Multi-Network Factory Floor Device NetworkingApril 1, 2005 By: Jeff Bock, John S. Rinaldi Sensors
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.
Most Read Articles