Looking for Insights About Dual Configuration in Mark VIe

Can any one please give more explanation about the dual configuration in mark VIe regarding the voting and the processing of critical signals. For example the trip solenoid relays in the TRPG card will have a configuration of 1/2 or 2/2?

Or we do not have any voting at all and we do have a designated controller!

thanks in advance

Good question, and, again--there's not much written on the subject by GE.... Hopefully Demigrog will correct me where I'm wrong, and fill in the blanks I may create.

It's my understanding that DUAL redundant Mark VIe systems are somewhat "unusual" when it comes to control in that one controller might be driving the digital outputs of one I/O Pack, and another controller might be driving the digital outputs or another I/O Pack. How is it "decided" which controller drives the outputs of which I/O Pack--whichever controller connects to the I/O Pack first (of course). So, during initialization of a Mark VIe turbine control panel as each I/O Pack and controller is going through it's initialization routine if <R> establishes a connection with an I/O Pack before <S>, then <R> drives that I/O Pack's outputs. If <S> establishes a connection to an I/O Pack first, then <S> drive that I/O Pack's outputs.

And, if the first-connected controller's connection is lost (such as if the controller is shut down or re-booted) then there is a slight time delay/lag as the other controller takes control of the I/O Pack's outputs. That time delay/lag is NOT published anywhere, but in my experience it is VERY fast.

Here's what the Mark VIe System Guide, Vol, 1, says in the redundancy explanation section:

"The Mark VIe controller or pack listens for the data on both networks at power up. The channel that delivers the first valid packet becomes the preferred network. As long as the data arrives on that channel the pack/controller uses this data. When the preferred channel does not deliver the data in a frame, the other channel becomes the preferred channel as long as valid data is supplied. This prevents a given I/O pack/controller from bouncing back and forth between two sources of data. This does mean that different I/O packs/controllers may have separate preferred sources of data but this can also happen if any component fails."

Now, this seems a little odd--but it's not really. Both controllers use the inputs from ALL I/O Packs in determining what the outputs should be, so there should be NO voting mismatches on the inputs. And if both controllers use the same values for determining what the outputs should be, there should be no voting on the outputs, either, right? Since there's only one I/O pack sending it's input values to BOTH controllers, both controllers should receive the same information to make its determinations on when executing the application code.

And, remember, both controllers are synchronized to each other and they both read their inputs, then they execute their application code, then they write to their outputs--and, in theory (and in practice in my experience, also) it doesn't make any difference which controller is actually driving an output because both controllers are making the same determination.

Now, as for the trip solenoids.... I believe the TRPG and the TREG still both have three Primary Trip Relays (driven by the PTUR) and three Emergency Trip relays (driven by the PPROs/SPROs), respectively, and the configuration software uses one signal from the "connected" controller to drive all three Primary- or Emergency Trip Relays. I seem to recall that when DUAL Redundant is chosen when creating the configuration for a specific application that's what happens. Now, there may be a special version of the TRPG and/or TREG for DUAL Redundant systems--again, that would be in the System Guide--but that was my recollection on early DUAL Redundant systems, and I may not be correct at all about that. But, it makes sense based on what I've seen GE do in the past. Only one controller in a DUAL Redundant system can write to outputs of any I/O Pack (as I recall), and that goes for the PTUR/TRPG I/O Pack/terminal board combo as well.

I hope this helps--and I hope Demigrog will make the appropriate clarifications/corrections.

I believe what you have written is correct. The dual redundant configuration MkVIe controls have been used in combined cycle power plants for HRSG and BOP control. I don't remember anything specific about the TPRG and TREG. I also don't recall any use of the dual redundant configuration for either heavy duty gas turbine or steam turbine control. (I am completely ignorant of what was (is) used on the aircraft derivative units.)

I will say that while the triple redundant TMR configuration offers slightly higher running reliability than the dual redundant configuration, there is one clear advantage the dual redundant arrangement has - it is possible to configure and test control loop changes on line by forcing one controller to standby, downloading revised software to it, booting it up and letting it initialize, then forcing the other controller to standby and verify that the revisions work and are stable. If all is well, then download the changes to the 2nd controller. If not, switch back and restore (or further modify) the revised controller.

Thanks for the information!

I don't believe GE will provide the DUAL Redundant configuration on a DLN-equipped heavy duty gas turbine, and I don't know if they will provide it on an aero-derivative gas turbine, particularly one with DLE. But I do know they provide it on steam turbines (primarily retrofit applications), and on heavy duty gas turbines (again, primarily retrofit applications).

The TRPx/TREx are the Primary- and Emergency Trip Relay cards--trip solenoids (fuel/steam stop valve solenoids) are wired between these two card, with the TRPx controlling the negative leg of the solenoid power supply and driven by the control processor(s), and the TREx controlling the positive leg of the solenoid power supply and driven by the PPRO(s). I don't know that they would be necessary in a DCS/BOP application.

Again, thanks for the information!

Thank you very much indeed Mr CSA for this explanation. i gained some insights now about it, and just want to confirm some points:

1: in the the Mark VIe System Guide, Vol, 1 they say : "the internal data (state) variables are taken from the designated controller and transmitted to the non-designated controller for its use. This is known as state exchange."

so here for example if i take the CNCF (the speed corrected factor) which is calculated from the inlet temperature (input) and compressor temperature ratio (control constant). so if i'm not wrong, this state variable will be sent by the designated controller to the non designated control right? and all this happens to converge the results of the two controllers?

2: as far as i have understood, during normal operation, we cannot know which controller is driving a particular IOpack! and if i suppose that i plug out the two IOnet cables from the <S> controller so know i can confirm that all the IOpacks are driven by the <R> controller no? and if yes, is this what we call "forcing the other controller to standby" explained by Otised.

