Why Two SCADA Screens Disagree About the Same Pump

Two screens show the same pump differently. The overview says stopped; the maintenance report says faulted. Both worked the state out for themselves, straight from raw signals. The fix is to derive it once and write down the order the checks run in: BadQuality, Unavailable, Faulted, Local, Starting, Stopping, Running, Stopped, Unknown, evaluated top down, stopping at the first match. The order earns its keep when communication goes bad — BadQuality overrides Running.

Raw signals are not operator-ready states

One field device hands SCADA more signals than you would guess: run feedback, stop feedback, fault, remote mode, local mode, permissive OK, command active, communication quality, analog speed. Making an operator combine those in their head during an upset is a display design failure, not an operator failure.

A derived status tag collapses them into one state. The label matters less than the definition. The HMI, alarm logic, historian, and reports have to use the same one. That is what the consistent state representation in ISA-101.01 actually costs you — not a screen convention, but a single place where state is computed.

Decide the priority order, then write it down

Equipment states are not equal. A fault outranks a normal stopped state. Bad communication quality outranks a clean running indication unless an independent safety system proves otherwise.

For a motor, the nine steps in the diagram above read like this:

1. BadQuality when required signals are stale or invalid.
2. Unavailable when the device is out of service or bypassed by an approved maintenance state.
3. Faulted when trip or drive fault is active.
4. Local when the device is not under remote control.
5. Starting when a start command is active and run feedback has not arrived yet.
6. Stopping when a stop command is active and run feedback is still present.
7. Running when run feedback is true.
8. Stopped when stopped feedback is true or run feedback is false by validated design.
9. Unknown when the signals do not match any valid pattern.

Put the order in the tag documentation. If it lives only inside a script, the next engineer cannot tell whether a strange display is a bug or a decision. That question eats more hours than the logic ever did.

Keep raw, normalized, and derived tags separate

A useful tag model has layers.

Layer	Example	Purpose
Raw input	P101_DI_RunFb, P101_DI_Fault	Direct value from PLC, I/O, or protocol driver
Normalized input	P101_RunFb, P101_Faulted, P101_Remote	Clean names and common polarity across equipment
Derived status	P101_Status, P101_StatusCode	Operator-facing state used by displays and reports
Diagnostic detail	P101_StatusReason, P101_LastTransitionTime	Explanation for troubleshooting

The separation stops signal inversion, protocol quality, and business logic from collapsing into one display expression. A faceplate should show the status; it should not be the only place the status exists.

Quality belongs in the raw layer especially. OPC UA carries a StatusCode alongside every value and distinguishes Good, Uncertain, and Bad. Dissolve that distinction into the derived status and you cannot get it back.

Use both text and numeric codes

Text is easier for engineers to read. Numeric codes are easier for historians, dashboards, and MES interfaces to store consistently. Use both.

Status code	Status text	Notes
0	Unknown	No valid state or conflicting inputs
10	Stopped	Normal stopped state
20	Starting	Commanded start, waiting for feedback
30	Running	Run feedback proved
40	Stopping	Commanded stop, waiting for feedback to clear
50	Faulted	Trip, drive fault, or package fault active
60	Local	Not available for remote command
70	BadQuality	Required signals are stale or communication is bad

The gaps of ten are there because states get added later — Unavailable is the usual first one. Keep the table stable after that. Repointing 50 from Faulted to Maintenance means old and new reports read the same number two different ways.

Handle impossible combinations explicitly

Field signals disagree. A valve shows both open and closed. A motor shows stopped feedback while current sits at running level. A drive reports running while PLC communication quality is bad.

Do not let impossible combinations fall through into a normal state. Give them diagnostic states or reason codes:

• OpenAndClosedFeedback for a valve with both limits made.
• NoEndPosition for a valve that is neither open nor closed after travel time.
• RunFeedbackWithoutCommand when a device starts from local control or a retained command.
• CommandedButNoFeedback when the start or open request timed out.
• FeedbackStale when the last update is older than the allowed age.

Maintenance gets far more out of those than out of one generic "bad status" alarm.

Match the delay to the physics

Derived status logic needs small delays. Contacts bounce. A VFD takes seconds to assert running. A pneumatic valve passes through neither-open-nor-closed while travelling.

Set the values per topic:

• Contact debounce for noisy discrete inputs.
• Start feedback timeout based on motor, drive, or skid response time.
• Valve travel timeout based on actuator size and air supply behaviour.
• Communication stale timeout based on scan period and protocol retry time.
• Report state hold time only when reports need stable buckets.

The pattern I keep finding is one global five-second delay applied to everything. A DOL contactor proves run feedback inside a second; a VFD on a long ramp takes considerably longer. No single number serves both — fast equipment feels sluggish and slow equipment alarms too early.

Field checks before alarms and reports depend on it

Before derived status becomes the source for alarms or OEE reporting, test it against real equipment transitions.

• Start, stop, fault, reset, local mode, and communication loss produce distinct outcomes.
• The HMI faceplate, overview graphic, alarm message, and historian trend show the same status.
• State transitions are timestamped from the controller or SCADA consistently.
• Bad quality does not land in stopped production unless that is an intentional reporting rule.
• Maintenance bypass or out-of-service status is visible and auditable.
• The derived tag survives a SCADA restart without a false transition.

The best test is a short transition log during commissioning. Capture raw inputs, derived status, command bits, and alarm events in one time window. If the timeline makes sense to an operator and a controls engineer sitting together, the model is close to usable.

Common mistakes

Calculating status only in the HMI graphic. Trends, alarms, mobile views, and reports then each run their own logic. Put the derived tag in the PLC, the SCADA tag engine, or another shared calculation layer.

Treating bad quality as stopped. It hides communication failures and corrupts downtime data. Show bad quality separately unless the process standard says otherwise.

Ignoring local mode. A device can be healthy and still not remotely controllable. Operators need the difference between Stopped and Local.

Letting reports redefine the state. If OEE or MES needs different buckets, map from the shared status code instead of rebuilding from raw bits.

Using colour without text. A grey motor could be stopped, disabled, local, bad quality, or not installed. The derived status needs a readable label and a diagnostic reason.

One thing to check next: open the status expression you are running today and trace by hand what it returns when the link drops. If the answer is Stopped, that screen's downtime report is already wrong.