During normal operation the GTurbine signals (all of them) in HMI got frozen. The Fuel shut-off valve probably closed, because the pressure line got ZERO (measured by BOP).

The Main Circuit breaker opened after 10,0 seconds by a DGP signal (Reverse Power).

After 55,0 seconds, all points in HMI came back. Naturally, registers, alarms only after this 55,0 sec.

Anybody have ever seen, or reported this problem.

Thanks

 

Yeah; I've seen this before when critical data is sent to the BOP from the HMI. So, when the HMI can't get data for some reason, the BOP doesn't get any data, and if it then shuts off fuel the unit will "shut down".

Did someone recently try changing something in the CIMPLICITY program or the MODBUS application or the GSM application (at either end of the GSM link)?

Have you confirmed that all of the StageLink cables and components (fiber optic MODHUBs, links, cables, connectors, termination resistors, etc.) are all properly installed, connected, and making good contact and are not grounded?

What else was going on in the plant at the time this event occurred?

When the BOP isn't programmed or configured to "survive" the loss of data from the turbine control(s) then this can happen, and has happened.

This isn't necessarily a Mark V or HMI problem as much as it's a plant design problem, and something the operators should be aware of and be prepared for. Some plants configured to require critical data from the turbine control system(s) use redundant links to get the data from more than one source (HMI) so that in the event one source (HMI) goes down, the link will switch to the back-up source to keep the unit running.

Were there any Diagnostic Alarms annunciated during the event?

 

Mr CSA,

At first thanks for your attention. I was sure you would help us.

I'll try explain better.

These BOP points, was collected by other Supervisory.

Most of all points got frozen,power transducers, water and fuel flows and pressure, rpm, H20 injection rpm, compressor temperature and pressure, most exhaust thermocouples, TTXM, TTRX (reference). Only four or six thermocouples operated properly. So the gsm link worked well.

In Trip log view, registered nothing during this 55 sec. After this time, TTRXwere 6 ºF and TTXM +- 600 ºF, when registered trip by excessive exhaust temperature (of course de Cbraker were opened 45 sec. earlier).

I think this problem occurred in internal mark V communication, not for external problems or TRIP COMMAND. But I don´t know what specific card, or processor failure.

 

There's too much that could go wrong to try to list all the possibilities.

I don't understand your explanation, at all. You say the GSM worked well, but yet you say that only four or six thermocouples operated properly. That doesn't seem to make much sense. To me, anyway.

The Trip History (Trip Log; Trip Display; whatever you want to call it) is stored on the Mark V, and then is "collected" (uploaded) by the operator interface. So, you should be able to see the information regarding events around the trip because they should have been stored in RAM on the Mark V, and should have been available to be "uploaded" and viewed and printed, on the operator interface (HMI).

If there was some problem with the Mark V, like a serious battery ground, or a power supply problem (spike, dip; induced AC; TCPS power supply problem; etc.) that caused the Trip History information to be lost, then that's another story.

