CANopen safety chip simplifies safety-related development -

CANopen safety chip simplifies safety-related development

Safety-related devices are increasingly being networked together. Expensive safety controllers and safety monitors are available already, but the number of simple and inexpensive safety-related devices is still low. Networked safety technology makes sense only if the peripherals are available at acceptable prices.

For device manufacturers, implementating a safety-related communication interface is challenging technologically as well as financially. Safety-related devices must be certified by the appropriate governing bodies worldwide, and for this reason the CAN in Automation (CiA) consortium of manufacturers and users commissioned the CANopen Safety Chip (CSC01). The CANopen Safety Protocol is programmed onto the chip's 16-bit microcontroller; TÜV Rheinland (the leading German technical inspection authority) has certified that this single-processor device meets IEC 61508 Safety Integrity Level 3 (SIL3).

The precertified and partly preprogrammed CSC01 is designed for safety-related devices such as sensors (for example, emergency switches, light grids, safety mats), actuators (safety-related relays and drives), or a mixture of both. One unique feature of the chip gives systems designers the ability to configure a direct communication link between safety-related sensors and actuators with no safety-related controller or monitor needed.

The chip simplifies the design of safety-related devices because the safety protocol is already implemented and certified. Manufacturers just have to have their safety-application program certified.

In Europe, the authorized classification bodies have outlined requirements to standardize levels of safety relevance. One such organization, the BIA (Berufsgenossenschaftliches Institut für Arbeitssicherheit or Institute for Occupational Safety), has adopted the Safety Integrity Levels (SIL) outlined in standard IEC 61508. SIL has four levels, defined as the percentage of error within a certain time. The IEC 61508 defines four SILs. They are:

SIL 4: L < 10-8 (Error/hour)
SIL 3: L < 10-7 (Error/hour)
SIL 2: L < 10-6 (Error/hour)
SIL 1: L < 10-5 (Error/hour)

The BIA defines possible failures as message repetition, message lost, message insertion, wrong message sequence, message corruption, message delay, and coupling normal and safety-related messages.

To achieve the SIL 3 certification the microcontroller must provide two CAN controllers with physically separate registers. The single processor implementation requires that the processor undergo a cyclic memory test to detect simple failures in the memory, such as a “frozen bit.” For reasons of performance this test is done with a hardware cyclic-redundancy check (CRC). The IEC 61508 standard also requires the processor be proven and reliable, meaning that it has been used in several large-scale applications for some period of time.

The CiA consortium that initiated the development of the CSC01 decided to use the M306NAFGTFP processor by Renesas. It provides sufficient peripherals (D/A converter, A/D converter, timer, and DMA controller) to be used in safety-related devices. This is also true for the chip's memory (10KB internal SRAM and 256KB flash memory) as well as the digital I/O and the serial interfaces. The microcontroller is run in “single-chip mode” at 16MHz. It comes in a QFP-100 package with a working temperature range of -40&#176C to +85&#176C (-40&#176 to +185&#176F).

CANopen Safety Protocol
In many embedded control systems, safety-related devices are required to communicate with other control equipment. However, control system designers don't like to have two different networks, one for embedded networking and another one for safety-related communication purposes. The CANopen Safety Protocol (CiA DS 304) allows combining both kinds of communication services.

Another advantage of the CANopen Safety Protocol is that all standardized device profiles can be also used for safety-related communication. In other words, devices that are built to comply with the standardized CANopen device profiles, such as a device profile for generic I/O modules or a device profile for motion controllers, communicate well within a CANopen Safety network. This communication is possible because the entire 8-byte data field can be used for safety-related process data transmission.

The CANopen Safety Protocol makes it possible to connect safety-related sensors and actuators directly to each other, thus avoiding the need for a safety-related controller (such as a programmable-logic controller or a safety monitor). Logically comparable safety chains can therefore be realized just as in conventional wired technology, such as an emergency switch that has a direct impact on the safety relay.

Based on the CANopen application layer (European standard EN 50325-4 and CiA standard DS 301/302), the CANopen Safety Protocol defines the safety-related data object (SRDO) for transmission of safety-related data. An SRDO is made up of two CAN messages, the identifiers of which differ in at least two bits. The information in the data bytes of the two messages are identical but bit-wise inverted, as shown in Figure 1. Both messages of an SRDO are transmitted within the safety-related validation time (SRVT) . An SRDO is transmitted periodically; the time between two SRDOs is defined by the safeguard cycle time (SCT ).

