Production data evaluation: from SCADA tags to better plant decisions

Define the decision before collecting more tags

Begin with the operating question, the person who must answer it and the action that follows. Data collection without a decision model usually produces storage, not transparency.

A useful question is specific and time-bounded: Which condition caused this line to stop first? Which permissive delays startup most often? Is a recurring drive trip related to load, temperature, communication quality or an upstream process condition? The question determines the signals, event resolution, history and context that are actually required.

For every proposed metric or dashboard, write the owner, decision frequency, required confidence and response. Separate monitoring from control. A report may recommend maintenance, but it should not acquire authority to change a live process merely because the same data is available. This boundary becomes especially important when analytics or AI is introduced.

• Decision and responsible role
• Affected asset and operating mode
• Required time resolution and history
• Action triggered by the result
• Acceptance criterion for a useful answer

Build a trustworthy production-data foundation

A value in a database is not automatically a reliable representation of the process. The team must know where it came from, what it means and whether it remained valid during the event being investigated.

Create a compact data dictionary for the signals that support the chosen use case. Record the source PLC or device, engineering unit, scaling, update method, timestamp source, quality indication, expected range, retention period and system owner. Identify whether each value is measured, commanded, calculated, manually entered or inferred. Similar tag names across machines do not prove that the underlying definitions are comparable.

Time synchronization deserves its own test. A controller transition, drive fault, HMI alarm and historian sample can appear in the wrong order when clocks, buffering or collection intervals differ. Verify how the source timestamps are generated and preserved. During communication loss, distinguish a stale last-known value from a confirmed healthy state rather than allowing a plausible number to hide missing data.

Turn alarms into diagnostic evidence

Alarm analysis is most valuable when it reconstructs the sequence of conditions around a loss, not when it simply counts every message in the system.

Start by confirming alarm definitions, priorities, deadbands, delays, acknowledgement rules and first-out behaviour. Repeated alarms may reflect a genuine unstable process, a poorly tuned threshold, a device that is cycling, or one initiating fault that produces many downstream symptoms. Frequency alone cannot distinguish these causes.

Preserve the relationship between the alarm and process values before, during and after the event. Useful measures can include occurrence count, active duration, acknowledgement time and recurrence by operating mode. Review nuisance and standing alarms separately from rare high-consequence conditions. Any proposed suppression or delay should be tested against the risk of hiding an actionable event.

Create plant-level visibility without erasing context

A common plant view can reduce the effort needed to compare lines and systems, but normalization must preserve the differences that affect interpretation.

Map each data source to an asset hierarchy and retain the originating system, equipment state and data quality. Define common states such as running, ready, blocked, starved, faulted and planned stop, then document how each machine maps its native signals to those states. Do not force unlike processes into one definition merely to make a dashboard symmetrical.

When consolidating alarms and trends from distributed systems, verify chronological order, naming, units, access control and the ability to trace a displayed result back to its source. A central archive should make investigation faster while keeping enough source context for the controls or maintenance team to validate the conclusion.

Use KPIs as entry points to investigation

KPIs such as overall equipment effectiveness, mean time between failures and mean time to repair can reveal a pattern, but the number is only useful when its definition and exclusions are controlled.

Document the denominator, planned-production period, ideal cycle, good-count source, downtime categories and treatment of changeovers, blocked or starved states. Apply the same definition consistently before comparing lines. If one area records micro-stops and another does not, a ranked dashboard may reward weaker data rather than stronger performance.

Every summary metric should support drill-down to the events, machine states and process values that produced it. Review a baseline period and test known scenarios before relying on the KPI for operational targets. A successful implementation allows a user to move from a change in the metric to a credible hypothesis and then to the evidence needed to confirm or reject it.

Add AI-guided operations only after governance

Natural-language access can reduce search effort, but it does not remove the need for source validation, access control and human authority over the process.

Begin with read-only tasks such as locating relevant trends, assembling an alarm timeline, preparing a shift summary or identifying the documents associated with an asset. Limit the accessible systems and data to the approved use case. Responses should show the source, time range, data quality and assumptions so a qualified person can verify them.

Define what the assistant is prohibited from doing, how incorrect recommendations are reported and who approves any resulting field or software action. Keep live commands, setpoint changes, forces, bypasses and downloads outside an advisory workflow unless a separately engineered and authorized control architecture proves they are safe. AI should shorten the path to evidence, not create an unreviewed path around operational responsibility.

Make the shift record part of the data model

Automated signals explain what the system recorded; a structured shift entry can preserve the operating context, observation and action that the tags do not contain.

Use defined categories, asset references, timestamps, priority, status and ownership. Link an entry to supporting alarms or trends without replacing the original records. Preserve editing history and role-based access, then define how an open item becomes a maintenance action, engineering investigation or completed handover note.

Review recurring entries alongside alarm and downtime analysis. Repeated manual comments can expose an unmodeled equipment condition, a missing alarm, an unclear operating instruction or a workaround that has become normal practice. Closing that loop converts shift knowledge into a controlled improvement rather than leaving it in free-text notes.

Deliver a phased, testable production-data project

Prove one bounded decision path before expanding the architecture. A pilot should test data trust, user workflow and measurable usefulness—not only connectivity.

Start with an installed-system survey and a source-to-decision map. Configure the smallest required collection and analysis path, then replay known events or execute an approved test. Confirm timestamps, loss-of-communication behaviour, access roles, calculation definitions, report results and the user's ability to trace conclusions back to source evidence.

Close the phase with an as-left architecture, data dictionary, KPI or alarm definitions, access and backup responsibilities, test evidence, open issues and a named owner for ongoing quality. Expansion to another line or use case should reuse the verified delivery pattern while rechecking the process-specific definitions. This approach makes transparency an engineering outcome rather than a dashboard promise.

• Installed-system and interface survey
• Source-to-decision data map
• Controlled definitions and ownership
• Normal, degraded and known-event tests
• As-left documentation and support responsibility