Medical Device Link.

Medical Electronics Manufacturing Fall 1999

EMBEDDED SYSTEMS

Designing Devices Using CAN and CANopen Buses for Networking

Holger Zeltwanger

A controller area network (CAN) is an international standardized serial bus system dedicated for embedded distributed control systems originally designed for use in cars. Since 1992, it has been used as an embedded network in medical equipment. CAN protocol controller chips are available from about 20 companies, some of which have integrated the CAN module with a microcontroller. Because CAN is a data-link-layer protocol, it specifies only basic communication services. Users must specify an application layer and a communication profile, which defines the use of identifiers, configuration of devices, network management, and specific application objects. If the content of the data should be standardized, device and application profiles could also be required.

Many European medical device manufacturers have developed CAN interfaces based on proprietary protocols. Some companies are now migrating to existing standardized CAN-based higher-layer protocols. One of these protocols, CANopen, was developed by members of the CAN in Automation (CiA) international users and manufacturers group, a nonprofit organization. CiA has established a medical special interest group, which is specifying a CANopen-based application profile for integrated operating theaters (IOT) and integrated intensive-care units (IIU). This profile features a self-configuring capability, as well as off-the-shelf plug-and-play functionality. It also detects and prevents communication with uncertified devices. This article examines how CAN functions and how designers can implement this technology to develop devices that can be networked using a standardized protocol.

Layered Architecture and Communication Model

Any communication system can be regarded as a layered system. In human communication, the first layer (physical layer) might be a sheet of paper and a typewriter ribbon. In CAN networks, this functionality is implemented in CAN transceiver chips that are compliant with ISO 11898.

The alphabet represents the data-link layer (layer two) in human communication. In CAN networks, this function is represented by the CAN protocol itself. A lot of early CAN users have used Latin characters to define their own language. However, as in human communication, this method does not allow interoperability among devices implementing different application layers. That is the reason CiA developed the CANopen application layer and communication profile. In CAN networks, device and application profiles specify the content of the transmitted objects. For CANopen, several general-purpose device profiles are available. CiA is developing additional medical-specific profiles.

Basic Communication Services

The CAN data-link-layer protocol provides only two communication services: to transmit a message and to request the transmission of a message. The messages are broadcast transmitted, which means any node is allowed to receive any message. Each CAN message has a unique identifier for the message content. The identifier is also assigned a priority to arbitrate bus access when two or more nodes attempt to access the physical layer simultaneously.

To initiate data exchange, the cpu of a given station passes the data to be transmitted as well as the identifier assigned to the CAN chip. The message is constructed and transmitted by the CAN chip. As soon as the CAN chip receives the bus allocation, all other stations on the CAN network become receivers of the message. Each station in the CAN network, having received the message correctly, performs an acceptance test to determine whether the data received are relevant for that station. If the data are of significance for the station concerned, they are processed; otherwise they are ignored.

The content-oriented addressing scheme provides a high degree of system and configuration flexibility. Stations can be added to an existing CAN network without making any hardware or software modifications to existing stations, provided that the new stations are purely receivers. Because the data transmission protocol does not require physical destination addresses for individual components, it supports the concept of modular electronics and also allows multiple reception (broadcast, multicast) and synchronization of distributed processes. The network can transmit measurements needed by several controllers in such a way that it is unnecessary for each controller to have its own sensor.

For the data to be processed in real time, they must be transmitted rapidly. This not only requires a physical data transfer path with up to 1 Mb/sec throughput but also calls for rapid bus allocation to enable several stations to send messages simultaneously. In real-time processing, the urgency of messages to be exchanged over the network can differ greatly. A rapidly changing dimension (e.g., engine load) must be transmitted more frequently and therefore with fewer delays than dimensions that change relatively slowly (e.g., engine temperature).

There is no limitation on data size as long as the segmentation method is being used. The bandwidth, however, is limited and has a maximum data rate of 1 Mb/sec. At this speed, a network length of ~30 m is possible. To accommodate longer distances, the band rate must be reduced. At 50 Kb/sec, a network length of 1 km can be achieved.

Priority. The priority at which a message is transmitted compared with another less-urgent message is specified by the identifier of the message itself. The priorities, which are determined during system design in the form of corresponding binary values, cannot be changed dynamically. The identifier with the lowest binary number has the highest priority.

