Embedded Systems
Making Medical Devices Smarter with CAN and CANopen Protocols
Nearly all medical electronics can now use controller-area network technology for remote access via the internet.
Olaf Pfeiffer
Today's computerized world tends to distribute and to decentralize. This is true not only for the Internet (many of the hottest Internet applications last year were based on distributed systems) but also for medical control applications in which local sensors are becoming smarter and network enabled.
In MEM's fall 1999 issue, Holger Zeltwanger showed how a controller-area network (CAN) and CANopen (a higher-layer protocol based on CAN) could be used in high-end medical electronics such as computed tomography systems from GE Medical Systems and other manufacturers. Since then, a number of new medical applications have incorporated CANopen and additional standards that are outlined. One such example is a CANopen device profile specified for collimators used in x-ray machines.
This article evaluates CAN as a viable option for less-expensive medical electronics. It also describes how Internet access to CAN and CANopen can be achieved, allowing for remote operation of equipment.
Affordability
Using Ethernet-based protocols tends to be overkill in price and performance for many embedded networking applications close to the sensor level. A more realistic approach comes from lighter networks based on CAN. Today, CAN is available in microcontrollers from more than 18 different chip manufacturers. It is the most affordable communication connection next to the regular universal asynchronous receiver-transmitter, or UART.
In addition to its affordability and availability, CAN provides many characteristics that make it ideal for applications at the sensor level. These include:
- Short message-frame sizes (maximum of 8 data bytes) that guarantee that no single message can block the network for a long period of time. Typical messages on a 1 Mb/second network only need 50–160 microseconds to transmit.
- Multimaster transmissions. Collisions are resolved in terms of priority.
- Physical layer requires only one or two twisted pairs.
- High reliability through a cyclic redundancy check (CRC) and retransmission on failure, which are all implemented in hardware.
- Network speeds up to 1 Mb/second that can be handled even by 8-bit microcontrollers.
However, simply providing a CAN interface is not enough to network-enable a device. Software is required to reach an off-the-shelf plug-and-play level, from which systems from different manufacturers can easily be combined. CAN provides a reliable communication channel. A higher-layer software protocol is required to specify what is communicated when, how the data are structured, and when to trigger and schedule the messages.
 |
|
In the past, only high-end
medical electronics such as x-ray machines could use controller-area network
technology. The technology is now a viable option for less-expensive medical
devices.
|
Remote Access
Many approaches are available for implementing remote access via the Internet to embedded devices. One Web page that summarized many approaches is www.embeddedinternetworking.com. Surprisingly, many options are available even for low- and medium-performance microcontrollers. If a CANopen network is used, the microcontroller of one of the network nodes can usually be used to implement a bridge or a gateway between CANopen and the Internet. Internet access can be provided either via a phone line or via an Ethernet connection, depending on the kind of access required by the application.
When using CANopen, adding remote access is a relatively simple step: All relevant diagnostic data and variables are already available on the network in standardized formats. A single access point implemented as an additional node or as a task on one of the nodes can provide remote access to all components of the local CANopen network.
Many proprietary solutions use customized interfaces. Such solutions guarantee certain levels of security and reliability. However, it is possible to simply use established Internet network protocols and services. Regular Web browsers or e-mail clients can be used to display HTML- or Java-driven user interfaces. Existing encryption methods for Web servers or e-mail can ensure privacy.
Although a low-performance microcontroller is sufficient to implement a complete, minimized Web server to allow access to local data or the local CANopen network, encryption usually requires a more powerful 16- to 32-bit microcontroller.
Getting Started
Different methods are available to implement a CANopen-compliant network interface. One of the first ideas that might come to mind is to get the specifications and start with the implementation. However, writing the code for a network protocol stack from scratch has some serious disadvantages.
This is one of the slowest approaches, requiring the longest development cycles, resulting in the longest time-to-market for the product. This path can also add up to be the most expensive path.
An alternate path that drastically shortens development time is to purchase the software for the network protocol stack. Usually these stacks, available for all major microcontrollers and CAN controllers, come with all necessary source code and only require a one-time fee.
Another approach, which provides the fastest turnaround times, is to use peripheral chips that implement the desired communication interface. Peripheral chips are sometimes available on a single chip or, more often, on a small PCB add-on board that can be incorporated into a manufacturer's own hardware. This approach requires no microcontroller development tools or custom coding, but it has some drawbacks. On a per-node basis, these solutions are usually more expensive, and some of the add-on boards can still be too large to be suitable for devices that need to stay within a small form factor. For low-volume applications, however, this is not a serious drawback.
In some cases, manufacturers prefer to have an in-house team involved in all levels of development. External trainers and consultants provide a quick start by helping to implement an initial prototype based on an evaluation board. They can also take care of the entire development, including testing.
Conclusion
The low per-node cost and the wide availability and selection of low- and medium-performance microcontrollers with an on-chip CAN interface make CANopen a candidate for almost any medical application—not only high-end medical electronics—using more than one microcontroller.
Once a CANopen network is in place, adding remote access to all components of the system is easier. CANopen provides a standardized way to access data in the local CANopen nodes in place. One single node of the system can act as the centralized remote-access point to the entire system.
The Web starting point for CAN and CANopen is http://www.can-cia.org. This site is maintained by the CAN in Automation (CiA) international users' and manufacturers' group. Although much of the information is available for free, additional services are available with paid membership, such as downloads of published specifications and preliminary drafts of new specifications.
Anyone interested in participating in any of the standardization committees for the usage of CANopen in medical applications may contact CiA via e-mail at headquarters@can-cia.org. For more technical insight on how CAN and CANopen networks operate, see the free on-line training classes offered by the Embedded Systems Academy at http://www.esacademy.com/myacademy.
Olaf Pfeiffer is manager in the United States for CiA (CAN in Automation). For more information, contact CiA at http://www.can-cia.org.
Copyright © 2002 Medical Electronics Manufacturing
