Humans are by nature creatures of habit. We like stability and we typically don't do well with change. One area where we haven't found consistency or stability is in factory floor networking. Just when we thought that these networks had stabilized, 2004 brought us incredible growth in Ethernet-enabled networking and 2005 looks to be very similar.
 |
The most practical approach to device networking in 2005 may be to build multi-network devices. Built to support multiple networking protocols, these devices can bridge serial, CAN (controller area networking), and Ethernet networks. These types of systems provide compatibility with legacy serial and CAN networks and also provide Web-server interfaces to CAN-based applications. Browser-based installation, troubleshooting, and online documentation can significantly improve your product all by themselves.
The Multi-Network Hardware Platform
Once you decide to support multiple networks, there are lots of strategies available, including daughter cards, external CAN controllers, and gateways. A new alternative is to select a processor platform with embedded Ethernet and CAN controllers. These processors combine serial, CAN, and Ethernet communications in a single package at a price point that is competitive with offchip Ethernet/CAN solutions.
ColdFire embedded 32-bit processors from Freescale Semiconductor are examples of this type of dual-network controller. Many of them integrate Ethernet and CAN controllers into the same die, and they are offered with and without embedded Flash memory. Freescale's MCF523x processor family (see Figure 1) shows the typical configuration for next-generation ColdFire embedded processors.
 Figure 1. Freescale's MCF523x processor family incorporates Ethernet and CAN controllers along with dedicated real-time control peripherals, such as the enhanced Timer Processor Unit (eTPU). |
RTOS and TCP/IP Stacks
A real-time operating system (RTOS) is often used within an embedded system to allocate CPU resources between control and communication tasks. Before discussing RTOS selection, it is important to discuss two reasons many system designers give for not including an RTOS in their factory floor devices: It costs too much, and the product is uncomplicated, so it does not need an RTOS. While advanced processors such as Freescale's ColdFire products can be implemented without an RTOS, in 2005 this strategy has little to recommend it.
Cost, often cited as the main reason to avoid an RTOS, actually favors use of an RTOS solution when all facts are known. The no-RTOS approach has hidden costs. First, any Ethernet solution requires a TCP/IP stack. Don't even look at the free stacks—you always pay for what you get in one way or another. When you purchase a TCP/IP stack you'll find that it can cost as much as or more than an RTOS, which typically includes a TCP/IP stack. Second, without an RTOS, designers generally implement some sort of internal, home-grown scheduler. Few systems of any complexity are actually no-RTOS; instead they use a home-grown RTOS with all its subsequent support costs. Over time it becomes difficult to add new features to the home-grown OS without fear of "breaking" the features currently implemented. As a result, a no-RTOS solution can be costly over the product life cycle.
Lack of complexity is usually the other reason cited for not including an RTOS. In this article, we're talking about multi-network systems with Ethernet, CAN, and possibly one or more serial communication ports. By definition, a system with these types of network interfaces is inherently complex and requires an RTOS to manage that complexity and properly service the network interfaces. It is hard to make the case that a system providing DeviceNet, EtherNet/IP, and Modbus TCP communications is not complex!
Most control-intensive applications (this includes most systems that control moving parts) have to deal with allocating CPU resources among three computing needs: high-level control algorithms, low-level control functions, and network connectivity. High-level control algorithms calculate how the application should be controlled. These algorithms may be quite complex and they require a significant amount of memory and CPU resources. Low-level control functions (such as servicing a timer) tend to be much simpler but must be executed with low latency. Low-level functions are typically handled by interrupts in order to ensure prompt servicing; however, interrupts generated by low-level control functions can impact the execution and performance of higher-level control algorithms.
 For More Information |
