Where the Logic Should Live: Controller, SCADA, or Relay

Walk into a plant that is hard to run and the logic is scattered. The pump alternation is in a relay because the integrator ran out of time. The high level alarm is evaluated in SCADA because the screen builder found it easier. A permissive lives in a script on the historian server, and nobody knows why the filter will not start on Tuesdays. None of those decisions was unreasonable on the day it was made. Each one put a piece of the process where it was convenient rather than where it belonged, and the plant has been paying for it ever since.

Three homes, three jobs

A control system has three places that can make a decision, and each is good at one kind of decision. The controller scans every few milliseconds, keeps running when the network is gone, and can act on its outputs directly. SCADA sees everything across the plant, talks to people, and keeps records. A relay does one thing with no software at all and does it whether or not anything else is alive. The rule that follows is simple to state: a decision goes to the lowest layer that can make it well, and the layers above it read the result rather than making it again.

The controller owns the process

Anything that decides what equipment does belongs in the controller. That includes the obvious, sequences and interlocks and level control, and the less obvious: alarm conditions, setpoint limits, and the mode logic that says whether a device is available. The reason is not that controllers are better computers. It is that the controller is the only layer that is guaranteed to be present when the equipment runs. A permissive evaluated in SCADA stops protecting the pump the moment the SCADA server reboots, and it protects the pump wrongly when the network is slow and the value on the server is a minute old. The same permissive in the controller sees the valve limit switch every scan and acts on the starter directly, and a SCADA outage changes nothing about how the pump behaves.

Alarm conditions are the case most often argued. It is tempting to set the high level limit in SCADA because SCADA has a nice alarm configuration screen and the limit is easy to change there. But the alarm condition is also what the controller uses to start the lag pump and to drive the local horn, and if SCADA evaluates it separately the two will disagree the first time someone changes one and not the other. The controller decides that the level is high, once, with a setpoint and a deadband and a delay that SCADA can read and, within limits, write. SCADA takes the bit and does what it is good at: shows it, prioritizes it, records it, and calls someone.

SCADA owns the people

The things SCADA should decide are the things that involve people: which alarm is urgent enough to wake the on-call operator, how the plant overview is drawn, which report goes to the state each month, how long history is kept. None of those needs to work when the network is down, because with the network down there is nobody to show anything to. SCADA is also the right home for calculations that span the plant, such as a daily flow balance or a chemical inventory, because the controller in one building does not know what the controller in another is doing and should not have to.

What SCADA should not do is close a control loop or hold an interlock. A level loop running on a SCADA server is a loop that stops when the server patches, and an interlock in a SCADA script is an interlock that stops when the script errors. Both have happened at plants that later could not explain why the tank overflowed on the night of the Windows update.

Relays own the dead-controller case

There was a time when relay logic was the control system, and some plants still carry the habit of solving problems with a relay because a relay is quick and the panel shop has a drawer of them. The discipline now is that a relay does logic only when the logic must work with the controller dead. That is the backup float circuit at a lift station, the emergency stop, a guard interlock, and a few monitoring relays that trip a starter directly. Everything else in relays is invisible to SCADA, undocumented after the first change, and the reason a pump runs when the program says it should not.

The cases that get argued

Setpoint clamps

The controller enforces the limit, because it is the last line. SCADA also clamps the entry field so the operator gets a message instead of a silent rejection. Two clamps are fine when the controller is the authority and SCADA reads the limit from it.

Runtime alternation

In the controller, because it changes which pump starts, which is a process decision. SCADA displays the hours and lets an operator fix the lead, logged.

Communication loss

The controller detects a lost link with a watchdog and holds a safe state; SCADA raises one communication alarm and marks the data stale. Both layers act, but on their own concerns.

Chemical dose calculation

In the controller when the pump is paced by it, because the pump runs whether or not SCADA is up. The dose the operator enters comes through SCADA with limits.

Scheduling by time of day

The controller runs the schedule from its own clock, synchronized by SCADA. A schedule that only exists on the server stops when the server stops.

Totalizers

In the controller for the value the process uses, in the historian for the report. They should agree, and the controller total is the one that survives a historian gap.

How a plant drifts

Nobody designs logic into the wrong layer. It drifts there. An integrator under time pressure puts an interlock in a SCADA script because the controller program is locked for the day. A technician solves a nuisance trip with a relay because the programming laptop is at the other plant. A screen builder adds an alarm in SCADA because the alarm list came late. Each is a small, sensible shortcut, and the sum is a plant nobody can reason about. The defense is a written rule, in the design standard, that says where each kind of decision lives, and a review at every change that asks the question.

The one question

For every piece of logic there is one test: what happens when the layer above disappears. If the answer is that the process misbehaves, the logic is too high. A permissive that vanishes with SCADA belongs in the controller. A backup that vanishes with the controller belongs in a relay. Ask the question at design, ask it at every change, and the plant stays one that a technician can understand at two in the morning with the drawing and a meter.