Controls automation achieves efficiency with edge controllers

In regional power generation systems, combustion turbines have become a mainstay in recent years. These powerful, complex machines are used in two ways:

in combined cycle configurations for base load generation;
in simple cycle arrangements for peaking plants, which handle mid- to high-demand power fluctuations.

RDI Controls is a Pennsylvania-based engineering services company that provides fully engineered retrofit packages for industrial and aeroderivative turbine control systems, including demolition, installation, control valve and field device integration, water injection, nitrous oxide (NOx) emission mitigation, generator protection and auxiliary/balance of plant (BOP) controls.

RDI was invited by a customer to bid on a project to retrofit three turbine peaking plants, each equipped with Westinghouse W301 and GE Frame 5LA combustion turbines in a simple cycle configuration with each operating in the 20 to 30 MW range (Figure 1). The previous iteration of the control system was designed with a pair of programable logic controllers (PLCs) for each of the six turbines, but, due to repeated control and maintenance issues, the customer needed a better-engineered solution that was easier to troubleshoot and more reliable (Figure 2).

Turbine tolerances and safety

Figure 2: The customer needed a better-engineered control solution that was easier to troubleshoot and more reliable.

Peaking plants trade off efficiency for responsiveness, generating significant waste heat and losing work to the operation of the turbine rather than power generation. To minimize these losses and reduce stress on the system as a whole, it is critical to keep the turbine running within tight tolerances during startup and operation.

Large, rotating machinery operating at high speeds and temperatures also require many safety considerations. Should the system fail to limit the speed of the turbine, for example, it might break apart, so RDI’s solution needed to include appropriate failsafes to protect against overspeed events and react to load rejections.

And, although each turbine would have its own control system, every pair utilized common site subsystems, which would need to be integrated into the primary controls. These included ammonia control systems, which RDI had previously retrofitted using Opto 22 SNAP programmable automation controllers (PACs) and electric starter motor controls that ran on Allen-Bradley PLCs.

Finally, for the sake of speed, cost and error-reduction, RDI aimed to leave as much of the existing field wiring in place as possible.

Edge control solution

In this case, RDI outbid the competition with a distributed system designed on Opto 22’s groov EPIC (edge programmable industrial controller). Edge controllers embed high-level automation functions such as data transformation and distribution, database transactions and manufacturing execution system (MES) operations at the device level in order to simplify complex control networks and bridge operations technology (OT) and information technology (IT) systems. To support this level of integration, edge controllers themselves provide processing power, storage and connectivity.

At the peaking plants, these controllers integrate all functions of the W301, F5LA and shared subsystems, including high-speed PID control, secondary control and networking, and embedded third-party communication. Subsystems are integrated using native OptoMMP communication and through embedded OPC UA communication via Inductive Automation’s Ignition Edge software. Additionally, each site reports to an external historian through a secure PAC gateway and integrates with a Citect SCADA HMI network, which RDI also designed.

Figure 3: RDI uses dual Ethernet ports on each controller to set up redundant network connections.

Distributed control architecture

For each turbine, one EPIC provides primary governor control, managing fuel mix, combustion and shaft speed, with one PAC providing backup control and overspeed protection. A second EPIC handles sequencer control, including the startup of auxiliary systems, process monitoring and coordination, and alarming, with a second PAC integrating high-density thermocouple sensing for temperature limiting and ramping. Finally, RDI uses the dual Ethernet ports on each controller to set up redundant network connections (see Figure 3).

Distributed control provides RDI with inherent failsafes. Because all four controllers are peers on the network, not remote input/output (I/O), each has the ability to interlock the system in the event of a partial loss of control or network connectivity.

Network redundancy is critical—we can't let the system fail for the sake of a bad switch—but in the event of network issues, each controller has the ability to trip the system as needed while maintaining its own control functionality, for example, lube oil operation, fan control or monitoring.

In our opinion, full controller redundancy doesn't matter in this architecture because the control is at the I/O level. If we are isolated from the network, we can continue running, and if we lose the I/O, redundancy won’t matter anyway.

