Deterministic networking: from niches to the mainstream?

Bernard Cole

February 11, 2013

Bernard Cole

There was a time before the Internet began turning into a means of distributing mass entertainment and infotainment when there was a clear delineation between two types of network operation.

One type included the real time and deterministic networks that served the specialized needs of industrial/ machine control and factory automation. The other included asynchronous networks in business and personal computing where the need was for reliable delivery and for which determinism and precisely timed delivery was a secondary consideration.

This is changing rapidly as noted in “Making networks more deterministic,” the topic of this week’s Embedded.com Tech Focus newsletter.

Many of the early factory automation and machine control oriented networks operated according to the same rules of real time and deterministic operation of the devices they linked. Starting as ad hoc and mainly proprietary solutions, out of this came a variety of so-called controller area networks standards such as CANopen, ControlNet, DeviceNet, Modbus,  Profibus, and the fieldbus.

At the same time, network communications between non-real time systems in business and data processing began to standardize around such LAN-based topologies such as Ethernet, which used something very similar to the current TCP/IP internetworking protocol suite.

Unlike the controller area networks, the TCP/IP protocol is probabilistic and asynchronous in nature. It was - and by in large still remains - a network environment where the aim is to guarantee delivery, but not within any particular, or even predictable, time frame. Even with the development of enhancements such as the Network Time Protocol (NTP) for clock synchronization between computer systems, it is certainly not within the fine-grained microsecond and millisecond deterministic boundary conditions most embedded control operations need.

But Ethernet and the TCP/IP suite have one advantage that these real time network protocols did not: they are ubiquitous, which provided two things that embedded developers needed: 1) a network protocol that if engineered correctly would work in a variety of environments and allow communications between them, and 2) a protocol that was low in cost to implement because of its ubiquity and the resultant economies of scale.

But starting in the late 1990s and through most of the last decade there have been increasing efforts to adapt the Ethernet protocol to the real time and deterministic requirements of embedded control applications.

Initially it was just a matter of physically configuring stations or nodes into a closed Ethernet collection and limit the number of nodes until the response times were within the deterministic requirements needed. This way the time it took for each to do the time consuming handshaking to ensure delivery could be minimized and, more importantly, predicted.

Even more fine-grained were early attempts to take the underlying TCP/IP protocol apart and use only those portions, such as UDP - that do away with the time consuming process of acknowledging receipt to guarantee delivery - in a closed environment to handle transmissions in a much more deterministic way. Several articles dealing with these techniques include:

Real time Ethernet
Speed packet throughput with compressed UDP
Internet connectivity: stacking the odds in your favor
TCP-IP for transactions

But most useful to embedded developers was the creation in 2002 of the IEEE 1588 and its precision clock synchronization protocol, the topic of a six part series on Embedded.com: “Basics of real-time measurement, control, and communication using IEEE 1588.“ Using it as the starting point, many of the industrial control network protocols have adapted elements of the PTP and out of that has emerged what is called the Industrial Ethernet.

Joining Ethernet in adapting to a networking environment that requires more and more real-time deterministic performance have been any number of other specifications and standards. One example is the Firewire serial interconnect specification which started its life as an alternative to the Universal Serial Bus as a way of networking various peripheral and storage functions to a main server or desktop computer.

With the development of IEEE-1394b-2002, Firewire now has several key features that, when coupled with SAE Standard AS5643 creates a deterministic, robust, and redundant distributed system architecture that meets most of the requirements for a hard real-time control bus and networking protocol. The details of its use in many demanding aerospace and defense designs are described in “IEEE-1394 and AS5643 bring deterministic networking to high reliability Mil-Aero designs," the lead article in this week’s Embedded.com Tech Focus newsletter.