Real-time control over Ethernet

PowerDNA (which refers to distributed, networked automation and control) is a system that aims to set new benchmarks for hard real-time I/O over Ethernet

Over the past few years, Ethernet has come to dominate factory-floor networking just as the PC backplane came to be the hardware platform of choice for industrial control. The reasons are much the same. First, the commercial market created the volume that brought prices to the lowest possible level. Next, because these technologies are so widely used, most engineers are familiar with them, have a wide range of design tools and find it easy to create systems.

Meanwhile, engineers can find Ethernet chips for a few dollars that allow them to embed networking capability into remote I/O units, while almost every host computer comes with an Ethernet port as standard equipment. These network interfaces can work with inexpensive twisted-pair cable, again helping control implementation costs. With Ethernet, engineers can also employ industry-specific protocols, such as the very popular Modbus/TCP factory-floor Ethernet variation.

Finally, with commercial Ethernet, engineers can tie their automation systems into an enterprise-wide system that includes tools that assist in overall plant management and procurement efforts.

De-facto standard

These various factors have led to various Ethernet implementations becoming the de-facto standard for factory networking. Venture Development Corp states that worldwide shipments of Ethernet-based distributed I/O products in the year 2000 was $246 million, and those researchers predicts rapid growth to a level of more than $800 million in 2005. Similarly optimistic for this growth, ARC Advisory Group projects that 4.7 million Ethernet-enabled controllers will ship in 2005, up from 116,000 in 2000.

Developed by United Electronic Industries, the modular PowerDNA system is optimised for real-time control applications requiring both large numbers of analogue and digital I/O points as well as extremely fast response.

Thanks to the patent-pending DaqBIOS protocol, which transfers commands and data over Ethernet hardware in a deterministic fashion, a PowerDNA system consisting of a PCI/PXI-based controller and multiple distributed nodes with more than 800 mixed analogue and digital I/O points can guarantee a response in better than 1ms. Continued over page

A wide selection of I/O configurations is available from the factory. "For several years engineers could purchase Ethernet-based I/O but with insufficient real-time response to address future system requirements. However, the development of the PowerDNA DaqBIOS protocol has solved this problem," claims Shaun Miller, president of UEI.

At the highest level, PowerDNA consists of a central controller card that fits into a host PC or PXI/CompactPCI system, and it supplies either one, two or four Ethernet ports. To each of these ports, users can attach as many as 64 I/O cubes.

Each I/O cube in turn consists of a metal enclosure that contains a communications layer, a CPU layer with an embedded real-time kernel, and positions for either three or six I/O layers. Customers select the desired functionality from a range of I/O layers, which are factory installed, configured and calibrated.

Users program their applications in C using a straightforward API that provides access to all hardware functionality. After compiling an application on the host PC, engineers can download it to an I/O Cube in several ways: over the Ethernet, over a serial link, over a USB port or even with a PDA equipped with an infra-red link. The application can run under host control or as a standalone task.

The central controller resides in a PC or PXI/CompactPCI system, and it is equipped with a 333MHz PowerPC processor, 128Mbyte of RAM and 64Mbyte of CompactFlash memory that stores programs and a mini-OS. The controller offers from one to four 100BaseT network interfaces, each of which can control as many as 64 I/O modules. The controllers can run the high-performance DaqBIOS protocol, but they also support standard protocols such as TCP/IP that allow users to integrate factory-floor tasks with an enterprise system. As for software, the central controller executes QNX, real-time Linux or VXWorks. And even when supporting hard real-time operation, 80% of the processor's time is available to run a user application.

Physical layers

Each I/O cube starts with a CPU layer, which contains a ColdFire CPU running at 66MHz plus 16Mbyte of SDRAM and 4Mbyte of Flash memory. This layer also provides an IrDA interface so users can field-configure the CPU module with the assistance of any infra-red-equipped PDA.

Next, the I/O cube also comes with the network layer, which provides two RJ45 jacks for daisy-chaining the Ethernet link to other I/O cubes; it also provides a USB port and a serial port over which users can download new programs or upload process data. Users can also daisy-chain power from cube to cube within this layer.

The small unit also holds as many as six I/O layers, each connecting to the CPU layer over a 32bit 33MHz bus with opto-isolation, so errant field signals cannot disrupt system operation. A five-layer I/O cube with room for three I/O layers measures 4x4x4in, whereas the eight-layer version is 6x4x4in.

Cube configuration

