PID Control with SCADA: What Runs in the Control Room and What Runs in the Field?

A SCADA screen may show a pressure setpoint, the actual pressure, pump speed and PID output on the same page. That does not necessarily mean the SCADA server is performing the fast PID calculation.

In many industrial systems, SCADA provides supervision, visualization, alarms, historical data and operator access, while the closed control loop runs locally in a PLC, RTU, DCS controller, VFD or dedicated process controller.

This distinction becomes important the moment the network becomes slow, a remote station drops offline or somebody starts troubleshooting a loop that refuses to settle.

The control room may tell the process where it should operate; the local controller is usually responsible for keeping it there.

A PID Loop Does Not Need the SCADA Screen to Stay Open

Consider a remote pumping station. A pressure transmitter measures the discharge pressure and sends its signal to the local controller. The controller compares that measurement with the required setpoint and changes pump speed accordingly.

The operator may enter the pressure setpoint from SCADA, but once that value has been accepted by the controller, the local PID loop can continue working without waiting for the SCADA display to refresh every cycle.

A simplified signal path looks like this:

Pressure transmitter → PLC / RTU → PID loop → VFD → Pump → Pipeline → Pressure transmitter

SCADA sits above that loop. It reads values from the controller, presents them to the operator, stores selected data and may write approved commands back to the station.

That architecture is very different from placing the control loop entirely inside a Windows application and relying on a network round trip for every PID calculation.

SP, PV and Output: The Three Values Worth Putting on One Screen

A useful PID faceplate should make three values easy to distinguish.

SP — Setpoint: the value the process is expected to maintain.

PV — Process Variable: the measured value coming from the field.

Output / MV / CV: the command generated by the controller to influence the process.

If a pipeline is required to operate at 6 bar, 6 bar is the SP. The pressure measured by the transmitter is the PV. The resulting pump-speed command or valve-position command is the controller output.

A well-designed SCADA screen should make it possible to see these values together. Seeing only the pressure measurement is useful for an operator; seeing SP, PV and output together is far more useful for someone diagnosing the control loop.

The Sensor Signal Comes Before the PID Mathematics

The PID controller can only react to the value it receives. If that value is wrong, perfect tuning will still produce the wrong result.

A pressure transmitter, temperature transmitter, flowmeter or level sensor may send a standard analog signal to the controller. Common industrial formats include 4–20 mA and 0–10 V.

Suppose a 0–10 bar transmitter is configured as:

4 mA = 0 bar
20 mA = 10 bar

The PLC analog input receives current, not “bar”. The signal must therefore be converted into an engineering value before it is used by the PID loop.

If 12 mA is incorrectly scaled as 4 bar when the real process value should be 5 bar, the controller will react to a measurement error that does not physically exist.

Do not tune around a bad measurement. Check the instrument range, analog input, scaling and engineering units first. The principles behind these signals are covered further in analog signal measurement and control.

Example: One Remote Pump Station, Two Very Different Time Scales

Imagine a water distribution station several kilometres away from the control room. The local PLC reads a pressure transmitter and controls a pump through a VFD.

The PID calculation may need to run at a regular interval determined by the process and controller design. Meanwhile, the SCADA server may poll the remote station every second, and the historian may store a value only every few seconds or on a significant change.

These are three different timing requirements.

PID execution interval ≠ SCADA screen refresh ≠ historian logging interval.

Confusing them can create very strange troubleshooting decisions. A trend that contains one point every five seconds cannot show every detail of a control loop running much faster than that.

The effect of delay and process response is examined separately in PID control with time delay and process dynamics.

Where Should the PID Calculation Run?

There is no rule saying that a PID algorithm can never run on a PC. Industrial PCs, soft-PLCs and real-time software platforms can perform closed-loop control successfully.

The more useful question is: what happens to this process if communication becomes late, irregular or unavailable?

For many plant applications, placing the loop in the local PLC, RTU, drive or controller gives the process a predictable execution environment and allows it to continue controlling even when the supervisory network is unavailable.

A standard PLC PID implementation, for example, can continue reading its local analog input and updating its local output without depending on whether the SCADA client is currently connected.

This timing issue is particularly relevant to real-time PID control.

What Happens When SCADA Communication Is Lost?

A communication failure should be treated as a designed operating condition, not as a surprise.

If the SCADA server loses contact with a pumping station, the local pressure-control loop may be able to continue at its existing setpoint. In another process, the correct response may be to fall back to a predefined value, stop an operation or enter another safe operating state.

The answer depends on the machine and process.

What should not happen is an undefined state where nobody knows whether the last command is still active.

The local program should define the required behaviour, while SCADA indicates that the data quality or communication status is no longer normal.

Operators also need to know the difference between:

• a real process value,
• the last value received before communication was lost,
• an invalid or bad-quality value.

Displaying an old pressure value as though it were still live can be more dangerous than displaying no value at all.

Should Operators Be Allowed to Change PID Gains?

SCADA can provide access to Kp, Ki, Kd or Kp, Ti and Td parameters if the underlying controller exposes them. That does not mean every logged-in operator should be able to change them.

PID gain changes alter the dynamic behaviour of the process. A badly chosen value may create oscillation, excessive overshoot or a response so slow that the process never reaches its target in useful time.

