In the course of an ongoing control system upgrade at its Greenwood Energy Center (GWEC) in Avoca, Mi., DTE Energy engineers also undertook to rationalize and reorganize a decades-old, dysfunctional approach to process alarms. "Previously, many of our DCS alarms were not rationalized," explained Kip Dobel, senior engineer in GWEC's Engineering Support Organization. "They were just characterized as high or high worse, and so we had a lot of noise and chattering alarms that were only fixed occasionally. In fact, operators determined unit status by the volume of alarms and not the actual alarms. Pages of alarms would scroll by on a unit trip, making it very easy for an important alarm to get lost in all the noise."
The company has been working to upgrade its distributed control system (DCS) from a 1990s-era Westinghouse WDPF system and lightbox displays to ABB's Process Portal A (PPA) 800xA DCS, but first decided it was essential to rationalize and reorganize the unit's approach to alarms. Dobel and colleague John Dage, DTE's principal engineer, presented "Alarm Rationalization Process at Greenwood Energy Center" this week at ABB Automation and Power World in Orlando, Fla. Located about 60 miles north of Detroit, GWEC is an 800-MW oil and gas plant, which serves as a "peaker" to deliver power to the grid when demand is especially high. This means the facility ramps its electrical production up and down more than other plants.
To focus on important alarms and eliminate the chatter, Dobel reported that GWEC began efforts to migrate to PPA 800xA in 2010 and also installed Matrikon's Process Guard software to help with post-event trip analysis. PPA 800xA included customer libraries, seven operator consoles, three engineering work packages (EWPs), domain and 800xA controllers, and AlarmInsight operator assistance software for 800xA, which grew out of collaboration by ABB and Matrikon. GWEC also runs OSIsoft's PI historian software to further document high-priority alarms and check on operating devices.
"We had about 6,000 analog I/O points, and so this meant dealing with about 10,000 decisions just to rationalize alarms and alerts from our analog signals," explained Dobel. "We wanted to give our operators an alarm system that would provide timely, accurate information to assist in operating the powerhouse in a controlled manner; employ Matrikon's Alarm Manager management of change (MOC) software to handle the rationalization; set up and execute an alarm rationalization scheme following EEMUA 191's principles; and provide the rationalization data to the operators' consoles."
Dage added that, "Previously, we were putting Band-Aids on the bleeders in our alarm system, but we weren't completing the documentation needed. This was the first time we did full documentation."
GWEC also hired a senior software engineer from Matrikon to help get its three-month, $250,000 alarm rationalization project started; hired some retired operators from outside the plant to help; and even set up a dedicated Alarm Rationalization Room with whiteboard and projector to present component data, trace alarm profiles, and facilitate discussing and hashing out the most logical and efficient ways to reorganize and reassign them.
"If you haven't done a rationalization project before, we recommend that you hire an external expert to help, but make sure you check their credentials and bring them in for a trial week to see if they can do what you need to get done," said Dobel. "Also, using retired operators from outside was helpful because they walked down the system and traced many devices and alarms, but it was also a mistake because we really needed to get more of our current operators involved too. A good rationalization team should have a panel board operator, a DCS expert that knows all the logic blocks in the systems and how they relate to the alarms system, instrument technicians and a scribe to keep everyone on track."