Deterministic networking: from niches to the mainstream?

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.

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:

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.