SCADA HMI: How PLC Ladder Logic Drives Process States

Posted on by

A SCADA HMI system shows process conditions and sends operator commands, while the PLC evaluates those commands with control logic and drives field outputs. The HMI or SCADA command is not proof that a motor, valve, or pump has physically operated; proven feedback must come from the field.

A small tank-fill process makes the separation clear. The PLC reads level switches, permissives, and motor feedback, executes a PLC ladder diagram, and controls a pump. HMI and SCADA tags expose commands, states, alarms, and history without replacing the controller.

SCADA HMI roles: How PLC, HMI, and SCADA work together

PLC: Scan inputs, execute logic, and drive outputs

The PLC is the real-time controller. Its input modules receive physical signals such as a low-level switch, high-level switch, emergency-stop circuit, motor overload contact, and pump-running feedback. Its output modules send signals to devices such as a motor starter, contactor, solenoid valve, or variable-frequency drive.

In a typical scan, the PLC reads the input image, executes the program from top to bottom, updates internal tags, and writes output states to the output modules. The exact scan time depends on the controller and program, but the sequence is continuous. A physical input that changes during one scan may not affect an output until the next scan or later, depending on input filtering, task priority, and output hardware.

A ladder logic PLC program generally uses permissives and interlocks to prevent unsafe or unwanted operation. For example, the pump may run only when the emergency stop is healthy, the overload is clear, the tank is not at high level, and an operator or automatic mode has requested filling.

HMI and SCADA: Command, display, alarm, and record

An HMI is the local operator interface. It can provide Start, Stop, Auto, Manual, and Reset controls, display tank level and pump status, and show active alarms. The HMI usually reads PLC tags over an industrial network and writes command tags when an operator selects a control.

SCADA adds supervisory functions across one or more controllers. It can provide central displays, alarm management, user permissions, reports, trends, and historical storage. SCADA may use the same PLC tags as the HMI, but it does not directly substitute for the PLC’s interlocks or output logic.

For example, a Start button can set FillStartCmd to true. The PLC still decides whether the pump output may turn on. A separate PumpRunFB tag should confirm that the motor starter or drive reports operation. A displayed command is therefore different from a proven output state.

How to read a PLC ladder diagram

Contacts, coils, branches, timers, and interlocks

A ladder diagram is organized into horizontal rungs between left and right rails. The PLC evaluates each rung from left to right. A contact represents a condition. A normally open instruction is true when its referenced tag is true; a normally closed instruction is true when its referenced tag is false. The symbols describe logic behavior, not necessarily the physical construction of the input device.

A coil writes a result to an output or internal tag when the conditions preceding it are true. In a simple motor rung, contacts for RunRequest, EStopOK, and OverloadOK may lead to a PumpStart coil.

Parallel branches represent OR logic. If either a local Start pushbutton or an HMI start command is true, a branch can create the same start request. Series contacts represent AND logic: every required condition must be true before the coil is energized.

Interlocks add conditions that must block an action. A high-level contact can prevent filling, while a low-level contact can initiate automatic filling. A permissive confirms that operation is allowed; an interlock identifies a condition that must stop or inhibit operation. Some programs use latched coils or set/reset instructions to retain a state after a momentary command. These require an explicit reset or stop path.

Timers add time-based behavior. An on-delay timer can require a condition to remain true for a defined period before allowing an action. An off-delay timer can keep an output or status true briefly after a condition disappears. A timer also provides a useful basis for detecting failure: if a pump-start command is true for five seconds but running feedback remains false, the PLC can set a start-failure alarm.

Inputs, outputs, tag states, and scan behavior

Physical inputs include switches, transmitters, feedback contacts, and safety devices. Physical outputs operate equipment. Internal tags store commands, modes, state values, timer results, permissives, and alarms. A tag name should make its meaning clear, such as TankHigh, FillRequest, PumpOutput, or PumpRunning.

During one scan, the PLC may read FillStartCmd as true, calculate FillRequest as true, and turn on PumpOutput. The motor feedback may remain false until the starter closes and the auxiliary contact changes. The HMI should show these as separate states rather than immediately labeling the pump as running.

Commands may be momentary pulses or maintained values. A robust design defines how a command is consumed, cleared, acknowledged, or rejected. It also defines what happens if a network update is delayed or a communication link fails.

Worked PLC ladder logic sequence for a tank-fill process

Field I/O, permissives, and the tank-fill states

Consider a tank filled by one pump. The field inputs are:

  • TankLow: low-level switch is active.
  • TankHigh: high-level switch is active.
  • EStopOK: emergency-stop circuit is healthy.
  • OverloadOK: pump overload is clear.
  • PumpRunFB: motor starter or drive confirms that the pump is running.

The physical output is PumpOutput. HMI and SCADA provide AutoModeCmd, FillStartCmd, FillStopCmd, and AlarmResetCmd. Internal PLC tags include FillRequest, FillPermissive, PumpStartTimeout, and FillState.

