Today is...
Saturday, June 23, 2018
Welcome to, the global online
community of automation professionals.
Featured Video...
Featured Video
A demonstration of EtherCAT control of linear motors using the CTC EtherCAT master.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Questions about MARK VI TMR
Questions about MARK VI TMR.
1 out of 1 members thought this post was helpful...


I am newbie in Control Systems. So please take my questions patiently and correct my understanding.

From my understanding,

The way "Redundant Input Signals" are handled is either High Select or SIFT Voting

How the process of high select takes place ? Give me please a simple scenario.

SIFT Voting will use "Median Voting" according to my understanding. SIFT is essentially for input signals only.

I read the output signals are voted using Hardware Voting. Is that right and what does Hardware Voting mean?


By Chiranjeevi on 13 August, 2017 - 4:20 am
3 out of 4 members thought this post was helpful...


In general, SIFT (software implemented fault tolerance) is meant for analog signals. Take example of TNH calculation (median of three frequency signals named 77NH-1,2,3). NH-1, 2, 3 will be processed by each pack R, S, T pack respectively. Each pack's values are shared through IONET to each controller. Each controller will compute the average of three signals coming from each pack.

Suppose if one input of this speed pickup failed or any of the IO pack failed then the corresponding input it exceeds the TMR differential configuration in the controller, then the average of remaining two values from the Io packs will be computed by the controllers as the final value of TNH.

If you wo input signals like CTIF-1, 2 or 77FD-1, 2 (in MARK VIe only two inputs are used), each input value will be processed by three analog packs but and shared to controllers. In the controller, higher value of these two input will be taken for final value of CTIM or fql1.

Taking higher value instead of taking lower value is a fail safe condition.

Any reference value like FSR,CSRGV etc. (suppose FSR is the final output of all FSRSU,FSRSD,FSRACC,FSRN,FSRT,FSRMAN). any 2 in put signals are selected for higher selection.

In case of analog outputs (example:servo currents), each controller R,S,T will provide the reference value to its cosponsoring R->R pack,S->S pack t-> T pack. The difference between the reference and actual will be compared and multiplied by current gain and further adding the null bias value.

In case of digital input or output, it is called 2/3 voting. Each input value will be fanned to all three IO packs in the TDBT terminal board to get processed by all the three packs and further shared to controllers.

In cases of digital output, each controller provides the output bit to the corresponding to its R -> R pack, S->S pack, T->T pack. The Io packs will energize its own relays on the terminal board. The final voting of output will be done on the terminal board. Two relays of one output should be always in energized condition to get the output energized or to have dry contact through (in case of commands to motors).

Suppose if one pack or its corresponding controller fails, then the corresponding relay will get de-energized. Failure of single pack or controller will not affect the plant in case of TMR as it is 2/3 voting on the terminal board. But failure of two packs of controllers will affect the turbine operation.

Failure of two controllers will also cause the corresponding output relays to get DE-energized and the AOP, AHOP, and some of the vent fans motors to start as they are configured with sense NC and connected to NC in the digital IO terminal board.

Hope this helps..

By Chiranjeevi on 13 August, 2017 - 11:15 pm
1 out of 1 members thought this post was helpful...

A small correction in my sentence:

Any reference value is the mininum among all, like FSR, CSRGV etc.
In case of FSR, it is the minimum select block value of FSRSU, FSRT, FSRN, FSRACC, FSRSD, FSRMAN etc.

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


Here's an example of SIFT. Many GE-design heavy duty gas turbines use a single temperature switch to alarm on high L.O. Temperature (temperature greater than 165 deg F). That temperature switch may be connected to a TBCI terminal board that "fans out" (distributes) the one signal to three VCRC discrete I/O cards, one in each processor rack (<R>, <S> & <T>), using three cables. At the same instant in time, each processor reads what it believes the value of that signal (often L26QAH)to be. Each processor then sends out, over the IONET (the silver-sheathed coaxial 10-Base2 Ethernet cables) its value of L26QAH to the other processors. Each processor then votes its value with the values from the other two processors and uses the voted value (2-out-of-3) in the execution of the application code (logic; sequencing).

