1660317266547 Bxgarticle

PlantPAx all aces for Texas natural gas production

Nov. 3, 2021

It might seem like natural gas comes ready-to-use out of the ground, but it actually requires plenty of separation and treatment to prepare it for consumption. No one knows this better than all the producers operating wells and plants in Texas, who must remove hydrogen sulfide (H2S) and carbon dioxide (CO2), dehydrate (dehy), cryogenically cool, recover natural gas liquids (NGL), and filter other residues before compression and transport—and all of these applications require process control and automation.

“Each of these treatment processes affects the others, which adds unique control challenges, and requires different technologies,” said Jerry Christian, owner at BXG Systems, a system integrator in New Caney, Texas. “Many natural gas companies have multiple plants with multiple types of control system hardware and software platforms. These varied control platforms are typically provided by multiple system integrators, and there’s often a lack of understanding among them about different natural gas processes. They also have many different solutions for the same problem, so it’s hard to understand what’s the best approach for each production challenge.”

Christian and Jeffrey “Scott” Cayton, technical director at BXG, presented “PlantPAx in natural gas” at this week’s Process Solutions Users Group (PSUG) meeting, just prior to the start of Automation Fair 2021.

Seeking consistency in chaos

Christian reported that end uses must also deal with functions that depend on available hardware and software; system architectures that aren’t well-defined and let in minimalistic, off-the-shelf solutions; widely varying network solutions; inconsistent and unoptimized alarm management; and inaccessible historical data that’s also hard to understand.

“A lot of natural gas data from transmitters used to be on circular charts that were stored in boxes,” added Christian. “But what good are these ‘databases’ if we can’t access and use their information?” 

Meanwhile, he added that system integrators often aren’t familiar with natural gas processes, and find that much of the typical user’s documentation, such as such as cause-and-effects, P&IDs and electrical schematics, is either absent or out of date. Plus, many integrators don’t visit with all of the stakeholders in a new control system, such as operations, maintenance, engineering and IT, so many of their needs are either ignored or unknown.

“This is why we and our end users want a common approach to process control software, as well as hardware and software that run consistently,” said Christian. “For instance, many natural gas plants run the same dehy process, but they’re all programmed differently by different system integrators. Or some sites don’t have remote I/O and some do, while others are using unmanaged switches. This is variability we want to reduce. However, it’s difficult for users and integrators alike because software isn’t their business. So, networking get neglected, and even critical pieces like alarm management don’t get addressed. We focus on the wants and requirement of whoever calls us, but there are many other people touching these processes, and we should be trying to meet their needs, too.”

Streamlining with software blocks

To solve these varied and persistent problems, BXG began using the PlantPAx DCS from Rockwell Automation. As the platform anchoring control systems for BXG’s clients, PlantPAx provides:

  • Process Objects library with proven software blocks;
  • Standardized approach to I/O handling that includes scaling, gating and alarm configuration;
  • Standardized motor control approach that includes two-speed motors, reversing motors, and variable frequency drives (VFD);
  • Standardized approach to process control valves by using PlantPAx’s p_PIDE block that includes cascading loops, ratio control and override configuration; and
  • Standardized approach to entire gas industry processes, such as dehy bed sequencing by using PlantPAx’s p_Seq block.

“We went all in with PlantPAx because it addressed everything we were looking for, such as software blocks with proven code at the PLC level,” explained Christian. “For example, we were able to put in 30-second gates to temporarily disable alarms, so low flows could proceed without shutting down a pump. We used to have to write lot of ladder logic for PLCs by hand, but now we can use PlantPAx blocks for I/O handling, scaling, gating, motors, valves and other functions. We can even use PlantPAx blocks for entire processes, such as dehy sequencing. And, as PlantPAx advances, we just upgrade along with it.”

Prove in use at midstream plant

Cayton reported that BXG recently implemented PlantPAx and FactoryTalk software and supporting components at a leading, midstream, natural gas plant near Odessa in west Texas. The plant operates two production trains, including one that produces 60 million cubic feet per day, and another that produces 200 million cubic feet per day. Its separation and treatment processes rely on about 2,000 I/O including 800 analog I/O and 1,000 discrete I/O.

