Originally Published MEM Fall 2005
NETWORKING
Medical Device Network Control StandardsOpen networking solutions based on the CANopen standard save medical equipment developers time and money.
Cyrilla Jane Menon
Many medical devices are machines. And, like modern machines in many industries, they employ networks for sharing information and controlling functions. However, unlike in most other industries, medical device manufacturers have been slow to move toward open networking standards for their applications.
This is not to imply that there are no standards; some are being used. One application known as the medical information bus (MIB) has defined a large group of profiles.1 For MIB, a profile describes the behavior of a given device. MIB is used in some applications, but with some proprietary elements.
Many device manufacturers use Digital Imaging and Communication in Medicine (Dicom), the network for transferring radiological data. But Dicom does not add the element of control. Machines need to be controlled. Increased automation control decreases the chance of human error.
Open networking standards that include control capability are just coming of age in medical devices. But they have been used prominently in automobiles for more than two decades. Automotive applications include real-time control of brakes and engines. The automation industry has used control networks for robots, transfer lines, and many other applications.
The topology, or configuration, of such applications is typically multitiered. It has been dis- covered that one network usually does not satisfy the requirements of all the applications the system might want to employ. Many automobiles, for example, have more than one network to cover the various applications, such as power train, body control, infotainment (navigation and video, for instance), and so on. Some of these networks would be good at spooling large chunks of data, such as video and imaging, in medical device applications. Others would be good at sending short, quick data packets for real-time control.
Some open network standards for medical device control applications have emerged. Many are based on controller-area network (CAN) technology. For these applications, CAN is coupled with another open standard, CANopen. CANopen is a generic framework, or higher-layer protocol, that allows industries to come together and quickly design application-specific implementations. CANopen medical applications have been created for a number of devices, such as injection-scanner machines, radiation dosimeters, and collimators, for example.
CAN and CANopen standards are managed by the nonprofit organization CAN in Automation (CiA).2
Controller-Area Network Technology
In order to understand these device control networks, a clear understanding of CAN technology is important.
CAN was invented by the German automotive system supplier Robert Bosch GmbH in the early 1980s for use as a control system on motor vehicles.3 The same inherent robustness that makes the technology suitable for the automotive environment makes it ideal for many automation environments, as well. The fact that it is used in critical automobile braking applications suggests its utility for medical applications that require reliable performance.
) |
| Figure 1. The ISO open systems interconnection seven-layer model. (click to enlarge) |
CAN covers the data link layer and part of the physical layer in the International Organization for Standardization (ISO) seven-layer open systems interconnection (OSI) model (see Figure 1).4 It is a serial data communication network in which messages are broadcast on the network media with multicast reception for systemwide data consistency. The CAN controllers (hardware) implement what is known as the CAN protocol. All CAN controllers exhibit unified behavior with respect to the network. This includes powerful error handling and fault confinement, along with bus access priority by nondestructive bitwise arbitration over the message identifier. The fault-confinement function attempts to distinguish permanent from temporary faults.
The structure of a CAN message is characterized by an identifier as standard (11-bit) or extended (29-bit). The data field can be any size between 0 and 8 bytes. Bus speed is configurable from 1 to 1000 Kbps. Off-the-shelf CAN silicon is available in a variety of packages and from several manufacturers. Because CAN products have been manufactured in high volumes for automotive applications, suppliers can offer them at a low cost.
Also, the large market increases the variety of the development tools available. These tools range from low-end CAN-to-PC interfaces without PC software to high-end analyzers with extensive features. Because of the variety, developers are not locked into a particular tool set.
Although CAN was originally standardized for technical reasons, cost is also a prominent factor. Savvy end-users are aware that the investment cost of developing CAN-based solutions is typically less than with other types of networks, and thus they can reap financial benefits from using the more cost-effective option.
CANopen (EN-50325-4)
CAN alone is not enough. System implementers need to decide what the messages mean, what priority the messages should have, what types of messages they want to transmit (such as event-triggered or time-triggered), and other system requirements. CANopen was created to serve as a system foundation that predefines those variables yet preserves highly flexible configuration capabilities. It provides the frame for the other layers of the ISO seven-layer model and unburdens the embedded-control-system developer of having to deal with CAN-specific details.
CANopen development began at Bosch, but in 1995 the company handed it over to CiA, which is an international association of CAN users and manufacturers. The members of CiA were looking for a common interface for machine control systems that they could easily program for a variety of applications. CANopen has also been adopted for applications involving off-road vehicles, maritime electronics, and railways, as well as medical equipment.
With CANopen, the interface between the application and CAN is realized by an object dictionary. The object dictionary is unique for each CANopen device and represents the whole access to its implemented application in terms of data and in terms of configuration.
The foundational principles of CANopen are strong, and they are generic enough to be standardized on their own. In fact, CANopen version 4 (CiA Draft Standard [DS] 301) is standardized as European Norm (EN) 50325-4.5,6 The CANopen specifications cover the application-layer and communication profiles (CiA DS 301), a framework for programmable devices (CiA 302), and recommendations for cables and connectors (CiA 303-1). The application-layer as well as CAN-based profiles are implemented in software.
In addition to the transmission and receiving of data and network management, the technical specifications encompass objects for synchronization, time-stamp, emergency, and other special functions.
CANopen sets up the framework for dealing with CAN-specific details such as bit-timing and implementation-specific functions in an object-oriented way (see Table I). It also provides standardized communication objects for real-time data (process data objects), configuration data (service data objects), and special functions, as well as network management data. The CANopen specifications, frameworks, and profiles are available from CiA at no charge.7
|
0h
|
—
|
Network management service |
|
80h
|
—
|
Synchronization message |
|
81h
|
FFh
|
Emergency message |
|
100h
|
—
|
Time stamp message |
|
181h
|
1FFh
|
Transmit process data objects |
|
201h
|
27Fh
|
Receive process data objects |
|
281h
|
2FFh
|
Transmit process data objects |
|
301h
|
37Fh
|
Receive process data objects |
|
581h
|
5FFh
|
Transmit process data objects |
|
601h
|
67Fh
|
Receive process data objects |
|
701h
|
77Fh
|
Network management error control |
| Table I. Hex value ranges for CAN open ID messages. | ||
Controller-Area Network Technology
In order to understand these device control networks, a clear understanding of CAN technology is important.
CAN was invented by the German automotive system supplier Robert Bosch GmbH in the early 1980s for use as a control system on motor vehicles.3 The same inherent robustness that makes the technology suitable for the automotive environment makes it ideal for many automation environments, as well. The fact that it is used in critical automobile braking applications suggests its utility for medical applications that require reliable performance.
) |
| Figure 2. Transmission can be driven by an event or timer, by remote request, by synchronization message, or by a combination of these. (click to enlarge) |
A process data object (PDO) is used to transmit the application data. Each PDO has a unique CAN identifier and is transmitted by only one device, but it can be received by more than one in producer-consumer communication. These transmissions may be driven by an internal event, by an event timer, by remote requests, by the synchronization message received, or by a combination of these (see Figure 2). Event- or timer-driven PDO messages are transmitted when an event or elapsed time triggers their sending. Synchronous transmission of PDOs takes place in both cyclic and acyclic transmission modes.
Controller-Area Network Technology
In order to understand these device control networks, a clear understanding of CAN technology is important.
CAN was invented by the German automotive system supplier Robert Bosch GmbH in the early 1980s for use as a control system on motor vehicles.3 The same inherent robustness that makes the technology suitable for the automotive environment makes it ideal for many automation environments, as well. The fact that it is used in critical automobile braking applications suggests its utility for medical applications that require reliable performance.
) |
| Figure 3. Service data object messaging. (click to enlarge) |
Service data object (SDO) messages are used to gain access to all device parameters for information or configuration. The SDO reads from entries or writes to entries of the object dictionary (see Figure 3), while the SDO transport protocol allows objects of any size to be transmitted.
The network management (NMT) and error control objects include boot-up message, heartbeat protocol, and NMT messages. The boot-up message and heartbeat protocol are single CAN frames with a 1-byte data field. The NMT message, transmitted by the NMT master, requires the addressed nodes to transmit their NMT state.
Additionally, CANopen defines protocols for synchronization, emergency indication, and time-stamp transmission. These error control messages are used to validate that a device is working properly in terms of CANopen communication.
The synchronization (sync) object message can be broadcast periodically by the sync producer, which acts like a strobe in sending device application messages. The time interval between sync messages can be defined.
The emergency message is triggered by the occurrence of a device internal error. It may be suitable for interrupt-type error alerts. The reaction of the emergency consumer is application specific and can be configured by the system designer. CANopen defines several emergency error codes to be transmitted in the emergency message, which is a single CAN frame with 8 data bytes.
Controller-Area Network Technology
In order to understand these device control networks, a clear understanding of CAN technology is important.
CAN was invented by the German automotive system supplier Robert Bosch GmbH in the early 1980s for use as a control system on motor vehicles.3 The same inherent robustness that makes the technology suitable for the automotive environment makes it ideal for many automation environments, as well. The fact that it is used in critical automobile braking applications suggests its utility for medical applications that require reliable performance.
) |
| Figure 4. Time stamp message. (click to enlarge) |
A common time stamp provides frame reference to the application devices. It contains a value of the type time-of-day (see Figure 4). This object transmission follows the producer-consumer push model.
CANopen Medical Device Profiles
Beyond the generic behavior of CANopen, device-specific attributes and actions need to be defined. It is advantageous to create device models with common basic required functions for interchangeability and ease of use. To lend openness, vendor-specific functions are allowed.
Controller-Area Network Technology
In order to understand these device control networks, a clear understanding of CAN technology is important.
CAN was invented by the German automotive system supplier Robert Bosch GmbH in the early 1980s for use as a control system on motor vehicles.3 The same inherent robustness that makes the technology suitable for the automotive environment makes it ideal for many automation environments, as well. The fact that it is used in critical automobile braking applications suggests its utility for medical applications that require reliable performance.
) |
| Figure 5. Definition of a device in CANopen, with reference by analogy to language structure. (click to enlarge) |
The reasoning behind device models can be compared with language structures. For speakers to fully understand each other, knowing their ABCs is not enough. They must have some agreed-upon grammar and vocabulary. With those, not only can they communicate, but a short story can be created. Carrying the analogy to networking, the letters would be the CAN frames. The grammar and predefined phrases are the device profile with its common structure. Adding the application profiles—that is, how those devices should be used—completes the story (see Figure 5).
CANopen device profiles are developed when two or more interested companies work together to arrive at an agreed-upon device definition. These device profiles can focus on the devices as dependent parts of a medical subsystem or as independent devices that are integrated with other independent devices. CiA has developed two standards families for medical device manufacturers: Profiles for Medical Devices (CiA Draft Standard Proposal [DSP] 412) and the Application Profile for Medical Diagnostic Add-on Modules (CiA DSP 425).
The CANopen Profiles for Medical Devices comprise the following parts:
- Part 1: General definitions.
- Part 2: Profile for automatic x-ray collimators.
- Part 3: Profile for x-ray generators (under development).
- Part 4: Profile for patient tables (under development).
- Part 5: Profile for x-ray stands (under development).
- Part 6: Dose measurement system.
In DSP 412, CANopen networks are used to provide device-to-device control of x-ray collimators, x-ray generators, patient tables, x-ray stands, and other subsystems. The interface is specified in each device profile and allows for remote control of devices of that type.
Example: Automatic X-Ray Collimators
In DSP 412 Part 2, guidelines for implementation of CANopen-based control of automatic x-ray collimators are given. The guiding architectural principles for use in defining the generic collimator device profile are that the collimator has no application knowledge and no system knowledge and that the system has no knowledge of the collimator device implementation. The device profile is crafted to minimize the number of violations of these guiding principles. In addition, manufacturer-specific functionality can be added to the generic collimator functionality.
The generic collimator, as defined by this device profile, has three basic functions, which may or may not be implemented in a particular collimator. The main purpose of a collimator is to limit, or collimate, the radiation beam issued by an x-ray-emitting source, such as an x-ray tube against a defined receptor format. The specification supports several versions of this collimation function—symmetric, rectangle, and circle. Rectangular collimation is the most common. In addition, filters may be applied to the x-ray beam to influence its spectral characteristics. Visual simulation of the x-ray beam is the third functionality incorporated in this device profile.
Controller-Area Network Technology
In order to understand these device control networks, a clear understanding of CAN technology is important.
CAN was invented by the German automotive system supplier Robert Bosch GmbH in the early 1980s for use as a control system on motor vehicles.3 The same inherent robustness that makes the technology suitable for the automotive environment makes it ideal for many automation environments, as well. The fact that it is used in critical automobile braking applications suggests its utility for medical applications that require reliable performance.
) |
| Figure 6. The x-ray collimator coordinate system, in front view. (click to enlarge) |
The specification begins with a definition of the collimator coordinate system (see Figure 6). This consists of the collimator entrance plane (to be defined by the collimator manufacturer), the central collimator axis that crosses the collimator entrance plane perpendicularly, and the image receptor reference plane that is defined as parallel to the collimator entrance plane and located at a distance from the x-ray focus (the source image distance [SID] in the figure).
Local control functionality is defined as optional; that is, collimator function may be controlled locally without a transmission of commands via the CAN bus. Local control therefore may result in internal collimator events affecting the functionality of the collimator.
The collimator functionality coordinates (X, Y, s, w, and D as defined in the device profile) may be controlled either in position or velocity mode. The X and Y coordinates define the square, and the s and w are required for representing any quadrant. M and D represent a circle's midpoint and diameter, respectively. A coordinate is in position mode when it receives a new target position. The coordinate is then moved to the target position with the maximum collimator-specific velocity defined for this coordinate. A coordinate is in velocity mode when it receives a new target velocity. The coordinate is then moved at the requested target velocity in the direction given by the sign of the target velocity value.
Medical Diagnostic Add-on Modules
The application profile for medical diagnostic add-on modules presented in standard DSP 425 consists of three parts, covering general definitions, injector devices, and electrocardiogram devices. The general application allows the injection machine to be controlled by a scanning device. With regard to remote control capability, there are six levels of implementation defined for injector devices:
- Class 0: Monitors injector device state machine.
- Class 1: Controls the injector device state machine.
- Class 2: Reads the actual injector device parameters.
- Class 3: Reads the configured injector device parameters.
- Class 4: Configures the injector device parameters.
- Class 5: Adjusts in real time the injector device parameters.
For error control, the CANopen heartbeat is required for reporting the current NMT state. Configurable or transmitted data include, for example, current injected total volume, current pressure, current flow rate, and volume remaining.
Conclusion
Networks are an important part of embedded systems. Networks specified for use in particular embedded or system applications have recently become available. This is important, because their availability means developers can now save time and money in creating a device suitable for their application.
Medical device manufacturers have implemented control-based networks. FDA has publicly stated that it will embrace open network standards and work cooperatively with device manufacturers that use them. (Universities such as Johns Hopkins are currently researching projects that use CAN-controlled surgical robots.) The opportunity should be taken to look further at developmental projects and consider using open solutions rather than proprietary applications.
CANopen, used in conjunction with long-proven CAN technology, is 10 years old. It has been employed in multiple applications and industries. This off-the-shelf open technology is probably not the answer for transmitting large amounts of data. The system, however, is completely suitable for real-time control applications. CANopen has been selected for a variety of real-time applications by product developers.
References
Bibliography
O Pfeiffer, A Ayre, and C Keydel. Embedded Networking with CAN and CANopen. (San Clemente, CA: RTC Books, 2003).
Cyrilla Jane Menon is general manager for CAN in Automation North America (Novi, MI). She can be reached at menon@can-cia.org.
Copyright ©2005 Medical Electronics Manufacturing
