Cogen plant’s unique approach links legacy control systems

Combined Cycle Journal Article on CSE’s Plant Controls Integration at large Co-Gen Plant in Illinois, USA

Read the article here.


Combined-cycle digital control systems follow a much shorter obsolescence curve than the physical assets. While a steam-turbine design might last decades without significant performance improvement, microelectronics are often out of date in less than a decade. For the huge wave of combined cycles installed between 1997 and 2005, the writing is on the wall for their legacy control systems.

Fortunately, convergence in digital technology and increasingly open systems based on accepted standards have led to a proliferation of new options. Rather than install a traditional DCS from one of the several primary vendors to tie legacy systems together, one cogeneration facility (installed in 1997) took a different approach. Instead of upgrading or replacing the actual control systems, the plant integrated them all, plus the controls for a new power-output booster unit, into a common HMI (human machine interface) and historian platform called IBECS™ (Integrated Be all End all Control System).

CorzineCSE Engineering Inc, Concord, Calif, was responsible for the revamp. Says CSE President, Craig Corzine: “The plant now has a central repository of information and a fully redundant network environment built from standard off-the-shelf components and customized for the plant, without reprogramming any of the existing controls, or using any third-party software.”

One of the key benefits cited by Corzine of the IBECS central data concentrator, or repository, is a common time stamp for all data. IBECS records the time stamp of a data change from the Mark V controller itself, not when the computer receives the data. IBECS monitors the actual Mark V data time stamp and re-indexes the historical data so the new data point will be in the correct chronological order. In this way, claims Corzine, IBECS creates a sequence-of-events recorder without additional hardware or software.

IBECS does not distinguish between a client and a server: All machines can perform the communications function. This means only one machine communicates with the controller, optimizing the availability of network bandwith

IBECS does not distinguish between a client and a server: All machines can perform the communications function. This means only one machine communicates with the controller, optimizing the availability of network bandwith

Common time stamps for data from different controllers are critical for troubleshooting and determining cause-and-effect relationships during abnormal events. The situation is exacerbated when you have multiple controllers and HMIs for independent process subsystems with different time stamps. “You end up manually ‘stitching’ the data together from all the affected controllers when you have to troubleshoot,” Corzine explains. An example cited is a Mark IV controlling an LM2500 gas turbine/generator with an independent controller for the steam injection to that turbine.

“Managing legacy control systems was one project driver,” according to the cogen plant manager, “another was the need to respond much faster to new ancillary-services market opportunities.” Other key benefits are the consistency in report generation, graphs, data presentation, piping schematics, and other critical plant information, and the availability of all the performance monitoring algorithms and information in one place for the entire plant—not as separate subsystems and associated HMI. Examples of performance and monitoring data available in the common HMI now are heat rate, swirl analysis of the GT exhaust, control-valve monitoring, tie-line control, and graphical presentation of the ready-to-start permissives.

The project began three years ago, but the plant kept asking CSE to add capability to the IBECS. Before IBECS, the controls environment included the following:

  • Four standalone Mark V systems for the 3 × 1 combined cycle—one for each gas turbine and one for the steam turbine.
  • A WDPF (formerly Westinghouse Electric Corp, now Emerson Process Management) DCS with Level 5 software.
  • Separate HMI for the steam turbine.
  • Three GE Fanuc PLCs (programmable logic controllers).
  • Five Allen Bradley PLCs for the supplementary-fired HRSGs and their burner management systems.
  • PLCs for the water treatment system.
  • Twenty-one power meters.
  • Two PLCs associated with the power-boost units.

There was no data sharing among these systems, something many folks from combined-cycle facilities of this vintage probably can relate to.

“We write software for every driver in a common programming code using the native communications protocol,” notes Corzine. “This is important because when you use interface driver software, such as OPC or DeviceNet, you run into issues with network latency, time lags, interrupts, and system overload.”

He adds: “We use the Virtual Tag System (VTS) from Trihedral Engineering Ltd, Bedford, NS, Canada. That’s the core product, and we write code related to powerplant functions.” In this way, CSE avoids problems with multiple programs written in different languages.

Importantly, VTS is an event-driven software system rather than database-driven. Unlike other historians, every tag is coded into the computer’s RAM (random access memory), not located in spreadsheets. This makes the CPU, the brain of the computer or chip, run more efficiently. “Our system isn’t constantly scanning thousands of spreadsheet entries to update tags, it simply identifies which ones have changed.”

VTS is not a C-based program, nor a script code in Excel; it was developed specifically for industrial applications, claims Corzine. A further claim is that VTS is the only programming language which can accommodate every driver common to powerplant control systems without third-party interface software.

At the cogen plant, for example, an engineer using the old system would have to open the editor function, send, compile, stop, and restart the application to add an “object” to the HMI. In VTS, all changes are made online in real time without shutting down or restarting anything, and immediately distributed through all the computers (schematic).

Unlike with other HMI/historians, tags in VTS are counted as only the specific I/O points. In other systems, 1000 discrete I/O points could represent 7000 tags that are counted towards your total for licensing and fee purposes. Most HMI software is “purpose-built,” says Corzine, meaning it lacks the flexibility or adaptability to integrate other parts of the plant controls.

One feature with a high degree of “cool factor” is encrypted operator notes. VTS software includes a historian. Operator notes, as in control room log book entries, are encrypted so they cannot be altered later and become part of the permanent historical record of that machine (or component). These notes are attached to historical trends developed in the historian. Most plant staff can see the value of operator notes located within the trend graphs at the exact time they occurred. “A good example,” says Corzine, “are device calibrations: They pop up right where they should be.”

Finally, the architecture for achieving redundancy is a distinguishing feature of IBECS (diagram). The industry standard for redundancy is multiple communication servers which also function as the data servers to the various clients, such as between a field controller and an HMI workstation. IBECS does not distinguish between a client and a server. All machines can perform the communications function. This means only one machine is actually doing the communication to the controller, which helps optimize the availability of bandwidth on the network. In addition, any IBEC machine can back up the other.

Back to News