Bus access conflicts are resolved by bit-wise arbitration on the identifiers, which involves each station observing the bus level bit for bit. In accordance with the "wired and" mechanism, by which the dominant state (logical 0) overwrites the recessive state (logical 1), the competition for bus allocation is lost by stations with recessive transmission and dominant observation. All losers automatically become receivers of the message with the highest priority and do not reattempt transmission until the bus is available again (Figure 1).

Figure 1. Standard controller area network frame.

Frame Formats. The CAN protocol supports two message frame formats. The only essential difference is the length of the identifier. In the standard format, the length of the identifier is 11 bits, and in the extended format, the length is 29 bits. The message frame for transmitting messages on the bus comprises seven main fields.

A message in the standard format begins with the start bit "start of frame," followed by the arbitration field. This field contains the identifier and the remote transmission request (RTR) bit, which indicates whether it is a data frame or a request frame without any data bytes (remote frame). The control field contains the identifier extension (IDE) bit, which indicates either standard format or extended format, a bit reserved for future extensions, and, in the last 4 bits, a count of the data bytes in the data field. The data field ranges from 0 to 8 bytes and is followed by the cyclic redundancy check (CRC) field, which is used as a frame security check for detecting bit errors. The acknowledgment (ACK) field comprises the ACK slot (1 bit) and the ACK delimiter (1 recessive bit). The bit in the ACK slot is sent as a recessive bit and is overwritten as a dominant bit by receivers that have at that time received the data correctly (positive acknowledgment). Correct messages are acknowledged by the receivers regardless of the acceptance test results. The end of the message is indicated by "end of frame." Intermission is the minimum number of bit periods separating consecutive messages. If there is no following bus access by any station, the bus remains idle. Unlike other bus systems, the CAN protocol does not use acknowledgment messages, but rather it signals any errors that occur. For error detection, the CAN protocol implements three mechanisms at the message level:

• Cyclic redundancy check (CRC). The CRC safeguards the information in the frame by adding redundant check bits at the transmission end. At the receiver end, these bits are recomputed and tested against the received bits. If they do not agree, there has been a CRC error.

• Frame check. This mechanism verifies the structure of the transmitted frame by checking the bit fields against the fixed format and the frame size. Errors detected by frame checks are designated "format errors."

• ACK errors. Frames received are acknowledged by all recipients through positive acknowledgment. If no acknowledgment is received by the transmitter of the message (ACK error), this could mean that either a transmission error has been detected only by the recipients, that the ACK field has been corrupted, or that there are no receivers.

The CAN protocol also implements two mechanisms for error detection at the bit level:

• Monitoring. The ability of the transmitter to detect errors is based on the monitoring of bus signals: each node that transmits also observes the bus level and thus detects differences between the bit sent and the bit received. This allows reliable detection of all global errors and errors local to the transmitter.

• Bit stuffing. The coding of the individual bits is tested at bit level. The bit representation used by CAN is non-return-to-zero (NRZ) coding, which guarantees maximum efficiency in bit coding. The synchronization edges are generated by means of bit stuffing. After five consecutive equal bits, the sender inserts into the bit stream a stuff bit with the complementary value, which is removed by the receivers. The code check is limited to checking adherence to the stuffing rule.

If one or more errors are discovered by at least one station (any station) using these mechanisms, the current transmission is aborted by sending an "error flag." This prevents other stations from accepting the message and thus ensures the consistency of data throughout the network.

After transmission of an erroneous message has been aborted, the sender automatically reattempts transmission (automatic repeat request). The message might compete again for bus allocation. As a rule, retransmission begins within 23 bit periods after error detection; in special cases the system recovery time is 31 bit periods.

If no measures for self-monitoring are taken, defective stations can lead to all messages (including correct ones) being aborted, blocking the bus system. The CAN protocol therefore provides a mechanism for distinguishing sporadic errors from permanent errors and for localizing station failures (fault confinement). A statistical assessment of station error situations, with the goal of recognizing a station's defects and entering an operating mode where the rest of the CAN network is not negatively affected, identifies the error types. This can even include the station switching itself off to prevent messages that are erroneously recognized as incorrect from being aborted.