Figure 1: An SRDO is made of two CAN messages with up to 8-byte data. The second message contains the same information as the first but is bit-wise inverted.

The receiver checks if the SRDO is valid by comparing the time and the logic of the CAN messages with an expected value. The two messages are then checked against each other. Errors cause the actuators of the safety application to transit into a predefined safe state. The device manufacturer or the end-user defines this safe state.

The properties of the SRDOs (CAN identifier, SCT, SRVT, mapping) are stored in the object dictionary and checked with a CRC checksum. A global failsafe command (GFC) is defined to increase the reaction time in safety-related systems. A GFC is made up of two high-priority CAN messages (CAN identifier 1 and 2). The GFC does not contain any data and may be sent by any network participant. The reason for sending it, however, must later be given via an SRDO.

Safety-related software
In a completed device using a CSC01, the safety-related software is made up of two parts: the CANopen Safety Chip (CSC) main program and the safety application program. The safety application program is developed by the device manufacturer and then loaded into the CSC01's flash memory. For usage in actuators it must control the second switch-off channel, for example a watchdog switch.

The CSC main program contains the CANopen Safety Protocol stack with all safety-related communication functions as well as the diagnosis functions for RAM, register, stack, and flash memory. This program is the preprogrammed, precertified software on the chip. The main program must not and cannot be changed by the device manufacturer.

The CSC01 main program controls all functions of the CSC01. For example, it checks if all conditions are met for the transmission of a safety-related message. If the message is valid, it communicates this in two different ways to the safety application program: it calls an event function and changes the status in the safety-related RAM. If it receives an invalid message or if it doesn't receive a valid message within the expected time, it communicates this fact to the safety application program. The safety application program then has to react accordingly with a predefined error reaction, which is defined by the manufacturer of the safety-related device. It's possible to define reactions in such way that just certain parts of the device transition to a safe state and the other functional units are not affected at all.

For the safe transmission of data the chip provides four safety-related messages: two are for the sending, two for the receiving of safety-related messages. Thus, 128-bit data (arranged byte-wise) is available to each direction. The data in the safety-related messages is mapped statically. Users may program the mapping only during development of the device. They may also write the safety-related variables to the CANopen object dictionary.

How safe is “safe”?
The word “safety” is too general—it really doesn't mean anything definitive. Therefore, we use terms such as safety-related and safety-critical.

A safety-related device provides or ensures safety. It is required for machines/vehicles, which cause bodily harm or death to human being when they fail. A safe state can be defined (in other words, safety-related). In case of a buzz saw, this could be a motor that seizes all movements immediately. The seizure of movement makes the machine safe at that moment. IEC 61508 defines the likelihood of failures of this mechanism, the Safety Integrity Levels (SIL). SIL 3 is defined as the likelihood of failing less than 10-7 % per hour. This is a necessary level of safety integrity for products such as lifts, where several people's lives are endangered. The buzz saw is likely to require SIL 2 only, it endangers just one person.

Safety-critical is a different matter. To understand safety-critical imagine a plane in flight: it is not “safe” to make all movement stop since that would make the plane crash. A safe state for a plane is in the hangar, but this is not an option when you're in flight. Other means of ensuring safety must be found. One method used in maritime applications is the “CANopen flying master” principle, which uses redundancy to prevent failure. For the above example an SIL 4, meaning likelihood of failing less than 10-8 % per hour is necessary. This is also true for nuclear power station control systems, among other examples.

Figure 2: The concept of the CANopen Safety Chip CSC01 as it applies to sensors

Figure 2 shows the CANopen Safety Chip as it's used in sensor applications—no external watchdog is necessary. The logical function of the watchdog lies on the receiver's side at the actuator. For actuators a watchdog must be integrated in the safety application.