As with traditional remote I/O, distributing control and I/O across multiple controllers also allowed RDI to reduce costs and minimize rewiring, which we determined was the best approach due to the uncertainty created by inaccurate drawings and years of undocumented modifications. Instead of building new panels or attempting to marshal field wiring to a smaller number of controllers, we dropped new controllers into existing enclosures, lifting and landing the existing I/O wiring from the old system to the new system. High-density and specialty I/O was placed on the lower-cost PACs and then located close to the equipment, rather than requiring long runs back to the primary controllers. This approach helped us minimize installation errors and reduce overall startup time. With the EPIC as the primary controllers, performance is not an issue because they are powered by quad-core ARM processors, which provide amazing horsepower. Proportional, integral and derivative (PID) control functionality is utilized for speed, load, startup and temperature control with each loop executing comfortably at 50 to 100 ms. With that speed, RDI was easily able to maintain the turbine/generator speed at 3,600 rpm to within +/- 1 rpm.

Figure 4: The starting resistor controller, a kind of electric starting motor, is controlled by a PLC, which adjusts its output in response to the speed of the turbine.

Subsystem integration

To interface with the shared subsystems at each of the three power-generation sites, RDI leverages a mix of hardware and software communication options included in Opto 22’s EPIC and PAC controllers. With groov EPIC, there’s no need to have a separate communication server. The EPIC sequence controllers coordinate data passing between the starting resistor controller (SRC), ammonia system, the other turbine controllers and remote I/O.

The SRC, a kind of electric starting motor, is controlled by an Allen-Bradley PLC, which adjusts its output in response to the speed of the turbine (Figure 4). RDI uses Ignition Edge, which is pre-installed on groov EPIC and provides a suite of native protocol drivers for common industrial devices, such as PLCs. Using Ignition, we create a bi-directional bridge between the EPICs and the PLC, consuming A-B tags and exposing the data through Ignition’s embedded OPC UA server. OPC UA tags can be directly linked to the control engine and other applications running on the EPIC, and turbine speed data can be sent back through to the PLC.

Having direct communication between different hardware platforms without engineered communication links or a server-based interface was fantastic. Compared to passing data via a human-machine interface (HMI)/PC interface, this approach provides a fully independent link between the systems to ensure it maintains operation in the event of an HMI/PC failure. If we were using the HMI to pass tags around, as is common, we would have been in trouble.

RDI uses the native OptoMMP protocol to communicate with the other subsystems. Turbine flow rate and temperature are passed to the ammonia system PACs to control the amount that is injected into turbine exhaust gas. Another PAC interfaces with Modbus serial devices to communicate voltage and protective relay statuses. And a pair of PACs create a non-routable interface for the external OSI PI historian. One PAC, which is linked to the control network, gathers data and passes it to another PAC on the historian’s network. The dual independent Ethernet ports on each PAC allow RDI to segment the networks so that data only flows out, not in.

Results

RDI definitely had a competitive advantage price-wise. We redid everything, including demo and install, and still came in 30% to 40% cheaper than competing bids. With Opto 22, RDI won the peaking plant contract and was able to retrofit each turbine pair in only two weeks, including demolition, installation and commissioning/testing.

Besides lower material costs, RDI attributes this advantage to three factors:

Control at the I/O level: Intelligent I/O networks distribute functions that, in a traditional remote I/O system, would normally be handled by a central controller. This architecture ensures that our systems can continue to run even with partial impairment.
Flexibility: groov EPIC and SNAP PAC are designed with embedded hardware and software tools—multiple networking options, communication servers and data processing functions—that provide our engineers with many options for designing and scaling systems.
Openness: We use components that are built on open standards and technologies, making it easy to integrate with third-party devices and external systems.

By leveraging these capabilities, RDI was able to meet the project’s objectives for performance and reliability. With no external dependencies or expensive server licensing, the system was also straightforward to design and simple to maintain.