CANopen Application Layer

The CANopen application layer and communication profile was originally developed as a standardized embedded network with highly flexible configuration capabilities. CANopen unburdens the medical device developer from addressing CAN-specific details such as bit timing and implementation-specific functions. CANopen provides standardized communication objects for real-time data (process data objects), configuration data (service data objects), and special functions (time stamp, sync message, and emergency message), as well as network management data (boot-up message, NMT message, and error control message).

In addition to standardizing communication objects, CANopen specifies the description of application objects. In the CANopen device profiles, defined application objects achieve a partial interchangeability of CANopen devices. CiA has published device profiles for generic input/output (I/O) modules, drive and motion controllers, human-machine interfaces, and encoders.

For special application fields, CiA is developing frameworks. Both the CANopen framework for programmable devices and the interface profile for IEC 1131–compliant devices have already been published. The framework for safety-relevant communication based on CANopen will be available by the end of this year. A specific framework for medical systems is under development. To guarantee interoperability, a CANopen conformance test tool is available, which CiA also uses for certifying CANopen devices and their implementation. The first modules have passed the conformance and are already certified.

Different communication objects are required in each decentralized control application. In CANopen, all communication objects are standardized and described in the object dictionary. The CANopen object dictionary is accessible by a 16-bit index, and an 8-bit subindex provides the object dictionary for arrays and structures. The use of an object dictionary enables designers to specify objects independently of the CAN identifiers. CANopen can distinguish more than 2048 objects even if CANopen is based on standard CAN frames with 11-bit identifiers.

Figure 2. CANopen device model.

The CANopen object dictionary also describes all application objects of a device. Application objects can be specified by a CANopen device profile or by an application profile. In addition, device manufacturers can define nonstandardized application objects, but such devices will not be interchangeable with those of the same class from another company. For standard devices, only the range 6000h to 67FFh is required to fit into a multiple device module. The 67FFh entry is reserved for the device-type entry of a certain device. The object at index 67FFh and multiples with an offset of 800h describe the functionality of each virtual object within a single physical device. This technique allows eight virtual devices to be implemented in one physical CANopen module (Figure 2). Four classes of communication objects are standardized in CANopen.

Process Data Objects. Process CANopen data objects (PDO) are mapped to a single CAN frame using all 8 bytes of the data field to transmit application objects. Each PDO has a unique identifier and can be transmitted by only one node, but can be received by more than one (producer/consumer communication) node. PDOs can be transmitted in different modes driven by an internal event, an internal timer, remote requests, or sync messages received from a specific node. Default mapping of application objects, as well as the supported transmission mode, is also described for each PDO in the object dictionary. PDO identifiers have a high priority to guarantee real-time performance. If real-time performance is required, a system designer can configure an inhibit-time for each PDO. The inhibit-time forbids this object to be transmitted within a specific time period. A deterministic PDO behavior can be designed on more than one object. PDOs are transmitted with no confirmation.

The application objects transmitted within a PDO are defined in the PDO mapping object, which describes the sequence and length of the mapped application objects. The CANopen device profiles specify the default PDO mapping. A device that supports dynamic mapping of PDOs must do so during the preoperational state.

Figure 3. NMT slave state machine.

Service Data Objects. The second class of communication objects includes service data objects (SDO), which transmit configuration data, sometimes longer than 8 bytes. If variable mapping during operational state is supported, the SDO client is responsible for data consistency. The SDO transport protocol allows transmission of any size object. The first byte of the first segment contains the necessary flow-control information, including a toggle bit to overcome the problem of double-received CAN frames. The next 3 bytes of the first segment contain the index and subindex of the object dictionary entry to read or write. The last 4 bytes of the first segment are available for configuration data. The second and the following segments, using the same CAN identifier, contain the control byte and up to 7 bytes of configuration data. The receiver confirms each segment, providing peer-to-peer communication (client/server). In the future, CANopen will allow a fast SDO transfer, confirming not only each segment, but also the complete object (Figure 3).