Waiting for your feed back

I believe the controller can be forced to standby from Control Station ST. You can also power down a controller and then turn it back on, which should force the other controller to take over all the I/O packs.

But, please understand that it has been nearly 9 years since I was on site with a Mark VIe dual redundant controller, and about 8 years since I had direct contact with one during a FAT (Factory Acceptance Test). Even then, due to various work rules, I was only able to direct others to do the actual work. And, while I would rather have had my own hands on the keyboard, it was better to have those who would be responsible for the equipment after I left site get the experience.

I am bewildered by the questions--and comments--in your most recent post. I can't tell if some Mark VIe is having problems (which it would be helpful if you would describe here), or is you're having problems with the design and implementation of DUAL Redundancy by GE in their Mark VIe control system.

I apologise for my meticulous questions.

Actually by February we will have and upgrade from Mark II to Mark VIe control system in our compression station. It will be a DUAL configuration this is why i wanted to understand this configuration.

I'm probably one of the most curious and inquisitive people you would ever meet, and I had a LOT of questions about DUAL Redundancy the first time I encountered it. And the second time. And the third time.

But, I'm also a pragmatist--and performance speaks volumes about a concept. I have worked on and commissioned several DUAL Redundant Mark VIe control systems, and no matter my apprehensions or suspicions, it works. And, it works very well--VERY well.

There's one thing I can say about GE turbine control systems (and DCS/BOP systems) utilizing Mark VIe hardware/technology: It works. And it works best when it's properly configured and commissioned. I have seen MANY commissioning engineers and others who have tried to force the Mark VIe (and the Mark VI, and the Mark V, and the Mark IV) to fit their understanding of how it should work. And, that was generally disastrous.

Now, sometimes the Mark VIe comes configured from the factory less than optimally--and, that can be a problem. But, re-designing the control system or re-configuring it <i><b>without understanding the reason it was designed and/or configured the way it was</i></b> just leads to LOTS and LOTS of problems. But, the proper way to handle any issues commissioning a system the way it was configured that is not performing the way it needs to is to work with "the factory" to understand what the problem could be and then to work with the factory to make it perform as needed.

I haven't worked on a Mark VIe in the past few months, but I have to believe there is some way to determine which controller is driving the outputs of a particular I/O Pack. And, in my personal opinion, having the I/O Packs individually driven by the two controllers is a good thing. I believe it could be called "distributed" control, in a very loose sense.

As for "converging" values, I think that's not a very big concern. If I understand the signal you asked about, it uses speed pick-up inputs (so both controllers should be seeing the same signals coming from the speed pick-ups) and a Control Constant--which should be the exact same value in both controllers. A lot of signals are like that. I would expect that only analog input signals from redundant devices (say, there might be two pressure transmitters on the same parameter--but not two LVDTs, they are handled VERY differently by the I/O Pack) might cause a problem if there was no convergence. BUT, I also believe there would be Diagnostic Alarms to alert a conscious operator to a lurking problem with the two inputs diverging or reading very different values.

Trust me--it's kind of scary not knowing which controller is doing what. But, also trust me when I say it works, and it works VERY well. And it provides a solid level of redundancy without having TMR. (And, one thing most people don't realize about TMR is: When you have three of everything, you have three times as much potential for problems and card failures.) With DUAL Redundant systems, there is one I/O Pack (for most terminal boards) providing the same signals to TWO controllers who are (should be--and are, in reality) making the same determinations about what the outputs should be doing, and when one of the controllers fails, the other "jumps in" extremely fast. With TMR there are three I/O cards providing the information to three controllers, and there are three cables connecting the three I/O cards to the terminal boards. And each one of the I/O cards, controllers, and cables, and the racks that house them, and the power supplies that power the racks that house them, can all fail. And you need to have more spares and will experience more failures. DUAL Redundancy is definitely the way to go.

And, the more I think about having two controllers controlling various outputs when one fails, that means there are fewer opportunities for momentary problems when shifting to a single controller in the event of a failure of one controller.

The two biggest problems with Mark VIe are: temperature/humidity, and IONET switches. GE way overestimated the allowable temperature range of the I/O Packs and hardware, and they do need cooling of some sort. Air movement in the control cabinet is key, and by air movement, I'm referring to forced air movement (such as by fans). GE also mounts I/O Packs in vertical columns--which "concentrates" the heat on the higher I/O Packs in the column, and makes them have more "issues." (And this is against the original design criteria--NOT arranging them in vertical columns, at least not the combo analog terminal boards/I/O Packs.) Forced air circulation is pretty much required for most applications/panels.

I believe the reliability of the IONET switches is improving, but I also believe they are subject to problems caused by temperature.

Hope this helps! Don't fret about convergence and which controller is doing what. It really does work. And it "fails over" without a hitch (unless there were ignored Diagnostic Alarms). And that is something you will need to get used to: Diagnostic Alarms. When commissioning is finished there should be <b>NO</b> Diagnostic Alarms. None. Zippo. Nada. Niente. If the commissioning personnel are allowed to leave site when Diagnostic Alarms are present, or if Diagnostic Alarms are annunciated intermittently during start-up and shutdown, the site is going to live to regret it. And, when Diagnostic Alarms are annunciated the operators MUST learn how to use the Mark VIe System Guide to interpret the alarms and get a technician if necessary to resolve the alarms. Unresolved Diagnostic Alarms, especially on DUAL Redundant systems, can lead to trips and worse. Respect Diagnostic Alarms and deal with them quickly. Or, learn to expect nuisance and intermittent problems.