3. Industrial data sources and acquisition

An industrial KPI dashboard is only as trustworthy as the data pipeline feeding it. Before any calculation of OEE, scrap rate, or energy per unit, engineers must answer a deceptively simple question: where does each number actually come from, and how does it travel from a physical sensor to a dashboard tile? In a real plant, that journey crosses several layers — control, supervision, historization, operations management, and enterprise planning — each with its own protocols, sampling behavior, and failure modes.

The Automation Pyramid and What Each Layer Contributes

Industrial data sources are conventionally organized as a hierarchy. At the base, PLCs (Programmable Logic Controllers) execute deterministic control logic and hold the most authoritative real-time values: motor run bits, cycle counters, temperatures, valve positions. Above them, SCADA (Supervisory Control and Data Acquisition) systems aggregate PLC tags into operator screens, alarms, and setpoint writes. Historians (e.g., OSIsoft PI, Ignition Historian, Wonderware InSQL) archive time-series values with timestamps and quality flags, enabling trend analysis and KPI backfill. MES (Manufacturing Execution Systems) adds work orders, material genealogy, and shift context. ERP contributes order quantities, costs, and delivery schedules. Finally, IoT sensors — vibration pucks, power meters, environmental monitors — increasingly bypass the control layer entirely, publishing directly over MQTT.

The critical insight for dashboard engineers is that these layers disagree. A PLC counter may increment at 10 ms resolution, the SCADA poll may sample it every second, the historian may compress it, and the MES may only record it at shift boundaries. Reconciling these differences is the core of acquisition engineering.

Protocols: How Data Physically Moves

Three protocols dominate shop-floor acquisition, and each imposes different constraints on your pipeline.

OPC UA is the modern, platform-independent standard. It provides a structured address space, built-in data types, subscriptions with configurable publishing intervals, and security via certificates. A typical subscription request looks like this:

MonitoredItem:
  NodeId: ns=2;s=Line1.Filler.CycleCount
  SamplingInterval: 250 ms
  QueueSize: 10
  Deadband: 0
  PublishingInterval: 500 ms

Here the server samples the tag every 250 ms, buffers up to 10 values, and publishes to the client every 500 ms. If the client disconnects, the queue prevents data loss up to its depth. Choosing these values poorly — for example, a 5-second publishing interval on a fast cycle counter — silently loses counts.

Modbus (TCP or RTU) remains ubiquitous on legacy equipment. It is register-based and stateless: you read holding registers or input registers by address. Modbus has no native timestamps, no quality flags, and no subscriptions — the client polls. A common pitfall is register mapping drift: a vendor changes firmware and address 40001 now means something else. Always document the register map and validate against a known physical state.

MQTT is a lightweight publish/subscribe protocol ideal for IoT sensors and edge gateways. A sensor publishes to a topic such as plant1/line2/vibration/motor3 with a JSON payload. MQTT excels at many low-bandwidth devices but provides no built-in schema enforcement, so payload contracts must be defined and validated at the broker or edge.

Data Quality Challenges in Real Plants

Raw acquisition rarely yields dashboard-ready data. Four quality problems appear repeatedly:

• Stale and frozen values. A PLC loses communication, but the SCADA cache keeps returning the last known value. Without a freshness check, the dashboard shows a plausible but wrong number. Mitigation: compare the source timestamp against wall-clock time and mark values older than a threshold (e.g., 3× the expected update interval) as UNCERTAIN.
• Timestamp misalignment. PLC clocks drift, historians apply their own timestamps, and MES records events at shift granularity. When you join a cycle count to a work order, a 30-second clock skew can assign production to the wrong shift. Mitigation: use a single time authority (NTP or PTP) and record both source and ingestion timestamps.
• Counter rollover and reset. A 16-bit counter wraps at 65,535. A naive delta calculation produces a massive negative spike. Mitigation: detect rollover by checking if the new value is less than the previous value and the difference exceeds a plausible threshold, then add the modulus.
• Unit and scaling inconsistencies. One flow meter reports in L/min, another in m³/h. A temperature sensor uses tenths of a degree as an integer. Without a normalization layer, aggregations silently mix units.

A Practical Acquisition Checklist

When onboarding a new data source for KPI use, work through the following verification steps. This checklist is designed to be copied and filled per tag or per source.

From Acquisition to KPI: A Worked Example

Consider a filling line where you need to compute units per minute. The PLC holds a 16-bit cycle counter at ns=2;s=Line1.Filler.CycleCount, sampled every 250 ms via OPC UA. The edge gateway normalizes the value, checks for rollover, and publishes a delta to the historian every second. The dashboard queries the historian for the last 60 seconds of deltas and sums them.

If the counter reads 65,530 and then 12, the gateway detects a rollover (12 < 65,530 and the drop exceeds 1,000), computes the true delta as (65,535 − 65,530) + 12 = 17, and publishes 17. Without this logic, the dashboard would show a negative production rate and trigger a false alarm. The observable verification is straightforward: compare the dashboard's 60-second sum against a manual count of physical units over the same window; they should match within one cycle.

Understanding these sources and their quirks is not preliminary work to be rushed through — it is the foundation on which every KPI calculation rests. The next step is to define how these acquired values are modeled into the KPI definitions themselves.