Smarten-Up Your Sensors with DeviceNet and CANopen

by Olaf Pfeiffer

Introduction

We live in a computerized world that tends to distribute and to decentralize. This is not only true for the Internet where many of the hottest applications during the last year where based on distributed systems - it is also true for embedded and industrial control systems where local sensors and actuators more and more often become smarter and network enabled. One of the latest examples is a higher-end coffee machine by WMF (one of those where you have compartments for different beans, milk and water). Several microcontrollers are networked together to control all the different valves, the heater, the grinder, etc.

When talking about "embedded network enabled" in this context, please don't envision a valve with an Ethernet interface. In the arena of embedded networking we are usually faced with one major restraint: costs. Sure would it be nice to be able to place our valves and pressure sensors onto a network - but please not by adding some $10+ of hardware components.

Show me the money - CAN is affordable

Ethernet based protocols tend to be a complete overkill in price and performance for many embedded networking applications close to the sensor and actuator level. A much more realistic approach comes from some "lighter" networks based on CAN - the Controller Area Network. Today, CAN is available in so many microcontrollers from some 18+ different chip manufacturers that cost wise it is the next most affordable communication connection to the regular UART.

Besides its affordability and availability, CAN has a few more benefits for applications in the sensor and actuator level. These are things like

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.
Multi-master transmissions (collisions are resolved by priority)
The physical layer just requires one to two twisted pairs.
High reliability through CRC check and retransmission on failure - all implemented in hardware.
Network speeds up to 1Mbit that can be handled even by 8-bit microcontrollers.

However, just providing a CAN interface is not enough to network enable a device. There is a little more software required to reach an off-the-shelf plug-and-play level, where system integrators can easily combine different components from different manufacturers. All CAN really does is provide a reliable communication channel - in addition a higher layer software protocol is required to specify what is communicated when, how the data is structured and when do we trigger and schedule the messages.

How to get started

The web starting points are www.odva.org for DeviceNet (site maintained by the Open DeviceNet Vendors Association) and www.can-cia.org for CANopen (site maintained by the CAN in Automation international users and manufacturers group). Both sides maintain an on-line product and service catalog containing all major providers and products. They also offer many additional services for paying members, such as free downloads of published specifications as well as preliminary drafts.

To implement a DeviceNet or CANopen compliant network interface for a sensor or actuator, there are different routes that can be taken. One of the first ideas that might pop to mind is "let's get the specifications and start with the implementation". However, writing the code for a network protocol stock from scratch has some serious disadvantages. Besides being 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 does shorten the development time drastically is purchasing the software for the network protocol stack from one of the many providers (see the web pages mentioned above for more details). Usually these stacks come with all source code, only require a one-time fee and are available for all major microcontrollers and CAN controllers.

In case the in-house development team does not want to get involved in all levels of details, external trainers and consultants can be used for any of the stages of the development. They can either provide a quick start by helping to get an initial prototype based on an evaluation board implemented within a few days or take care of the entire development including test.

A completely different approach that can result in the fastest turn-a-round times is using "peripheral chips" that implement the desired communication interface. These are sometimes available on a single chip or more often on small PCB add-on board that can be incorporated into your own hardware. Although this approach has additional benefits such as not needing to buy any microcontroller development tools and getting involved in actual coding, there are some drawbacks: on a per node basis, these solutions are usually more expensive (which for low-volume applications is not a serious drawback) and some of the add-on boards can still be of significant size making them unsuitable for devices that need to stay within a small form factor.

Conclusion

Network enabling a small sensor or actuator with a CAN-based network protocol such as DeviceNet or CANopen is not a major undertaking. Even a company with little or no experience in embedded networking can have a prototype up and running within a few weeks, if the proper tools and resources are combined.