“We were asked to look at this plant’s PC hardware, PLCs, HMIs, historian, alarms and network, and review where they wanted to go,” said Cayton. “They had a mix of PCs in the control room, including two Dell servers  running standalone FactoryTalk View software on two different Microsoft operating systems; several operator workstations with standalone HMIs and minimal hardware configuration such as RAM; two different engineering workstations; and one Wonderware workstation running InTouch software.”

Cayton reported that each of the PCs, workstations and HMIs in the plant’s control room weren’t networked together, and typically had their own alarm databases that had to be acknowledged individually. Unfortunately, they were generating alarms that had to be documented every few seconds—totaling about 950,000 alarms per month.

“This plant had been trying to get up and running more effectively for a long time, but it needed multiple operators per shift, and was burning through operators and resources because of all the alarms,” said Cayton. “This was also leading to at least one unscheduled downtime event per day—and sometimes multiple events per day—which were wearing out the team. We had to rationalize these alarms, get to the few true ones, and also get rid of all these random PCs because they were driving their users crazy.”

Get the best of Automation Fair 2021

The editors of Control, Control Design and Smart Industry are reporting live from Automation Fair. When the event comes to a close, the editors will compile a report of the best, most important coverage from the event. Register now to pre-order the report and be among the first to receive it in your inbox. Pre-order your copy now.

In addition, the presence of so many PCs and HMIs made it difficult for operators to navigate through the plant’s many display screens to reach the information they needed to make decisions. This complexity also made it hard to train new operators.

“If you have too many alarms, then you’re training your staff to ignore or turn them off,” explained Cayton. “However, when a truly important alarm comes along, you don’t want to ignore it because that’s how you end up with loss of life and property. This plant’s alarms were scattered, and you couldn’t see their history. And when the plant had a fire, the systems weren’t synchronized, so it was a nightmare to piece together what happened.”

Saved by simplification

Cayton added the BXG began by implementing fault-tolerant and fully redundant ftServer software and servers from Stratus. Running as virtual machines (VMs) on the Stratus systems were FactoryTalk Historian SE, FactoryTalk VantagePoint Server, and FactoryTalk Alarm & Event database software packages from Rockwell Automation, which were joined by updated SQL Server and SQL Server Reporting Services (SSRS) software. Other VM images include FactoryTalk View SE Server and FactoryTalk Asset Centre Server, with a spare image of FactoryTalk View SE Server.

“The plant manager is now on SSRS a lot because it lets users see the most frequent and stale alarms, and identify actual problems to solve,” said Cayton. “SSRS is really outstanding because it enables canned reports, and its users just love it. The plant has gone from needing multiple people per shift in the control rooms to needed just one. In fact, we were recently there, and they went one hour without a single alarm.

“They’re also pleased that alarms with PlantPAx match the ISA’s color-matching strategy for prioritizing severity. Previously, every alarm was red, but now a red one means something is really broken.”

To achieve greater consistency, BXG rewrote many of the plant’s functions using PlantPAx, and sometimes called in affected skid builders to help. Cayton added these revisions were seamless to the operations and were completed without disturbing the operators.

“We went from 40 process screens to 11, and now the operators aren’t more than two clicks from anywhere in the plant they want to be,” said Cayton. “We also added ultrawide screens and redrew their display, so the operators could see all their process functions on one screen.”

Cayton and Christian reported the plant’s operators and managers can now concentrate  on improving their essential processes, and are so relieved and happy with PlantPAx, FactoryTalk and their other new solutions that they’re planning to standardize on them, including their export to two other natural gas facilities.

“After implementing each of these changes, the control room experienced a much calmer atmosphere,” concluded Cayton. “They could view their KPIs, focus on improving their natural gas processes, and make better decisions more quickly, which dramatically reduced their unscheduled downtimes.”

About the Author

Jim Montague | Executive Editor

Jim Montague is executive editor of 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®.