So, if <R> & <T> thought L26QAH was logic "0" (the L.O. Temperature was NOT high), but <S> thought L26QAH was a logic "1" all three processors would use a logic "0" in the execution of the application code. And, there would be at least one Voting (Voter) Mismatch Diagnostic Alarm to alert that one of the processors had a different value for the signal. (Some versions of the Mark VI operating system would only annunciate a single Voting Mismatch Diagnostic Alarm--from <S>. Later versions seem to annunciate two Voting Mismatch Diagnostic Alarms--from <R> and <T>. Don't know why the change.)

The Voting Mismatch Diagnostic Alarms tell the technician that there is something amiss with the TBCI terminal board, or the cable connecting the TBCI to the VCRC in <S>, or a problem with that channel of the VCRC in <S>. There's only one switch, with one set of contacts, and it's not likely the switch would be the problem.

But, the concept of SIFT is that all three processors will use the voted value of L26QAH in the execution of its application code. So, each processor will take the same action--even if its input value for a particular signal is different from the other processor's input value.

Most GE-design heavy duty gas turbines use two, redundant High-High L.O. Temperature switches (26QT-1 and 26QT-2) for tripping the turbine on excessive L.O. Temperature (usually 175 deg F). These two switches can also be connected to a TMR TBCI terminal board, and fanned out using cables to VCRC cards in the three control processors. And, the same voting takes place on the two signals, L26QT1H and L26QT2H.

IN THIS example, however, under normal operating conditions BOTH high-high switches must be a logic "1" to trip the turbine, and some application code also checks to see that the high alarm temperature was also indicating high temperature before initiating a turbine trip.

(I need to note that in some GE-design turbine control systems one, or even two, of the three L.O. temperature switches may be connected a single VCRC in only one of the three control processor racks. That is called a "simplex" input, and under normal operating conditions, that signal is used by all three control processors--it's not voted, because it's only connected to one VCRC in one control processor rack. But, its value is put out on the IONET for all the processors to use in executing the application code by all three processors. If there's a problem with the TBCI or the interconnecting cable between the TBCI or the VCRC or with the input channel of the VCRC, then there will be an alarm (Process Alarm), sometimes it's a 'switch problem' alarm, sometimes it's an erroneous high- or high-high temperature alarm.)

Personally, I think of SIFT and voting as background activities. And, they are "invisible" under normal operating conditions. The only time they become important are when Voting Mismatch Diagnostic Alarms occur. And, that's what Diagnostic Alarms do--they can indicate problems with Mark VI hardware (terminal boards; cables; I/O cards (VME processor cards). Diagnostic Alarms are useful tools in keeping a GE-design heavy duty gas turbine running and reliable; they are NOT nuisances. (UNFORTUNATELY, many commissioning personnel do not properly configure inputs and outputs and that results in excessive numbers of erroneous and/or intermittent Diagnostic Alarms.)

It's important to note that a single Diagnostic Alarm cannot trip a turbine (no Diagnostic Alarm can trip a turbine). BUT, combinations of Diagnostic Alarms CAN result in a turbine trip. So, it's VERY important to quickly acknowledge and resolve all Diagnostic Alarms. And, NO, no one can tell you exactly which combinations of Diagnostic Alarms will result in a turbine trip.

Again, it's not a simple topic, this voting and SIFT. In my way of thinking of things, voting of inputs (which can be voted) is done BEFORE any application code is executed, and in this manner each control processor should arrive at mostly the same determinations and alarms and actions. Some outputs are voted, and if there is a disagreement between the three processors there will be Diagnostic Alarms to that effect. The one big exception here is servo-valve outputs. And, some servo-valve calculations use voted inputs, others do not. But, in the end the outputs are voted at the servo valve, by summing the amp-turns of torque produced by each processor's signal/coil.

In my opinion, high-selecting or median-selecting or low-selecting of signals is not technically voting. It's just a means of selecting, based on GE's decades of data and experience, which signal is likely to be most accurate based on known failure modes of devices and instruments and design of the control system. Everything is done in its own way for the purpose of enhancing turbine reliability and availability. But, not every signal is voted, and not every signal needs to be voted. Not every signal is high- or median- or low-selected. But, those three determinations are done in each processor during execution of each processor's application code, so that, in my opinion is not voting in the true sense of the word.

I just searched GEH-6421, Vol. I, and found a lot of information about SIFT, mostly in the 'System Architecture' chapter, Sect. 2. There are some good drawings and some confusing drawings, and some good information there about some of GE's control system philosophies and how they are accomplished in the Mark VI using software (which does not degrade) and hardware.

Hope this helps!

By Chiranjeevi on 13 August, 2017 - 6:48 am
1 out of 2 members thought this post was helpful...

>I read the output signals are voted using Hardware Voting.
>Is that right and what does Hardware Voting mean?

To get any one excited or output Digital output or to appear at the terminal board channels, the 3 (minimum 2 relays should be energized) relays for one present on the terminal board should energize if the signal is connected and configured as sense NO. The IO packs will supply 28V DC to its own relay coils. The final output goes through two series contact combinations of R&S, S&T,T&R relays.

To have better visualisation study VOL I or II manual.

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


I'm going to echo Chiranjeevi's comment to refer to the Mark VI System Guiude, GEH-6421, Vol's. I & II. Vol. I has a lot of generic information, and Vol. II has a lot of hardware-specific information.

I would also remind you that the HMI usually has a LOT of GEH's and GEI's and other information in more than one directory/folder. Unfortunately most of the files are named using the GE publication number--but you can change the name of any file to be more descriptive and easier to find.

I recommend going through all the .pdf files and copying and renaming the ones you want to spend more time going through--putting them in a folder on the Desktop for easy access/reference.

SIFT.... I think you'll find it's been covered before on It's primarily for ALL I/O (analog and discrete) that is connected to <Q> (<R>, <S> & <T>. All the processors are synchronized, meaning they all start and execute their application code at the same instant in time. At the beginning of every "scan" they all read their inputs, then they all share the values of their inputs with the other processors, then each processor votes the values (most--but NOT all), and then they begin executing the application code using the voted values of inputs.

In this manner, the application code SHOULD always decide to perform the same operation--and if there is a voting mismatch, then one of those Voter Mismatch Diagnasty, ..., er, ..., uh, ..., Diagnostic Alarms gets annunciated to let a conscious operator know that something is amiss with some input signal. Again--this is for most of the discrete (contact) inputs and many--but NOT all--of the analog inputs.

Some of the analog inputs are high-selected at the I/O card ("firmware"), some are median-selected (the "middle" of the three processor values for triple redundant inputs) at the I/O card. And, some are used by the processors without any voting at all (such as turbine shaft speed pick-ups). Yes--the "display" value of these signals is "voted" (displays, other than the Pre-voted display in Toolbox, can only show one value, even though there might be two or three values).

LVDT inputs are high-selected at the I/O card level. In the Mark VI, I believe if you find the P2 pressure transducer inputs you will find that they are median-selected in the application code to compare against the P2 pressure reference. ALL inputs are NOT handled the same way, though many are.

I believe the way turbine shaft speed pick-ups are handled has changed over the production period of the Mark VI. In the beginning, they weren't voted--each processor used its own value. I believe the signals are high-selected now--but I don't know if that's done at the I/O card level (firmware) or in application code. Liquid fuel flow divider mag pick-ups are handled differently, also, I believe, depending on version of Mark VI hardware/software. Each processor used to use its own liquid fuel flow divider speed input, but I think that's changed similar to the turbine shaft speed pick-up inputs.

Signals like some compressor discharge temperature thermocouples (where there might be only two, not three), are usually median-selected in application code. If there are three, they are usually still median-selected (the middle value is used).

Exhaust T/Cs are a different beast altogether. One-third are connected directly to each processor--but, during the "voting" part of the application code scan each processor sees what the other two processor's values of exhaust T/Cs are, and uses them all in executing the application code (combustion monitor; median exhaust temp calculation; exhaust over-temperature protection; exhaust temperature control; etc.).

As for discrete outputs, most are voted at the I/O card level--two of the three processors must say a discrete output is true or false for it to be true or false. Since some discrete outputs are "simplex", they are not voted. (Some discrete inputs are "simplex" and are not voted, also. Since we're talking about TMR, we won't discuss other situations for simplex I/O.)

Servo outputs, as we've talked about, are voted at the servo valve--through the summing of the three servo currents. Current flowing through a coil produces torque, and three servo currents algebraically sum their torques to position a device like a fuel control valve or the IGVs.

4-20 mA analog outputs are kind of unusual, in that they are output at the I/O card level, based on the inputs from the application code. It's difficult to explain, but I believe if you red the VAIC or VAOC card descriptions in the Mark VI System Guide you can get more detailed information. As always, if you have specific questions, you can ask them here.

Before SIFT, each control processor was independent of each other control processor, and signals were 'voted' by a communicator processor (called <C>). Because they were not synchronized like Mark VI (and Mark V and Mark VIe), they were subject to different problems, that sometimes resulted in un-annunciated turbine trips because one processor could think the turbine should be tripped because of low-low L.O. pressure, but the turbine wouldn't trip--but it a second processor though the turbine should be tripped because of an IGV servo error, then the turbine would trip, but there would only be a LOSS OF FLAME alarm, because two processors didn't agree on why the turbine should be tripped, but two processors did agree the turbine should be tripped--so no Process Alarm. The fuel stop valve would close, but the only alarm would be LOSS OF FLAME--BUT there would be LOTS of
Diagnostic Alarms (but nobody pays any attention to Diagnostic Alarms, right???).

SIFT fixed a LOT of nuisance trips and un-annunciated trips and other problems, by having each processor know what every other processor's signal values were (the voted signals, that is) and using the voted signal when executing its application code. Theoretically, all three processors will use the same values when executing the application code, and will make the same determinations and the outputs should all be the same. When everything is working correctly, and there are no Diagnostic Alarms.

Hope this helps! It's not an easy topic without being able to share drawings.

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

Chiranjeevi and CSA,

Thank you very much. I am taking my time reading the above posts. Again, Thank you

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

while the below detailed explanation applies to a MKV, this approach does not carry over in its entirety and completeness!

I will leave this right here..


The above descriptions are not intended to be 100% complete--the topic is too big and there are too many signals to cover precisely how each one is handled in detail. We can always discuss individual signals if necessary.

As for being relative to Mark V or Mark VI, the original poster asked about TMR Mark VI, and I tried to make my descriptions as specific to Mark VI as possible. If I have mis-spoken or am incorrect (I have been incorrect in the past, and I have not always described things in the best possible manner), I welcome corrections or am happy to make clarifications. The subject is very big, and can be very complicated, and it's not always easy to explain--and I do make mistakes from time to time and I am not offended by corrections. In fact, I welcome them because I want to be correct and not to mislead anyone unintentionally.

In general SIFT is the same for most of the versions of the Mark* beginning with Mark V. But, for some signals, things have changed--specifically, the P2 pressure control via the SRV.

In the Mark V, the servo regulator compared the P2 pressure reference to the P2 pressure feedback at the I/O card level, and the LVDT signals (from redundant SRV LVDTs) was high-selected at the I/O card level with the high value being used by the servo regulator. The servo regulator type specified in the I/O Configurator was a type 7x, where the second character reflected how the servo and pressure transmitter(s) connected to the Mark V (at the terminal board(s) interacted. There could be one P2 pressure transducer (paralleled to all three control processors), or there could be three P2 pressure transducers, one connected to each of the three control processors.

I don't know exactly when this change was made, but most Mark VI panels (but not every Mark VI) started comparing the P2 pressure reference to the actual P2 pressure reference in application code--running in the control processor (the UCVx). And, the output of that was sent to the servo regulator on the VSVO card (usually) to compare against the high-selected LVDT feedback which was made at the VSVO card. If redundant P2 pressure transducers were used, the application code (which is downloaded to all three control processors) in each of the control processors would choose the desired value (usually median) for use in comparing to the P2 pressure reference--in each control processor (the UCVx).

Discrete outputs, for a TMR control, are voted at the I/O card level--the VCRC (usually, for a Mark VI) and the TCQC for a Mark V. 2-out-of-3 control processors must indicate the output should be picked-up (true) for it to go true. It's how the wires are terminated at the TRLY card that determines if the output will be powered ("wet") or unpowered ("dry").

As for the 2-out-of-3 hardware relay voting, that only takes place on the TCTG/S/L (in the Mark V), or the TRPG/TREG combination in the Mark VI. In both the Mark V and Mark VI there are two sets of hardware-voted relays--the PTRs (Primary Trip Relays) and the ETRs (Emergency Trip Relays).

Finally, I'm aware that GE is transitioning from pressure switches to pressure transmitters, and from temperature switches to temperature sensors (such as T/Cs or RTDs) for many alarm/trip functions (such as L.O. temperature in the above descriptions). That's a huge change for GE, but it's possible because transmitters have become cheaper and more reliable over decades, and control system I/O has become cheaper per channel. The L.O. temperature switches were just an example of SIFT voted I/O--and even that was not identical on every turbine, which was true for most Mark Vs used on GE-design heavy duty gas turbines, and most Mark VIs, as well. It wasn't until later in the Mark VI product life that the use of transmitters and temperature sensors for applications that previously used pressure- or temperature switches.

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


This is a very interesting topic, I'll try not to repeat what was already said, but I have some thoughts I'd like to share.

Well, starting with the concepts, when one says that a system is 'M' out of 'N', it basically means that it is composed of 'N' independent channels which are connected in a way that 'M' channels are sufficient to perform the function. It is a concept very well consolidated in IEC61508/IEC61511/ISA 18.2.

For example, if you have a 1oo3 system, it means that it only requires that 1 channel (out of 3) is 'trigged' to execute the subsequent logic (or the function it was projected for). The decision to use 1oo3, 2oo3 or even 1oo4, for example, generally is related to the reliability your system need to perform this function. It can be, for example, a SIF (Safety Instrumented Function) there was projected to mitigate some process risk, and as the initiators (or final elements) have probabilities of failing dangerously (false measurements, valve stuck, etc), you may require 1oo2, 1oo3 or some other kind of architecture to guarantee a certain probability of dangerous failure of your SIF (called PFD/PFH which is a probability of dangerous failure on demand/per hour). However, these calculations do not account for safe failures (spurious), since it would get the process to a safe condition. So sometimes it is interesting to use for example 2oo3 architecture (or 1oo2D, with D meaning 'intelligent and independent diagnostics'), which combines high availability and high reliability (generally speaking). But don't forget that there are many calculations behind these definitions and selection of proper architecture.

Another interesting concept is 'fault tolerance', which is the ability of the system to continue to perform a required function in the presence of faults or errors. Basically it is defined as 'M minus N', for example, a 1oo3 system have a fault tolerance of 2, that is, even if 2 channel fail (in a dangerous way), the third one can still perform its function and take the process to a safe condition. 2oo3 systems have a fault tolerance of 1, because if 2 of them fail (dangerously), the system will not be able to perform the required function and so it can lead to an accident.
If the failures are detected, then the system may execute its function even if the good channel is not triggered, by means to achieve the probability of failure it was projected for.

So, in my opinion, when people say (commonly) that the processors are 'using a voted' value, they actually talking about a selection type and not a MooN, which is the architecture. It can be high selection, low selection, median selection, etc and the system will choose what to do with the selected value. For example, 3 transmitters connected to 3 AI cards, goes through a median selection, and the same resulted value is sent to the processors and then it is compared to the threshold.

The difference is subtle, but another situation would be when each processor takes its own input, checks against a threshold value, and 'vote' for what to do. In this situation, there isn't a proper selection, but a MooN architecture where requires N channels to be triggered to perform its function.

So when CSA says that 'In my opinion, high-selecting or median-selecting or low-selecting of signals is not technically voting.', I totally agree.

Another very important point talked about here is about diagnostics and alarms. They have to be 100% clear. Also, every alarm MUST HAVE a specific action that shall be taken by someone (operator, maintenance, etc) and a determined time to act. If when the alarm occurs there isn't a clear action to mitigate it, then it should not be an alarm. If you have infinite time to act, it shouldn’t be an alarm. Etc etc etc. The alarms must be rationalized so everyone trusts the system and know for sure that when an alarm occurs, something SHALL be done and it CAN NOT be ignored.

If you have a poor configured alarm system, people start to ignore alarms (because there are so much of them and so they are so confusing) and then bad things happens (it can be 'as good as' a safe stop, causing low availability (and loss of money), but it can also be a dangerous failure which can harm people).

Well, each topic mentioned here in this post is a long long subject. I'm not an expert in any of them, but I hope I could contribute somehow.

Also, I don't think I exactly understood when CSA said 'And, NO, no one can tell you exactly which combinations of Diagnostic Alarms will result in a turbine trip.'.

Best regards!

Non GE TMR systems such as those by Triconex or ACS Triplex have true 2oo3 voting for all inputs. Every I/O input has 3 channels that are voted on. All DO's have 4 solid state switches in a H pattern that are voted by A, B, C and A+B channels. All communication is triplicated. Backplane communication busses for processor and I/O have 3 channels, and the inter chassis communication is also via 3 separate cables.

In our control strategies for regulatory process control, when we use multiple analogue inputs for a control loop, we may use mid select if we have 3 inputs or a transmitter select with trip to manual on deviation. Once the deviation is fixed or bypassed with the good input selected the loop can be put back into auto.

The 3 input mid select will also have a dev alarm and trip to detect a bad or varying input.

Analogue outputs usually just have redundant I/O cards.