When configuring an I/O cube, users can select from several I/O layers: analogue input (16 channels, 16bit resolution, 100ksample/s digitisation rate); analogue output (eight channels, 16bit resolution, 100ksample/s update rate); temperature measurement (24 channels, 24bit A/D, direct sensor connection); digital I/O (with either eight or 16 bi-directional lines); communication (eight RS232/485 ports); and four-axis motion control. Soon to be available are layers that supply mass storage and battery operation, making the unit ideal for stand-alone data logging or remote/vehicular operation. The central controller communicates through the I/O cube's network layer to individual I/O layers using the patent-pending DaqBIOS protocol. It employs either isosynchronous operation with time-sharing, or variable timing in a broadcast scheme, or both.

Because the protocol is optimised for process applications, the overhead per message is extremely low and the scheme achieves impressive response times. For example, in a system with 16 modules (3072 I/O points) using variable timing, the time required to communicate with all I/Os is less than 1ms.

The DNA-CC central controller starts at £1750 with one communications port; and an I/O cube with the network and CPU layers along with three open I/O-layer positions costs £575; an I/O cube with six open I/O layers sells for £675.

The I/O layers themselves range from GBP 260 (eight-channel analogue output) to £1170 (four-axis motion control).

 

Ethernet inadequacies

Real-time enhancements to Ethernet are necessary to meet the hard real-time requirements of a select set of mission-critical applications. When many people hear the term Ethernet, they immediately think of the scheme that interconnects office equipment. They don't realise that the actual Ethernet spec dictates only the first two of the 7-layer OSI model, the physical and datalink layers. In essence, the basic Ethernet standard specifies cabling and hardware interfacing as well as the framing, addressing and check summing of data packets. The popular 'office Ethernet' takes the standard a step further by adding TCP/IP (where the Internet Protocol is responsible for moving packets of data from node to node, and the Transmission Control Protocol is responsible for verifying the correct delivery of data from client to server). Together Ethernet and TCP/IP implement all seven layers of the OSI model. A key part of the core Ethernet spec is determining how to deal with the case when multiple network devices want to use the same pair of wires at the same time. Ethernet uses Carrier Sense Multiple Access with Collision Detection (CSMNCD). If a node sees the wire is idle, it begins transmitting, but if the wire is busy, it waits a few moments and checks again if it's become free. It's also possible that two nodes might want to start transmitting as soon as the wire is free, a condition known as a collision. In that case both nodes back off, wait for a random time and try again. Because it's impossible to predict exactly how long a collision resolution will take, network access is not deterministic. Such collisions might be rare and resolving them could take only a few milliseconds, and that level of performance is fine for the office as well as for some non-critical factory applications. However, it fails absolutely for mission-critical systems or processes where you can't afford to take the chance that a task might ever fail to perform within the allotted time. One way to overcome this problem is to take advantage of Ethernet's physical and data-link layers but to use them in such a way as to avoid the non-deterministic behaviour that arises from the collision detection and avoidance mechanisms employed in commercial Ethernet schemes. With the DaqBIOS protocol, UEI has extended the upper layers of the communications model, which guarantees hard real-time performance, even on a factory network with hundreds of I/O points, as well as full compliance with IEEE 802.3 standards. DaqBIOS is fully transparent for any device not aware of it. What's really real time? Here it's crucial to clarify what UEI means by real time. One popular definition dictates that a real-time system must produce correct responses within a definite time limit or else performance degradation or malfunctions result. This definition is vague and imprecise because there's no boundary to the time limit, which could theoretically extend to several seconds, and what constitutes a malfunction is a matter of interpretation. Thus engineers try to be more precise by referring to soft and hard real-time systems. With a soft real-time system, they mean that there's a very good probability that the system will respond within an acceptable amount of time. The possibility remains that a given task might not execute within the dictated time parameters, but in such systems an occasional failure to meet a deadline doesn't compromise program correctness. In a soft real-time system, you take a best-effort approach and minimise latency from event to response as much as possible while keeping throughput up with external events overall. In contrast, in a hard real-time system the deadlines are fixed and the system must guarantee response within a fixed and well-defined time. This is referred to as deterministic performance. The system must satisfy deadlines on each and every occasion. For instance, if you're controlling a printing press with paper moving through at hundreds of metres per second, you want to be absolutely sure that the system can detect and compensate for process variations within microseconds.

United Electronic Industries
m122@industrialnetworking.co.uk