On larger systems, PID tuning pages are often better placed behind an engineering or maintenance permission level. Changes can also be logged so that a sudden change in process behaviour can be compared with recent parameter edits.

An unexplained tuning change at 02:00 is much easier to investigate if SCADA recorded who made it.

Manual and Automatic Operation Need More Than Two Buttons

In automatic mode, the controller determines the output from the control algorithm. In manual mode, a permitted user or another part of the control program may directly establish the output.

A SCADA faceplate may provide the request to change between these modes, but the controller should decide whether the request is permitted.

For example, a pump may be prevented from entering manual operation while a critical interlock is active. A valve output may also need physical limits regardless of what value an operator enters.

Another detail is the transition from manual back to automatic control. If the controller output suddenly jumps from the manual value to a very different PID value, the process can be disturbed immediately.

Where supported, bumpless transfer, tracking and suitable initialization should be considered as part of the control strategy.

The Trend Display Is One of the Best PID Troubleshooting Tools

SCADA becomes especially useful when a control problem happened twenty minutes ago and is no longer visible on the live screen.

For meaningful diagnosis, trend these values together where practical:

• Setpoint
• Process value
• Controller output
• Auto / Manual state
• Actual VFD speed or valve feedback
• Relevant process alarms

Different patterns point toward different problems.

If the PV oscillates regularly around the setpoint while the control output also swings back and forth, tuning and process dynamics deserve attention.

If the output remains at 100% for several minutes but pressure never reaches the setpoint, the first question should not be “Which PID gain should we increase?” The pump, valve, pipework or process demand may simply have reached its physical limit.

If the PID output changes correctly but the VFD does not follow it, investigate the command path, drive state, limits and interlocks.

More general symptoms are covered in common PID problems and troubleshooting.

SCADA Can Show the Problem Without Being the Cause

This is worth remembering during maintenance. The SCADA screen is often where a bad process first becomes visible, so it is also the first thing people blame.

A pressure value that jumps randomly may originate from a damaged transmitter, poor shielding, a loose terminal or an analog input problem.

A pump that stays at maximum speed may be responding correctly to an impossible setpoint.

A valve that never reaches the controller output may have a mechanical or pneumatic problem.

The supervisory screen is the observation point. The fault may be several layers below it.

PID Pressure Control Through a VFD

A common SCADA application is a variable-speed pump maintaining line pressure. There are several valid ways to arrange the loop.

In one design, the transmitter is wired to the PLC, the PLC executes the PID controller, and an analog or network command is sent to the VFD.

In another design, the VFD itself receives the pressure feedback and runs its own PID function while the PLC and SCADA supervise the drive.

The second arrangement can reduce the number of control layers involved in a simple pumping application. The first may provide more flexibility when several pumps, valves, operating modes or plant-wide sequences have to be coordinated.

The drive-side approach is described in PID control with a VFD, while the process behaviour itself is covered in PID pressure control.

Temperature, Flow and Level Do Not Behave Like Pressure

A SCADA project may contain hundreds of PID loops, but that does not make them interchangeable.

A temperature loop may respond over minutes. A pressure loop may react much faster. A tank-level loop may tolerate a slow response and can behave as an integrating process. A flow loop may react quickly but suffer from noisy measurements.

This is why the same Kp, Ki and Kd values should not be copied from one process to another merely because the SCADA faceplates look identical.

Related applications include PID flow control, PID level control and PID with temperature controllers.

Alarms Are Not a Substitute for Control — and PID Is Not a Safety System

Suppose a pressure loop normally operates at 6 bar. The PID controller attempts to maintain that operating value. The SCADA high-pressure alarm might be configured at a higher process threshold.

These are separate functions.

A process alarm warns that operation has moved outside an expected range. A control loop attempts to regulate normal operation. A required protective or safety function must be designed according to the hazards and applicable machine or process safety requirements.

Do not assume that a standard PID block plus a red alarm on the SCADA screen constitutes an independent safety layer.

A Practical Check When a SCADA PID Loop Looks Wrong

Before changing the gains, follow the signal path once from the field to the actuator:

1. Is the sensor physically reading the correct process?
2. Does the PLC receive the correct electrical signal?
3. Is the value scaled into the correct engineering unit?
4. Are SP and PV using compatible units?
5. Is the loop in the expected Auto or Manual mode?
6. Is the PID output moving in the correct direction?
7. Does the valve, pump or VFD actually follow that output?
8. Is the process physically capable of reaching the requested setpoint?

This short check often finds problems that no amount of PID tuning will repair.

Related SCADA and PID Topics

SCADA and controllers: What is SCADA? · PLC and Modules · PID Control with PLCs

Measurement and feedback: Analog Signals · 0–10 V and 4–20 mA · Pressure Sensors

Process PID: Pressure Control · Flow Control · Level Control · PID with VFDs

PID behaviour and tuning: PID Control FAQ · PID Gain and Tuning · Time Delay and Process Dynamics · PID Troubleshooting

SCADA, PLC and PID architectures vary considerably between plants and manufacturers. Control execution time, communication-loss behaviour, output limits, manual/automatic transfer and protective functions should always be designed and verified for the actual process and the controller being used.