Today is...
Tuesday, September 19, 2017
Welcome to, the global online
community of automation professionals.
Featured Video...
Featured Video
EtherCAT with CTC’s master lets your multivendor network play well together...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Mark VI Redundancy Test
Do you usually perform redundancy tests with Mark VI R, S and T racks?

Hi everyone.

At our plant we have two frame 6B GE turbines which is controlled/protected by a Mark VI.

The architecture is pretty standard, supplied by GE, and consists of three Racks (R, S and T) which performs 2oo3 voting to increase availability without letting go of safety.

After every turnaround or even after a minor turbine "pitstop", in addition to the usual diagnostics evaluation and hardware checks, we also perform a redundancy test as soon as the turbine comes back to operation. This test consists of:

1) Normal procedure to start the turbine

2) Wait until it gets to FSNL

3) Turn off Rack R (switch off the Rack R power supply) and check if the turbine keeps running with only racks S and T.

4) If no trip occurs, restabilish Rack R, wait some minutes after it achieves appropriate control state, and repeat the procedure to racks S

5) Repeat step 4 for rack T

Obviously, before starting the test you have to make sure there isn't already a problem with some 2oo3 logic points at R, S or T, because if you already have one problem and switch off a second rack, definitely there will be a trip.

Well, this test goes pretty well with one of our 6B, no trip occurs. However, the other 6B is tripping when rack R is powered off. It does not happen when S or T are powered off, but only when Rack R is. That indicates that it is not a 2oo3 redundancy problem, because we would have to have a trip when powering off S or T also (for example, if there is a 2oo3 voting issue with S, when shutting down S there would be no trip, but when shutting down R and T definitely there would be a trip).

Also, as the first cause indicated problem with GCV or SRV, we did another test at FSNL disconnecting rack R, S and T VSVO output points to the SRV and GCV (one each time) and that was no trip at all.

We couldn't perform more detailed tests this time because the turbine start was already late, and as these redundancy tests are last thing to be done, unfortunately it got postponed for next stop. Also, it does not jeopardize the turbine safety, only availability (worst case scenario we would get a safe trip).

Well, I'd be happy if you guys could share your experience with these kind of tests, and maybe suggest how to identify faster where the problem is. IMHO, the possibilities are:

1) The power supply of Rack R is wrongly being used to supply some vital point, or maybe to supply something that should be supplied from S or T (mistake at field connections).

2) Some Mark VI logic is operating as 1oo1 with a variable from Rack R. That is a logical but unpractical possibility. I also checked all Rack R single card points and could not find out anything like that.

At next stop, I'm thinking about to, instead of switching off Rack R, remove the cards cables one by one, so we would be able to narrow down the search. Do you have any other suggestions/ideas?

Thank you very much.

Kind regards,

1 out of 1 members thought this post was helpful...

First off RRA I have to say good job on the fact that you perform a TMR check after any maintenance activity. The benefits of the TMR architecture are many times just assumed but never tested. And as you have found there can be issues even with a properly running system.

I would ask for a list of alarms that are generated when "R" core is powered down. I know there will be quite a few. But there should be some alarm that indicates the cause of the trip that can be investigated.

As you have mentioned I suspect that there is some device being powered from "R" core that is critical. I would be looking at any card I/O that is simplex only to "R" core. In the past I have found issues with incorrect wiring related the LVDT excitation for a particular gas valve. If you are getting alarms for loss of position for any valves then this is a great place to start. Some of this can usually be confirmed by using the triplog if this is properly configured.

But giving us a list of alarms generated when "R" is powered down would help us suggest a shorter list of things to start checking on. My bet is LVDT excitation since you mentioned "as the first cause indicated problem with GCV or SRV.

But more information would be helpful.

Thank you very much for your contribution. I will check again the alarms and try to find any other information that can guide us here for the next opportunity to test the system.

The LVDT excitation is a good candidate also in my opinion.

I agree with you about doing the right tests, many times people do not care about the control and also safety systems, until they fail. We as Engineers have a major role to influence the good practices.

Best regards.

1 out of 1 members thought this post was helpful...

Hi everybody,

Just to give a feedback (it is important and maybe it will help someone else with a similar problem), this turbine had a pitstop and I was able to do some more testing.

In fact I confirmed that the problem was with the LVDT excitation. Each valve (GCV and SRV) LVDT has two excitation (redundant) so they still work when losing one source.

The excitation come from a TSVO terminal board, being 2 excitation from Rack R, 1 from S and 1 from T. The problem here was that both LVDT excitations of SRV valve was being fed from Rack R, and the GCV was being fed from S and T. That way, the trip occurs only when powering off rack R due to lost of LVDT signal of SRV.

The solution was pretty straightforward: I swapped one excitation source between GCV and SRV. Final condition was:

SRV excitation #1: Rack R
SRV excitation #2: Rack S
GCV excitation #1: Rack R
GCV excitation #2: Rack T

The interesting fact is that we discovered that this error was there for many many years, since startup, and nobody noticed because they never did redundancy tests before. So, do your tests. Don't wait for the problem occur.

Best regards,

2 out of 2 members thought this post was helpful...

Dear RRA,

Thanks very much for taking the time to reply and provide feedback. As you say hopefully this will help someone in the future and you can feel better about system functionality should a core experience a failure.
Glad you were able to solve the issue!!!