Deterministic or Probabilistic Communication: Does it Really Matter?

Deterministic communication networks are important for all automation systems. Looking at probabilistic communication networks, however, the answer is a bit more involved: Very likely the best solution is a combination of a low-level deterministic system combined with Ethernet—a probabilistic network that has been given deterministic properties by virtue of some clever hardware.

Field devices with integrated switches simplify the construction of Ethernet systems that exhibit deterministic behavior. IDENT Control Compact is an RFID controller with integrated three-port switch (one internal and two external) that not only creates collision-free domains but also enables the simple setup of linear Ethernet networks preferred in most automation systems.

Networks, by design, fall into either of two categories: deterministic or probabilistic. A deterministic system is designed such that for a given I/O structure an upper limit to the update time can be calculated exactly. Under normal conditions deterministic systems are allowed to be faster than their limit update time, but will never be slower; you are always assured that such a system will never perform worse than this worst case time.

How much the update time deviates from the upper limit is called jitter. Less jitter is better since this gives you the ability to make simple yet precise calculations concerning the real update time of a machine. Limiting the jitter can be especially important in controlling outputs like valves and electro-mechanical actuators.

Clever solutions have been developed for deterministic systems that enable perfect synchronicity between all outputs on the network; this is by no means trivial since output devices are controlled (in a Von-Neumann style) one at a time and thus output states from the PLC are sent back to back with small time intervals. Using these features, it is possible to coordinate activation and deactivation of operations that are controlled by multiple outputs, even when they are on different modules on the network.

One deterministic network is AS-Interface. With AS-Interface and its Master-Slave communication principle, the update time is provided with a simple equation relating the number of network nodes to the update time: Tupdate = (n+2) x 156 μsec.

No such formula can be provided for an Ethernet system where it is possible that two nodes on the same network start to transmit data at the same time. The probability of such an initial data collision is influenced by a number of factors. A real-life example of a probabilistic system frequently encountered is that of a person taking his car to the office. On a good day with light traffic this person will most likely be faster than the person walking and taking the train. During heavy traffic hours the situation is different. Now the total travel time depends on factors like traffic density, weather, and accidents along the way. The best one can do is to calculate a minimum time based on distance and maximum legal speed, but as everybody living in Los Angeles, Chicago, or Boston knows, it is not possible to predict the maximum travel time.

Collision management
To handle data retransmissions Ethernet uses CSMA/CD (Carrier Sense Multiple Access/Collision Detection) where, after an initial collision, both parties “sense” the data collision and then pause for a random time period known as backoff delay before attempting to retransmit their information. And since there is inherently nothing that would keep the two from selecting the same backoff delay, there is a certain likelihood (in fact it is 50%) that the second attempt could again result in a data collision. Fortunately, Ethernet uses a method by which the backoff delay is increased after each collision, eventually allowing both parties to send their information with near certainty. Unfortunately, the message delay between sender and receiver has to increase significantly. This procedure is called truncated binary exponential backoff, where the number of random time slots increases as 2n for the nth collision. On Ethernet, n is truncated at 10 resulting in a maximum number of 1024 possible intervals and the number of retry attempts is limited to 16. In case 16 retries is not sufficient internal error messages are generated.

As a consequence of these collisions and the random nature of the transmission retries, a question like “What is the time one has to wait until a message is transmitted with certainty?” cannot be answered. The only question one can address is “What is the likelihood that my message will make it in a certain time?” Clearly this is not satisfactory and, in the past, increasing the raw speed of Ethernet to Gbit and 10 Gbit versions was an obvious way to address the issues. The biggest drawback of this brute force method is the increase in hardware and cabling cost. But even with overwhelming raw speed, professionals agree that Ethernet must be used differently in automation environments.

Combining Ethernet with AS-Interface at the I/O level gives engineers the ability to use any non-safe PLC and still benefit from all the advantages networked safety provides. All safety relevant operations are processed at the AS-Interface level. Here, safe input and output devices are combined to perform the required safety function up to CAT4, SIL3 and soon ISO 13849. Diagnostics operations and machine control is performed with a conventional PLC.

While AS-Interface and its master-slave behavior is inherently collision free, Ethernet must be used with network switches (and not hubs), creating collision domains with just one participant. Such a setup is frequently called collision-free. Looking closely at it, though, shows that while collisions are unlikely they are still possible as long as the communication is half-duplex. In a full-duplex environment, collisions are completely avoided. This approach not only guarantees that each RFID controller is in its own collision domain, it also solves a problem frequently overlooked when considering Ethernet: The only topology allowed with Ethernet is the star-topology, which is not well suited for automation systems used along linear conveyors. The use of Ethernet switches to enhance determinism and allow line topologies comes at a price—literally.

Adding a switch to an RFID controller, HMI, drive, or other high-end product may be economically feasible, but doing the same to a sub $100 distributed I/O module or a networked proximity sensor is probably not possible. The networking solution of the future will most likely be one that combines low-level deterministic offerings, where in quantity, modules can be offered at prices below $10 per I/O point, and upper level Ethernet structures move larger amounts of data quickly. By consolidating a large number of binary devices at the Sensor-Actuator Level the added cost of making Ethernet deterministic is manageable while the flexibility of the low-level solution further reduces the cost and complexity of the entire system.

Here is a simple Ethernet network using switches to give Ethernet deterministic properties. While collisions are unlikely they are still possible as long as the communication is half-duplex. In a full-duplex environment, collisions are completely avoided.

Why is combining Ethernet with a low-level I/O solution the way of the future? Low-level deterministic I/O solutions consolidate all machine I/Os at a gateway to Ethernet. Thus, all this information fits nicely into a single Ethernet data packet, reducing the network loading considerably. Depending on the specific low-level I/O solution teamed up with Ethernet, other planning, installation, and maintenance advantages benefits can be realized.

Because a single gateway may handle hundreds of field I/O, even large installations typically need only a few of them, making the additional cost of integrating a switch necessary to make Ethernet collision free a non-issue.

Safety, an added benefit
The two-tiered approach offers another advantage for safety and the upcoming changes from EN954 to ISO 13849. AS-Interface not only allows conventional, non-safe, I/O data to be collected and moved up to Ethernet, it also enables functional safety devices (e-stops, door interlocks, light curtains) to be directly connected to the same network. Networking safety along with conventional automation devices can reduce wiring by 90% while adding functions not possible in traditional hardwired safety.

Imagine a simple system with one safety e-stop and one safety door interlock switch. By code, if the safety function has been activated with the e-stop, it is necessary to perform a manual reset after the e-stop has been set back into its released state, after the e-stop button has been pulled out. The door interlock switch however, may be auto restarted. Since conventional safety relays either auto restart or are designed to be restarted with a reset, this trivial installation requires two independent safety relays ANDed together at their safe outputs.

Not so when the safety devices are part of AS-Interface. In this case the safe data is transmitted through the network and the AS-Interface safety controller (called SafetyMonitor) evaluates this information. Both safe and non-safe devices are part of the same network. The data from the reset button can easily be taken into account by a single SafetyMonitor, making the door interlock switch auto restart while requiring the manual reset for the e-stop. Similar simplifications apply when some inputs need to result in delayed deactivation of the safe outputs while others are supposed to immediately turn them off. Again, conventional hardwired approaches require two safety relays while AS-Interface can accomplish this with just one SafetyMonitor. Using a safety PLC would certainly result in similar logic flexibility but at a much higher cost.

Pepperl+Fuchs
www.pepperl-fuchs.us

::Design World::