Another thing that happens is that when another START is initiated (i.e., when L4 picks up during another START event), then the Trip History will be started from the beginning, because L4 is the "trigger" for Trip History, for both starting and stopping (when L4 drops outs that's when the Trip History "stops" except for the three seconds after L4 drops out).

If there was a serious problem with <C> which caused a communications problem with the HMI, then it's still not clear how GSM could have worked well. But, that would explain the loss of data on the HMI display, and maybe even the loss of Trip History data by the Mark V. One has to remember: The operator interface is separate from the Mark V; in other words, for most every installation in the world (and there are exceptions, unfortunately) a loss of communications between the operator interface and the Mark V will <b>not</b> result in a trip of the turbine by the Mark V.

Now, if data is being collected by the "Supervisory" from the Mark V, and that data is used to maintain fuel flow to the turbine when it's running, and the communications between the Mark V and the operator interface are interrupted, and if the "Supervisory" can't maintain fuel flow without the data that it gets from the operator interface (which gets the data from the Mark V), then if fuel flow is lost the unit will eventually trip on loss of flame (because there's insufficient fuel), and very shortly after that the generator breaker will open on reverse power (because there isn't any power coming from the turbine because the flame is out because the fuel ran out).

On machines operating on gas fuel, I have seen them continue to run for seconds, even minutes, as gas pressure bleeds down between the valve operated by the "Supervisory" and the turbine. Some sites even have large "receivers" which can even extend the operating time as the fuel/pressure in the receiver bleeds down when the supply valve upstream of the receiver is shut by the "Supervisory."

So, barring a loss of power and before a START was initiated, it should have been possible to upload the Trip History display info, which should have included the Process Alarm queue, and have some idea what happened.

GSM is a means of communicating with a DCS or "Supervisory", as is MODBUS. The StageLink is the coaxial (and possibly fiber optic) link between the operator interface(s) and the Mark V (and possibly the EX2000 exciter regulator, if so equipeed). So, if data was lost on the operator interface (HMI) that would imply something was wrong with the StageLink or the communications between the Mark V (the <C> processor/core, which is where the StageLink is connected in the Mark V), the <C> core, etc. Re-booting the operator interface (HMI) while the unit is running will not cause the Mark V to trip, so losing communications between the Mark V and the operator interface while the unit is running will also not cause the Mark V to trip the unit. With but a couple of exceptions, one doesn't need an operator interface to operate the Mark V. To see what's going on; yes. But, one can use the <BOI> to operate the unit (presuming it was properly configured, and someone knows how to use it, which is another issue altogether).

ONe has to be VERY careful when interpreting and reading Alarm lists when a turbine trip has occurred. The trip at the "top" of the list is NOT usually the one that caused the turbine to be tripped. It's the "lowest" trip on the Alarm list (the first trip that's annunciated) that caused the unit to be tripped.

If the turbine were running and the circuit breaker opened and the turbine continued to run, one of two things would happen. If the control system didn't do anything at all and fuel flow didn't change, then the unit would likely overspeed, and maybe even very quickly. If the control system recognized that load was lost when the generator circuit breaker opened and reduced the fuel to just make the unit hold rated (100%) speed, then it would not have tripped on exhaust over temperature, because there wouldn't be enough fuel to cause that to happen.

Again, there's just too much that we don't know about what happened at your plant. And we don't really even know how the "Supervisory" gathers the data you were talking about, and what it does with that data. Like keeping fuel flowing or not. some "Supervisory" systems do that, they won't allow fuel flow unless there is a "demand" from the turbine. Many don't, but some do. And we don't know how your plant is configured.

Without a lot more data, it still doesn't look like a Mark V or HMI problem. But, that's just based on what we have been told.

I wish I could be more helpful, but at this stage, it's just not possible.

We don't know if the Mark V at your site is SIMPLEX or TMR. There's just too much we don't, and can't likely, ever know. It could have been an "internal Mark V" problem--but that would have resulted in <b>many</b> Diagnostic Alarms, which we don't know about either.

There's just too much we don't know. Sorry.

 

Perfect, Mr. CSA !!!

I´ve made a mistake when I said: "Only four or six thermocouples operated properly."

During this famous 55,0 sec all signal were frozen... I was in doubt because after open the circuit breaker, this fews TC read properly, (600 ºF).

So the right information is that all points were frozen.

When I said BOP supervisory, i´m talk about our SDCD, that is an different LAN from arcnet. I tried, wrongly, emphasize that mk5 sent, ou didn´t send any information.

Our plants storage all information from Gas turbines from only one PC. So each unit has one PC in respective P.E.E.C, and a unique server station (GSM) sent information from all of them to a data banch. The others units has its datas stored correctly, I hope these "FROZEN" unit too.

I don´t have knowledge to affirm that the problem occurred in mk5, but all elements shows it.

I've seen the unit running, more than five times, without AC power, PEEC in black out. The unit Tripped by low suction alarm, after 12 seconds from the black-out beginning.
And is "normal" rebot the stations (HMI) while th unit is running.

Normally appears on alarm list the famous "Diagnostic alarms", but not a specific. it appeared before this event.

After this events, we observed a dc ground alarm, and there short circuit in the mk5 source, because we measured different VDC in the power supply. It´s not as default.

Well, sorry by this poor english.
I´m looking for more information.

Rgds

 

CSA,

If you want, you can send your phone number to guirrod [at] ig.com.br. Then I call you...

Thanks