ColdFire processors support high-level algorithms and low-level control functions by using dedicated processors on the same chip. While the ColdFire CPU executes the RTOS and application control algorithms, a dedicated co-processor, called the eTPU (enhanced Timer Processor Unit) services all timing interrupts and processes low-level control functions. Low-level control is not impacted by task switches, and high-level control is not pre-empted by high-speed interrupts.
In comparison, most other processors don't have dedicated resources to handle low-latency interrupt requirements and therefore must consume significant CPU resources to meet real-time requirements. The eTPU offloads this task from the core and allows the ColdFire CPU to dedicate itself to executing high-level control code.
Choosing Network Application Layer Protocols
No matter what processor platform or RTOS is selected, a multi-network device requires a set of networking protocols. These software components handle the conversion of the bits and bytes of data sent across the network to data relevant to your application. Only a small set of application layer protocols is vital to plant floor networking. An overview of each of these follows.
Modbus (Serial). Modbus is the oldest of all the network communication standards and is the only serial communication standard on this list. Every device is represented as a collection of registers (16-bit unsigned integers) and coils (bits). The protocol has a very small instruction set with a very concise message frame. Designers are continuing to implement serial devices with Modbus capability, so the ability to send or receive data from these new and legacy devices will continue to be important.
DeviceNet (CAN). DeviceNet is one of the most important I/O networks in the U.S. today. It is an application layer protocol that uses CAN technology. CAN supports a single bus with drops topology. While CAN can support thousands of nodes and data rates up to 1 Mbaud, DeviceNet limits the network to 64 nodes and 125, 250, and 500 Kbaud. DeviceNet is a master-slave connection-based network, where a master device requests a connection from a slave and the two devices negotiate connections for noncontrol and I/O data. Once the I/O connection is created, masters communicate to slaves using polling, cyclic, or change-of-state communication modes.
CANopen(CAN). CANopen is another one of the CAN application layer protocols. Whereas DeviceNet is more connection oriented, CANopen is more message oriented. CANopen supports two basic messages; service data messages and process data messages. Service data messages are used for high-volume, low-priority messages, while process data messages are used for high-priority, low-volume messages. CANopen is not connection based and supports peer messaging. In production mode a CANopen device simply produces data without regard to who might be consuming it. CANopen has wide acceptance in Europe and growing acceptance in the U.S.
EtherNet/IP. EtherNet/IP is an adaptation of the CIP (control and information protocol) technology used in ControlNet and DeviceNet. Every device on the network is represented as a series of objects with attributes and values. EtherNet/IP uses TCP (transport control protocol) to transport message data and UDP (unconnected device protocol) to transport I/O data. EtherNet/IP is the standard for Ethernet communication to Rockwell Automation plant floor equipment.
Modbus/TCP. Modbus/TCP is Modbus over TCP/IP. Modbus/TCP uses the same register (16-bit unsigned) and coil (bit) representation and function definitions used for Modbus. All Modbus and Modbus/TCP messages are identical except that the CRC (cyclic redundancy check) field is not included in the Modbus/TCP message. Because of its simplicity, Modbus is widely implemented in plant floor systems.
Efficiently Creating Multi-Network Systems
Multi-network systems require additional hardware components and layered software modules to provide reliable, extensible systems over the product life cycle. One method to achieve this is to tortuously select the physical interfaces, an RTOS, a TCP/IP stack, and protocol application layers a la carte. This approach, highly risky in single network systems, is even riskier when dealing with multiple networks with their varied physical interfaces and multiple application layer protocols.
A more effective, less risky option is to select a vendor with a fully integrated package with all the physical interfaces, RTOS, and application-layer protocol stacks required for the application. For example, Freescale uses its Design Alliance Program (DAP) to forge strategic partnerships with RTOS and networking software vendors to create a large number of choices for its customers. Designers building multi-network systems can choose software modules from any of the vendors in the DAP program knowing that these solutions can be integrated with their Freescale hardware platform.
No matter which of the silicon vendors you prefer, if you choose to implement a multi-network platform in 2005, select the most highly integrated platforms to mitigate your risk, save effort and resources, and shorten your time to market.
Jeff Bock is a Senior Product Marketer, Freescale Semiconductor, Austin, TX; [email protected], www.freescale.com
John S. Rinaldi is President, Real Time Automation, Wauwatosa, WI; 800-249-1612, [email protected], www.get-ethernet-enabled.com or www.rtaautomation.com.