The operating problem
The technical act of reading a tag is usually straightforward. The difficult part is deciding what that value means over time and how it should become a durable business record. A production manager asks when the machine stopped, why it stopped and how long the loss lasted. The control system may expose several bits, transient states, counters and acknowledgements that do not map cleanly to that question.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 11 Jul 2026 · Last reviewed 11 Jul 2026Start with the business event, not the tag list
A tag list describes available technical signals. It does not define the operational record the business needs. Begin by naming the events that must be reconstructed later: running, stopped, starved, blocked, faulted, changeover, waiting for operator or disconnected. Then identify which signals support each event and where ambiguity remains.
- Define the event vocabulary with production and engineering together.
- Record the source evidence used to infer each state.
- Do not force ambiguous technical states into confident business categories.
Transitions matter more than snapshots
A dashboard that polls the current state can show what is happening now but still fail to explain history. Reliable event records are created around transitions: when the state changed, what the previous state was, how long it remained stable and whether the transition was confirmed. Short signal chatter must not create dozens of false stoppages.
- Use debouncing or stability windows appropriate to the process.
- Persist both the transition time and the time the system observed it when useful.
- Make duplicate and out-of-order event handling explicit.
Machine evidence and operator explanation are different facts
The machine can provide evidence that it stopped. The operator may provide the reason, production context or corrective action. Those facts should be linked but not collapsed into one editable value. If an operator changes the reason, the machine event should remain intact and the reason history should remain auditable.
- Keep technical state and human classification separate.
- Allow unresolved reasons to remain visible rather than inventing defaults.
- Record who confirmed or changed an explanation and when.
Wanted versus actual state prevents false closure
Industrial workflows often require a business system to request a state and wait for the PLC or SCADA layer to confirm it. Writing a requested value does not mean the equipment accepted or reached that state. A wanted-versus-actual pattern makes the handshake visible and prevents the software from closing a stoppage or job prematurely.
- Record the request, acknowledgement and final confirmed state separately.
- Define timeout and retry behaviour without flooding the control system.
- Keep safety-critical control decisions inside the responsible automation layer.
Communication failure is an operational event
When the bridge loses connection, silence cannot be interpreted as running, stopped or zero production. The system must record that data quality is unknown for a period and expose the gap to support staff and report users. Otherwise missing data quietly becomes believable performance information.
- Persist connection state and last-good-read timestamps.
- Flag reports that include uncertain or incomplete intervals.
- Give support staff a practical recovery and reconciliation path.
Only calculate OEE after the event history is trusted
OEE is a derived measure. If event boundaries, production counts, planned time and reason classification are weak, the percentage will merely formalise the uncertainty. Establish the event ledger first, validate it against real shifts and only then implement the agreed availability, performance and quality calculations.
- Reconcile the event history with operator and production records.
- Version calculation rules when definitions change.
- Expose drill-down from a KPI to the events that produced it.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
Only current status is required for a local display.
Historical event architecture may be unnecessary.
Use a simple monitored view, but state clearly that it is not an audit history.
Management needs downtime duration and reasons.
Transitions and operator context must be persisted.
Design an event ledger before building dashboards.
The business system must request a machine-side state.
A handshake and ownership boundary are required.
Implement wanted/actual confirmation with timeouts, retries and logs.
Signal quality or connectivity is unreliable.
Data completeness is itself part of the domain.
Record uncertain intervals and prevent silent substitution of missing values.
Evidence that the current approach is becoming risky.
- A running bit is treated as a complete production model.
- Every tag change is inserted without debounce or transition logic.
- Operators can overwrite machine evidence when selecting a reason.
- Connection loss is represented as zero, stopped or unchanged without qualification.
- OEE is calculated before production, planned-time and event definitions are agreed.
What to clarify before commissioning work.
- Define the business states and events required by operations.
- Map each state to source tags, counters and contextual data.
- Agree transition, debounce and timestamp rules.
- Separate machine evidence from operator reason capture.
- Define communication-failure, retry and reconciliation behaviour.
- Validate several real shifts before trusting derived KPIs.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
Can SQL read directly from the PLC?
The technical route varies, but a business database should normally receive data through a controlled bridge or integration layer that handles interpretation, connection state, retries and logging.
Should operators be allowed to correct stoppage reasons?
Yes, where the process requires it, but corrections should be auditable and should not erase the underlying machine event.
Is polling always worse than subscriptions?
No. The correct method depends on the source, event rate, infrastructure and failure model. Reliability comes from explicit behaviour and diagnostics rather than the API style alone.
When is the data ready for OEE?
When event boundaries, planned time, production counts, quality data and exception handling have been validated against real operating periods and are understood by the responsible teams.