Feature

Simplifying industrial backplanes

System designers turn to serial-communications strategies to boost reliability and extend service life in hostile factory or industrial environments.

By Richard Zarr, National Semiconductor -- EDN, 12/5/2005

Designing automation controls for a factory floor is a daunting task. You must consider the environment—hot, dirty, corrosive, electrically noisy, and generally hostile to anything electronic (or human, for that matter). Most PLC (programmable-logic-controller) systems include a central controller and peripheral I/O modules. These modules can include ADCs, DACs for connecting to sensors and the real world, communications modules, digital inputs and outputs, relays, and more. All of these modules need to communicate with the central controller through a signal bus. Designers can bolster the reliability of a system by simply removing interconnections between devices. Several methods for this technique exist, but the simplest is to serialize the data and use fewer connections. The techniques involve several physical layers and topologies, as well as packet formats to make implementing these buses straightforward. Communication, whether it is with smoke signals or lasers, requires a physical medium in addition to some time to propagate from the origin to the destination. Many options are available, including wireless, cable, fiber optic, and acoustic. All of these physical media carry intelligence, but some are better than others for harsh environments.

In the wired category, the standards include TTL (transistor-to-transistor logic), ECL (emitter-coupled logic), RS232, RS422, RS485, LVDS (low-voltage differential signaling), and Ethernet, which find use in networks, backplanes, and buses. The older TTL standard uses a nearly 5V signal relative to ground; is slow; and is single-ended, which leaves it susceptible to ground noise. RS232 adds a bipolar voltage swing to help with noise immunity but lacks differential signaling's advantages in electrically noisy environments. RS422, RS485, and LVDS standards all use differential pairs of wires to remove common-mode noise across both wires at the receiver. LVDS uses current instead of voltage and greatly speeds the signaling by reducing signal swing. This approach removes many issues with wires, including cable capacitance.

In an electrically hostile environment, such as a steel mill, large electrical currents can be flowing inches away from a control system. These currents can induce noise onto conductors, especially long interconnects between devices. The standard technique for rejecting this noise is to use differential signaling. RS422 and RS485 are good options for long-haul interconnections but lack speed for local buses. LVDS is a better choice for local buses, such as those between devices mounted on DIN rails. In addition, designers are starting to use Ethernet as an interconnect in backplanes. Ethernet has several advantages. It is a standard; uses a well-defined MAC (media-access controller), which many processors employ; and has standard drivers for most operating systems. This article focuses on serialized-LVDS approaches as methods for maintaining good noise immunity plus providing 100- to 400-MHz speeds.

Topologies

Which topology makes the most sense? Options include the multidrop bus, the redundant multidrop bus, the point-to-point bus, and the ever-popular ring topology. The multidrop, or multipoint, bus is popular for many backplanes and is well-suited for both single- and multiple-processor systems. If you choose LVDS, you would use a double-terminated transmission line with LVDS transceivers at each board. The advantage of using individual transceivers is twofold. First, you can place the transceivers near the connector, limiting near-end reflections from the connection discontinuities. Second, these transceivers tend to be more robust than integrated drivers in FPGAs. They are also cheaper to replace in case of failure than a $100 FPGA. In this topology, a message would enable the driver on a board and send the serialized packet onto the backplane. All other devices would be listeners and receive the transmitted packet. Most shared-bus topologies need some form of traffic control. A simple method is to use a common access line involving additional wires to indicate to all devices that someone has requested the bus and no other device can talk. Alternatively, you can implement a master/slave organization to allow communication only when the master controller asks for it (Figure 1).

Multidrop buses are simpler to implement; however, the entire bus can fail if a single failure, such as a short, the loss of a terminator, or a hung bus driver, occurs. This failure can be catastrophic in an industrial environment; consider an oil refinery in which failure is not an option. A simple way to fix this problem is to use two buses. If one dies, the other keeps working. In addition to the redundancy, the system has twice the bandwidth in its native mode (normal operation). With two buses, the loss of one bus simply halves the available bandwidth, allowing the system to continue to function in a reduced mode. The downside to this option is increased cost and complexity (Figure 2).

Another method of preventing bus failures is to use a point-to-point topology, which Ethernet networks use. Each device has its own bus to communicate with the controller. If a single device or bus fails, all the other devices continue working without compromise. However, in a local backplane, the downside is the mechanical interconnection. For devices that plug into one another, such as DIN-rail mounting, pass-through connections would be necessary, thus increasing rather than minimizing the number of interconnections. The increased number of wires diminishes the advantages of the point-to-point topology for backplanes.

A ring topology, on the other hand, is self-healing and can automatically partition itself. Token-ring and similar networks use this method. In a backplane implementation, the system contains the ring. The topology also allows side-by-side plugging of modules on DIN rails (Figure 3). If any device or interconnection fails, the ring can turn back on itself, isolating the faulty device or broken connection (Figure 4). The physical implementation of the ring topology is similar in expense to that of a dual-multidrop-bus architecture with the exception of the interface. The ring uses only drivers and receivers, not transceivers. However, two additional passive buses are necessary to complete the ring. The driver is always enabled; however, because the device can select either of two receiver buses, an enable must select the desired bus. Alternatively, two digital inputs on an FPGA could select the bus. Sample components for this approach include the National Semiconductor DSLV049, using digital selection of the receiver; the DS90LV027 and 28; or two DS90LV019 transceivers.