The process has four useful states:

  1. Idle: the pump is stopped and no fill request is active.
  2. Filling: the PLC has commanded the pump and is checking running feedback.
  3. Complete: the high-level switch has stopped the fill.
  4. Fault: a permissive is lost, a timeout occurs, or an abnormal level condition is detected.

The intended behavior is simple: in automatic mode, a low-level condition creates a fill request. The request remains active until the high-level switch becomes active or a stop, interlock, or fault removes it. Manual filling may use an HMI start command, but the same high-level and safety interlocks still apply.

The worked PLC ladder logic sequence

The following rung descriptions show the logic without depending on a particular PLC manufacturer’s syntax:

  1. Permissive rung: place normally open contacts for EStopOK and OverloadOK in series. Their combined result energizes FillPermissive. If either condition is false, the permissive is false.
  2. Automatic request rung: place AutoModeCmd in series with TankLow. Add a branch for a maintained manual or HMI start request if manual operation is permitted. The branch result creates FillRequest.
  3. Stop and high-level logic: use TankHigh, FillStopCmd, and loss of FillPermissive to reset or remove FillRequest. A high-level condition has priority over a start command.
  4. Output rung: place FillRequest and FillPermissive in series with a normally closed TankHigh interlock. The resulting coil is PumpOutput.
  5. Start verification rung: when PumpOutput becomes true, start a five-second on-delay timer. If PumpRunFB does not become true before the timer expires, set PumpStartTimeout and remove the run request.
  6. State rung: set FillState to Filling when PumpOutput is true and PumpRunFB is true. Set it to Complete when TankHigh is true with no active fault. Set it to Fault when the timeout or a critical permissive failure occurs.

This arrangement keeps the control decision in the PLC. The HMI can request filling, but the PLC prevents the output if the tank is high, the emergency stop is open, or the overload has tripped.

Expected-state test from start command to proven output

An expected-state test checks each transition rather than only checking whether the final pump output is on:

  1. With the tank below the low switch, place the system in automatic mode. Expected result: TankLow, AutoModeCmd, and FillPermissive are true; TankHigh is false; FillRequest becomes true.
  2. On the next PLC scan, expected result: PumpOutput becomes true. The HMI may show a start command accepted or a pump-starting state, but it must not yet claim proven running.
  3. Within five seconds, the starter auxiliary contact changes. Expected result: PumpRunFB becomes true, the timeout remains false, and FillState becomes Filling.
  4. When the tank reaches the high switch, expected result: TankHigh becomes true, FillRequest resets, and PumpOutput turns off.
  5. If PumpRunFB does not arrive within five seconds, expected result: PumpStartTimeout becomes true, the pump request is removed, and the HMI and SCADA alarm state becomes active.

Map tags, commands, status, alarms, and history to HMI/SCADA

Map command tags separately from proven status tags

Command tags represent operator intent. Status tags represent controller decisions or field feedback. A practical mapping includes:

  • Commands: AutoModeCmd, FillStartCmd, FillStopCmd, and AlarmResetCmd.
  • Controller status: FillRequest, FillPermissive, PumpOutput, and FillState.
  • Proven field status: PumpRunFB, TankLow, TankHigh, EStopOK, and OverloadOK.
  • Diagnostics: PLC health, tag-quality status, communication heartbeat, scan watchdog, and last command result.

The HMI can show a Start button changing to “requested,” followed by “starting,” “running,” or “failed to start.” The running indication should use PumpRunFB, not merely FillStartCmd or PumpOutput. A command acknowledgment can confirm that the PLC received and accepted a request, but only field feedback confirms equipment operation.

Define alarm conditions and communication-loss behavior

Useful alarm conditions include high-high level, pump start failure, overload trip, emergency-stop open, and an unexpected running condition. For example, an unexpected running alarm can occur when PumpRunFB is true while PumpOutput is false. The alarm priority, delay, acknowledgment requirement, and reset condition should be defined in the PLC or the alarm system consistently.

Communication loss requires a deliberate design. The PLC should continue its local safety and process interlocks if the HMI or SCADA connection disappears. A heartbeat can detect a stale supervisory connection, but loss of SCADA communication should not by itself prove that the pump has stopped. The display should mark affected values as stale or unavailable.

For a command channel, the PLC can reject new HMI commands when the heartbeat is lost, clear a timed-out momentary command, or transfer control to a defined local mode. The chosen behavior must be visible through a CommLoss status and should not bypass the high-level, emergency-stop, or overload interlocks.

Record state changes and values in SCADA history

SCADA history should record the events needed to reconstruct the fill cycle: command time, command source, FillState changes, PumpOutput, PumpRunFB, tank-level values or switch transitions, alarm activation and acknowledgment, permissive loss, and communication quality.

Historizing both command and proven status exposes delays and failures. A record may show that FillStartCmd was issued at 10:02:00, PumpOutput changed at 10:02:01, and PumpRunFB arrived at 10:02:03. If the feedback never arrives, the same history supports the start-timeout diagnosis instead of incorrectly recording a successful pump run.