Exploring the love/hate relationship with distributed control

'To the degree networks and standards can provide easy, consistent and seamless access to device-resident controls, the vision of truly distributed control may finally dawn upon us.'

By John Rezabek

Every compressor in the facility went down at once that day, when a PLC redundancy switchover didn’t transfer in time. The engineers didn’t know that each P453 remote I/O processor had a dip-switch-selectable timeout setting—if it didn’t hear from the logic solver before the timeout, all the associated I/O would go to the zero power state. And so they did, when the startup team decided to invoke a switchover one day, much to the dismay of the commissioning manager for the new unit.

Before PLCs, compressor interlocks were all solved in local panels using relay logic. This “natural” distribution of logic solving lent a certain fault tolerance to the process; at least (barring a total power outage) only one critical piece of machinery would go offline at a time. The disadvantage was, interlocks implemented with hardwired relay logic were difficult to configure, costly and labor-intensive to build, difficult to troubleshoot, difficult to modify, and subject to mechanical assaults on reliability in the form of lose wires, vibration, corrosion and unseen jumpers. This was why the early adopters were eager to move logic to the magical PLC.

2016 State of Technology Report: Oil & Gas

Fortunately for us, it took less than 10 years for PLCs to become powerful and inexpensive enough for each compressor to have its own, individual, local, dedicated PLC. This was a great capability, but it also introduced a new challenge: every little skid that arrived, from truck loading to wastewater filters, had a different little PLC aboard. Some used ladder logic and some used weirdly structured text reminiscent of HP calculators’ “reverse Polish.” One site tried to stem the divergent solutions by specifying, for example, “all logic shall be solved by Modicon 984 PLCs,” only to find that 1) there were several “grades” of that generation of 984s, and 2) systems integrators that favored another PLC wanted to charge a premium for the deviation, but frequently didn’t excel at programming the PLC of choice. Modbus was still developing as a de facto standard, so networking the growing and divergent field of PLCs to the built-for-purpose DCS host was expensive and complex, requiring painstaking mapping of PLC coils and registers for the DCS to display.

Every little skid had a different little PLC. Some used ladder logic and some used weirdly structured text reminiscent of HP calculators’ 'reverse Polish.'

The DCS, which I’ll emphasize stood for “distributed control system,” was itself more centralized and less distributed than the network of little PLCs out in local panels and skids. But few entrusted the PLC to do much closed-loop control, since most of the analog measurements were wired to the centrally-located DCS I/O, and control could be solved with greater determinism than the master-slave polling network of Modbus over RS-232/485. So critical, closed-loop “control,” indeed nearly all PID control, remained centralized despite the “DCS” moniker. And so it remains.

But today, I can go on Amazon and buy a credit-card sized Raspberry Pi, already in its third generation, for less than $50. You can load a stripped-down Windows 10 OS on Raspberry Pi, and I have little doubt such a platform could solve PID or even invert a matrix for model-predictive control. Not that you would, but the point is that astounding computing power and networking capability have become cheap and ubiquitous. “Control at the edge” is becoming part of the IoT vernacular as it pertains to access control and security, but also because microprocessor-based devices at the edge are smart enough to invoke actions—to solve logic or do closed-loop control—without having to “phone home” to a central host or human operator.

Process control professionals have had “control at the edge” since the days of local pneumatic controls, and this heritage lives on almost unnoticed in every valve positioner with a servo solving proportional or PID to position the valve stem where it’s directed. While we might not have trusted PID to 1990s-vintage PLCs, why not empower valve positioners and their ilk to execute rudimentary control loops? To the degree networks and standards can provide easy, consistent and seamless access to device-resident controls, the vision of truly distributed control may finally dawn upon us.

Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

  • Great article! I work with many smaller plants currently operating manually & trying to add automation. The choice for entry level PID controllers seems really bad. A standalone PID controller that drives barely two loops (4-20 mA) costs $400. The cost per loop of adding a controller is very high. Just to implement simple, primitive PID logic this sounds massively overpriced. Would love to hear opinions or comments!

    Reply

RSS feed for comments on this page | RSS feed for all comments