The CSC main program communicates via the following functions with the safety application program:

  • AppInitialisation(): Called to initialize the safety application program. The application program initializes its own global and local variables within the function. It also sets CAN Node-IDs and defines its own parts of the object dictionary and then registers this.
  • AppProcess(): Called cyclically. The safety application program processes its own cyclic processes in this function.
  • AppSrdoEvent(): Called if a safety-related message was sent or received without errors.
  • AppSrdoError(): Called if a safety-related message was received with an error or if the message did not arrive within the defined time. The safety application program acknowledges the successful processing of an event. If no positive acknowledgement was sent, the CSC main program interprets this as error and transits to the safe state.
  • AppPreSafetyStop(): The call before the transition to the safe state. The safety application program must not communicate with the watchdog any more.
  • AppNmtEvent(): Informs the application program that the CANopen network management (NMT) has an event to report.

There are also functions for the safety application program to call the CSC main program:

  • CgtAppToCscWriteObject(): Writes a value to an entry in the CANopen object dictionary, which is located in the memory area of the CSC main program.
  • CgtAppToCscReadObject(): Reads a value from an entry of the object dictionary.
  • CgtAppToCscSendEmergency(): Initiates sending an emergency message on the CAN network.
  • CgtAppToCscSendGfc(): Initiates sending a GFC message on the CAN network.
  • CgtAppToCscSignalPDO(): Initiates sending a Process Data Object (PDO) message on the CAN network.

The CSC main program is also in charge of the permanent control of the internal memory. The 5KB of RAM is tested via a transparent GALPAT test. The GALPAT test is a RAM exerciser, called a galloping pattern (hence GALPAT). The 42KB of program memory, which houses the CSC main program as well as the safety application program, is tested in the 16-bit CRC hardware within the microcontroller.

About 2ms of pure (no overhead) calculation time is available to the safety application program for a safety cycle time of 20ms. The safety application program is called eight times during the safety cycle time. It's called in a 2.5ms frequency with a tolerance of ±0.6ms.

Simple applications (such as emergency switches, light grids, and safety valves) can be implemented directly in the chip. For more complex applications (such as safety-related drives and emergency relays) the chip can be used as bus interface to communicate with other microcontrollers. For these cases the safety application provides the safe transmission of safety-related data to and from the safety-related application modules.

Device developers can design the interface any way they like. If the chip is used as an interface to the bus, errors are passed from the safety application as binary switch-off signal to the safety-related application unit. The switch-off itself is done by the safety-related application CPU.

If the CSC01 is used in sensors, no external watchdog is necessary. The logical function of the second switch-off channel is located on the receiving side at the actuator. Errors within the CSC main program (such as diagnosis errors) prevent further CAN messages from being sent.

If the processor is used in devices with safety-related outputs, a second switch-off channel must be implemented within the safety application program. In case an external watchdog is used, the safety application program is responsible for controlling it and setting it back. The CSC main program provides just the necessary information to use the watchdog switch. It doesn't check the watchdog, however.

Figure 3: The CSC01 starter kit1

To launch a safety-related device, developers must still program and implement their safety application and have it certified with the applying safety bodies in their country. Although the safety requirements for safety-related devices differ from country to country, the development environment is mandatory for compatibility reasons: if you don't use the mandatory development environment it may hamper the interaction between the safety application and the safety protocol implemented on the chip. The Altium (Tasking M16C Compiler Release Vers. 2.3 r1) development environment is mandatory for developers who program safety applications in every and any country if those developers want to keep an SIL precertification. Any other environment may interfere with the communication between the CSC main program and the safety application. CiA provides a starter kit (shown in Figure 3) and several software tools for developers of safety-related devices. A software tool is available from the organization for the configuration of safety-related messages. The starter kit provides an input module and an output module along with the CSC01 and a CAN-USB gateway module. The starter kit also provides cables, resistors, and demo versions for compilers and other software tools. The starter kit includes a functionally limited version of the configuration tool.

Safety boost
Safety certification is an expensive and time-consuming business. The higher the safety requirements are, the more manufacturers need to invest. Implementing both a safety protocol and programming a safety application, debugging, and having each part certified can take the better part of two years.

With the CANopen Safety Chip, half of the work is done already: The CANopen Safety Protocol is preprogrammed and precertified onto the microcontroller. It can be used for safety-related applications requiring a safety level of up to SIL 3 (IEC 61508). The chip targets safety-related sensors and actuators. System designers can concentrate on the safety application and speed time to market.

Monika Mack is technical editor and communications manager for the international users' and manufacturers' group CAN in Automation (CiA). You can reach her at .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.