Network Management Objects. The third class of communication objects includes the network management objects: boot-up objects, network management objects, and error-control objects. The boot-up object has the same identifier as the error-control object and is transmitted after initialization but before the node is set into preoperational state. The network management object, which is transmitted by the network management master node, is the highest priority object in a CANopen network. This object controls the NMT slave-state machine. A device operates in four states: initialization, preoperational, operational, and stopped. After power on, each CANopen node is in the initialization state and transits automatically to the preoperational state. In this state, sync objects and error control are provided, and SDOs can be transmitted. If the NMT master has one or more nodes set to the operational state, it can transmit and receive PDOs. In the stopped state, only NMT objects are allowed.

The initialization state is divided into three substates, enabling a complete or partial reset of a node. In the Reset_Application substate, the parameters of the manufacturer-specific profile area and the standardized device profile area are set to their default values. In the Reset_Communication substate, the parameters of the communication profile area are set to their power-on values. The third substate is the initialization state, which a node enters automatically after power on, reset communication, or reset application. Power-on values are the last stored parameters.

The error-control object indicates which state a node has. This object can be requested remotely by the NMT master module (node guarding) or can be transmitted periodically by the NMT slave modules. Transmission cycle times as well as expected reception cycle times can be configured.

CANopen also defines three specific objects for synchronization, emergency indication, and time stamp transmission. The sync object, which provides the basic network clock, is broadcast periodically by the sync producer. The time between sync messages is defined by the communication cycle period object, which may be written by a configuration tool during the boot-up process. A time jitter can occur in transmission by the sync producer because objects with higher priority identifiers are being transmitted or because one frame is being transmitted just before the sync object. The sync object is mapped to a single CAN frame with the identifier 128. By default, the sync object does not carry any data, but it can have up to 8 bytes of user-specific data.

Emergency objects are triggered by a device internal fatal error and are transmitted from an emergency client on the application device. This makes them suitable for interrupt-type error alerts. An emergency object can be transmitted only once per error event. As long as no new errors occur on a device, no further emergency object may be transmitted. Any number of emergency-object consumers can receive these objects. The reaction on the emergency consumers is not specified. CANopen defines several emergency error codes to be transmitted in the emergency object, which is a single CAN frame with 8 data bytes.

A common time-frame reference is provided to application devices by means of the time stamp object. It contains a value for the time of day. This object transmission follows the producer/consumer push model. The associated CAN frame has the identifier 256 and a data field length of 6 bytes.

Figure 4. X-ray angio-biplane system using CANopen technology.

Because CAN is a communication object (COB)–oriented network, where each COB has one or more associated identifiers that implicitly specify its priority, the allocation of identifiers to the COBs is an essential issue in the system design. To reduce the configuration effort for simple CANopen networks, a default identifier allocation scheme is defined. These identifiers are available in the preoperational state and can be modified by means of dynamic distribution. A CANopen device must provide the corresponding identifiers only for the supported communication objects. The default profile identifier allocation scheme consists of a functional part, which determines the object priority, and a module identifier part, which distinguishes between devices of the same functionality. The identifier allocation scheme corresponds to a predefined master-slave connection set and allows peer-to-peer communication between a single master device and up to 127 slave devices. It also supports the broadcasting of nonconfirmed NMT, sync, and time stamp objects. The predefined master-slave connection set supports one emergency object, one SDO, up to four receive PDOs and four transmit PDOs, and an error-control (boot-up) object. To optimize the identifier allocation, system designers can reallocate the identifiers statically, which means that the identifiers are fixed during the run time of the system. Dynamic distribution, which is the preferred method in CANopen-based systems, indicates that the identifiers are distributed via the CAN network using the SDO services (Figure 4).

To transfer data items to the correct location in the network, it is sometimes necessary to link transmit PDOs and receive PDOs, which are transmitted from one device and received from others. This is the case in systems in which the default identifier distribution is insufficient. In the process of PDO linking, system designers must ensure that the transmit PDOs have unique identifiers and that the data length of linked PDOs is identical.

Conclusion

Networking medical devices is becoming more important to end-users. Using a standardized protocol enables manufacturers to develop devices that can be easily linked to other systems. CAN is a data-link protocol that allows manufacturers to specify application layers and communication profiles.

Holger Zeltwanger is managing director of CAN in Automation (CiA; Erlangen, Germany).

Back to the Fall 99 Table of Contents