An interesting benefit of the ring topology is a pseudo-point-to-point connection. This approach eliminates the requirement for bus access because the packet traffic is unidirectional. The downside is that every module needs to handle every packet. Designers can somewhat automate this process in the control logic of the interface using a short buffer to implement a store-and-forward methodology. The device need not necessarily store the entire packet but must store just the header for inspection.

Protocols

Given a reliable hardware implementation, a method of accessing the physical media through a protocol is necessary. The protocols vary depending on the topology. In the multidrop topology, a device must signal to all the units before transmitting data to minimize or avoid collisions on the shared media. Collisions will occur, so a checksum must verify the integrity of the information in a packet of data. Randomization of retransmission times can help to reduce the collisions on the bus. Prioritizing devices by bus position or address can also help. By using a priority-access method, the units with the highest priority have the shortest wait time when sending packets. You can establish a fixed priority or use a round-robin approach in which the last device that transmitted has the lowest priority. As other devices send messages, the priority of the waiting device rises, and waiting time lowers. This method gives each device equal bus time to send messages. High-priority messages can have a fixed minimal delay time or no delay time for urgent messages, such as "emergency stop."

In a serializer/deserializer system, when the bus is not in use, idle messages continuously transmit to allow the recovery circuitry in the deserializer to synchronize on the data. In a shared-bus topology, the system cannot use idle messages to synchronize the receivers, so a preamble in the packet format is necessary. The preamble varies in length depending on how fast the receiver synchronization circuits lock to the incoming data. A faster lock time in the receiver means that the preamble will be shorter and the data throughput will be more efficient.

In a ring topology, it is advantageous to continuously transmit idle data to always lock the serializer/deserializer receivers. However, a method must exist for controlling when each device wishes to place information in the stream and not collide with another device. Ring topologies use token passing to provide a cue on when to transmit data. A token is a special header that identifies the current token master, as well as other data on the network. Data follows the token like freight cars following a locomotive. At each stop along the way, a device has the option of adding data following the token when the token is not in use.

In the simplest form of a ring, only one device can use the token at a time. This approach simplifies carrying packets in a continuous stream. So, as each device receives the token, it sets a bit in the token, signaling that it has taken the token for packet traffic, and all upstream devices, excluding the destination, simply pass it on. This method removes the store-and-forward requirement. The destination device simply removes the packet as it comes in and frees the token unless an outgoing packet needs it. The downside here is bus efficiency. If the token is in use, a device must wait for it to be free before sending data.

Various methods exist for providing priority to a token-based system. A simple one is to implement a round-robin method of token counting. If a system has three bits of priority (seven levels), once a device uses a token, the priority would drop to the seventh and lowest level. As the system passes the free token around, every time the token passes a device, the priority count increases by one until it reaches level zero, or "transmit ready." If the device has a packet pending, and a free token passes, it can now grab the token for itself. If an emergency occurs, the system can ignore the priority level and use the next free token.

Token protocols can be complex. For example, what happens if a device dies while it has the token? Also, when a user powers up the system, which device instantiates the token? Despite these issues, token passing works and can provide a self-healing system for highly reliable backplanes.

Sample design

Many microcontrollers today, such as the Zilog EZ80 Acclaim and the Freescale MCF523x, have a built-in Ethernet MAC, which connects to a PHY (physical)-layer chip using an MII (media-independent interface). The MII has a 4-bit-data, nibble-mode interface along with a simple serial bus to configure the PHY. You can build a custom bus controller in an FPGA that has an MII to emulate an Ethernet PHY. The FPGA-based controller handles the bus access or token management, serialization and deserialization, ring management, healing, and clock generation and recovery.

This design can enable a system to transport Ethernet packets as if the backbone were Ethernet. Additionally, TCP/IP over Ethernet is well-defined and provides a simple method for implementing an Internet-ready backplane (Figure 5). The FPGA emulates the functions of the Ethernet PHY and allows the MAC inside the microcontroller to function as if connected to a normal Ethernet network.

Using LVDS eliminates many of the problems of noise in industrial environments. Also, speeds can increase through the use of current-mode drivers and lower voltage swings. In addition, by serializing data and reducing the number of interconnects between modular devices, LVDS increases reliability by avoiding connector failure. The sample design requires only eight upstream and eight downstream connections, providing a 100-Mbps, packet-based, Ethernet, self-healing ring topology.


Author Information
Richard Zarr is the worldwide program manager for technology-partnership marketing at National Semiconductor (Santa Clara, CA). He has a bachelor's degree in electrical engineering from the University of South Florida (Tampa, FL). His career involved designing computers and communication equipment before he entered applications engineering in 1984. His current focus is developing technology partnerships between National Semiconductor and other corporations requiring high-performance analog technologies.



ADVERTISEMENT

ADVERTISEMENT

Feedback Loop


Post a CommentPost a Comment

There are no comments posted for this article.

Related Content

 

By This Author

There are no additional articles written by this author.


ADVERTISEMENT

Knowledge Center



Technology Quick Links

EDN Marketplace


©1997-2008 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other Reed Business sites