The high/low signal selector is the small, decisive block that makes override and constraint control possible. It takes several input signals, usually the outputs of competing controllers, and passes just one of them onward: a high selector passes the highest, a low selector passes the lowest. That single choice is how a control system decides, moment to moment, which controller gets to drive the valve, letting whichever limit is currently most pressing win. This guide explains the selector's auctioneering behavior, how high-select and low-select implement override, and why the controllers that lose the selection must track the winner to bump back in cleanly.
High/Low Signal Selector in one line: A high/low signal selector is a control block that receives several input signals and outputs one of them: a high-select block passes the highest input, a low-select block passes the lowest. When the inputs are competing controller outputs, the selector decides which controller drives the final element, which is the mechanism behind override and constraint control. The losing controllers must track the selected output to avoid windup so they can take over smoothly when their limit becomes binding.
A signal selector is one of the simplest blocks in a control system and one of the most powerful in what it enables. In its basic form it takes two or more input signals and outputs a single one according to a rule: a high-select block, sometimes written HSS, outputs the highest of its inputs at every instant; a low-select block, or LSS, outputs the lowest. There are related forms, a median selector passes the middle of three, useful for voting among redundant measurements, but the high and low selectors are the workhorses of override control. The block continuously re-evaluates, so as the inputs change, which one is passed can change from moment to moment.
This behavior is often called auctioneering, and the metaphor is apt. Each input is like a bidder, and the selector runs a continuous auction in which the highest or lowest bid wins the right to pass through to the output. When the inputs are the outputs of different controllers all reaching for the same final element, the selector is effectively deciding which controller wins control of the valve at each instant. The controller whose output is selected drives the process; the others are, for that moment, out of the loop, their outputs computed but not used.
The choice of high-select versus low-select depends on the direction of the action and which way is safe. If a valve should be driven to the more open, higher-output position whenever any controller demands it, or held back to the lower position, the selector is chosen so the correct controller wins in the situation that matters. The selector itself is purely mechanical, it just compares numbers, but wiring the right controllers into the right kind of selector is how the control engineer expresses which loop should take precedence under which conditions.
Override control is built almost entirely on selectors. The idea is to have a normal controller that runs the process for its usual objective and one or more override controllers that each guard a limit, all feeding their outputs into a selector that passes just one to the final element. In ordinary operation the normal controller's output wins the selection and runs the process. When the process approaches a limit that an override controller guards, that controller's output moves toward taking over, and once it becomes the selected signal it seizes control of the valve and holds the process at the limit, overriding the normal controller until the danger passes.
This is exactly the machinery behind constraint control. Running a process against its most limiting constraint means letting whichever constraint is currently binding take control, and a selector is what hands control to that active constraint automatically. A controller pushing for throughput and several constraint controllers each holding a limit feed a selector; the most restrictive output wins, so the process is driven forward until it hits a constraint, at which point that constraint's controller wins the selection and pins the process at the edge. As conditions change and a different constraint becomes tightest, its controller starts winning instead, and control passes to the new active limit without any explicit switching.
What makes the whole scheme robust is that the selector needs no logic beyond comparing signals, yet it produces sophisticated behavior, seamless handover between objectives and limits, from a single, transparent rule. There is no mode switch to get stuck, no sequence to fail; whichever controller is most demanding in the selected direction simply wins, and the transition from one controller being in charge to another is inherent in the continuous comparison. This simplicity and predictability is why selectors, rather than more elaborate switching logic, are the standard way to build override and constraint schemes in the regulatory layer.
The one thing that will wreck a selector scheme if ignored is windup in the losing controllers. A controller that has lost the selection is still receiving its measurement and computing an output, and if it has integral action, that integral will keep accumulating as the controller tries and fails to influence a process it is not currently driving. By the time conditions change and it is finally selected, its output has wound far past anything reasonable, and it will slam the valve when it takes over, a violent, dangerous bump instead of a smooth handoff. This is the classic failure of a naively built override scheme.
The fix is anti-windup tracking, sometimes called external reset or back-calculation. The actual selected output, the signal that really goes to the valve, is fed back to every controller as a tracking or reset feedback signal, so a controller that is not selected keeps its internal state aligned with the real output rather than integrating away on its own. Kept in step with reality, a losing controller sits poised right at the value that matters, and when its limit becomes binding and it wins the selection, it takes over from exactly where the process actually is, bumping in cleanly with no jolt. Tracking is not an optional refinement; it is what makes selector-based override usable at all.
For processes monitored through SCADA, selector schemes are far easier to run and to trust when the selection itself is visible. It is genuinely useful for an operator to see which controller is currently winning the selector, that is, which loop or which constraint is actually in command of the valve at any moment, because that reveals what is holding the process back and whether it is the limit they expect. A cloud SCADA that historizes each controller's output, the selected signal, and which input won lets a team watch override handovers happen, confirm that tracking is keeping the losing loops in step, and diagnose a scheme that is behaving oddly, and it lets them do it for remote and unmanned sites where an operator can never see the panel in person.
A high-select block outputs the highest of its input signals at every instant, while a low-select block outputs the lowest. Both continuously compare their inputs and pass just one onward. Which one is used depends on the direction of the control action and which controller should win in the situation that matters, since the selected signal is the one that drives the final element. A related median selector passes the middle of three inputs, often used for voting among redundant measurements.
A normal controller and one or more override controllers, each guarding a limit, all feed their outputs into a selector that passes just one to the final element. Normally the normal controller wins and runs the process, but when a guarded limit is approached, that override controller's output takes over through the selector and holds the process at the limit. This lets whichever loop is most pressing win control of the valve automatically, which is the essence of override and constraint control.
A controller that has lost the selection is still computing an output, and if its integral action keeps accumulating while it is out of the loop, it winds up and will slam the valve when it is finally selected. Anti-windup tracking feeds the actual selected output back to every controller as a reset feedback, so the unselected ones keep their internal state aligned with the real output. This lets whichever controller next wins the selection take over smoothly from where the process actually is, with no jolt.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.