1660238359003 Johnrezabek

Is redundancy still redundant?

Feb. 1, 2021
Contemplating field network redundancy requirements for an ‘EtherBus’ future

“Someone hustle to the nitrogen plant and hit the blue button,” came the message over the plant radio. A power interruption, although brief, left the facility’s operators scrambling to bring their plant to a safe and quiescent parking place with hopes for a quick resumption of production. To everyone’s dismay, the decades-old nitrogen separation plant was never equipped with any provisions for an automatic restart after a loss of power. Total power outages were thankfully rare, but the end user’s chemical facility spent some time and effort to detect that its nitrogen and air supplier’s PLC needed a reset, and to locate that blue button. Oy vey.

Their petrochemical plant had been constructed according to specifications adapted from their petroleum-refining-heritage neighbors; in both cultures, high availability was crucial. So, how did their plant end up with this single point of failure that corroded their plant's reliability? Conserving capital is irresistible, so outsourcing a utility like compressed air and nitrogen was attractive. The degree to which the owner’s standards could be instilled in the third-party’s cookie-cutter air separation plant was limited. Some incentives and penalties for reliability or lack thereof could be negotiated into the supplier’s contract, but these did little to inspire investment in reliability.

With emerging technologies to enable digital integration of field devices, how much capital and engineering effort should one spend making their new networks “bulletproof”? New fieldbus solutions like IEEE 10BaseT1L or Advanced Physical Layer (APL) promise to become practical for real-world deployment—so do we need to conceive innovative architectures that support improved availability levels? Conventional Ethernet installed to integrate PLCs, motor controls, analyzer networks and similar appliances can typically tolerate service outages of minutes, hours and even days, as connected devices can function adequately, maintaining safe production of product, without digital communications with the host DCS. With long-available ring topologies a degree of redundancy is achieved, primarily for cable/fiber and media converters. These solutions are not without their own risks, and may themselves rely on intelligent switch firmware—whose execution may not be as fault-tolerant as we’d like.

In the early days of DCS imaginings, the concept of single-loop integrity was bandied about. Simply put, the idea is that no single fault shall affect more than one loop. Since the distribution of the DCS was less than distributed (many control loops executed in one controller), this led to redundant controllers and redundant I/O, which we largely take for granted.

Fieldbus deployments, with multiple devices communicating on the same twisted pair and power supply, compelled us to reimagine redundancy. Redundant-ring topologies in FOUNDATION fieldbus and Profibus PA networks are possible but rarely deployed; we conceive of the single-pair trunk in the same vein as its conventional multi-pair counterpart. And many early adopters took pains to carefully segregate critical loops onto more highly managed segments. But on the field side of the fieldbus trunk, few active devices had an impact on overall network functionality.

If the paradigm is to use existing, nominally 18 AWG twisted-pair fieldbus cable for APL, the inherent limitations of Ohm’s Law will likely dictate a smaller basket of eggs—i.e., it remains to be seen how many devices we’ll be able to power on a single pair in a hazardous area. Power-hungry devices like Coriolis flow or mag meters want to offer two-wire solutions. Perhaps worrying how to construct a network that supports dozens of field devices on a single pair (or single redundant ring) won’t be necessary.

That there will be a proliferation of active devices, e.g. APL switches, field power supplies, and more, still seems to loom in the future; perhaps we’ll have one switch for every 12-16 devices. If the hope is for a single, unified twisted-pair fieldbus (finally), it will need to support critical controls as well as equipment diagnostics. Let’s hope network infrastructure reliability doesn’t need to be compromised for the sake of conserving capital.

About the author: John Rezabek
About the Author

John Rezabek | Contributing Editor

John Rezabek is a contributing editor to Control

Sponsored Recommendations

IEC 62443 4-1 Cyber Certification – Why ML 3 is So Important

The IEC 62443 Security for Industrial Automation and Control Systems - Part 4-1: Secure Product Development Lifecycle Requirements help increase resilience for control systems...

Multi-Server SCADA Maintenance Made Easy

See how the intuitive VTScada Services Page ensures your multi-server SCADA application remains operational and resilient, even when performing regular server maintenance.

Your Industrial Historical Database Should be Designed for SCADA

VTScada's Chief Software Architect discusses how VTScada's purpose-built SCADA historian has created a paradigm shift in industry expectations for industrial redundancy and performance...

Linux and SCADA – What You May Not Have Considered

There’s a lot to keep in mind when considering the Linux® Operating System for critical SCADA systems. See how the Linux security model compares to Windows® and Mac OS®.