How to Achieve Real‑Time PLC Data Collection: End‑to‑End Device Integration and Platform Delivery

1. Define Data Boundaries Before Connecting Devices

Many projects start by pulling every PLC point, but control variables are not all needed for long‑term analytics. A production device can expose hundreds of variables (temperature, pressure, internal states). Collecting all at high frequency creates three problems: data explosion, meaningless values, and wasted resources. The first step is to create a device‑point list that records device ID, point ID, business meaning, unit, data type, line, and collection interval.

Example variable names such as DB21.DBD12, M100.2, AI_03 are useful to engineers but carry no business semantics. After ingestion, each point must be mapped to a clear description (e.g., "Device001 – spindle speed – rpm").

2. Handle Heterogeneous Industrial Environments

Factories often contain PLCs from Siemens, Mitsubishi, Omron, Schneider, etc., using protocols like OPC UA, Modbus TCP, or proprietary drivers. Directly connecting each upstream system to every PLC leads to multiple redundant connections, increased maintenance cost, and security risk.

The recommended architecture adds an industrial gateway or edge collection layer that performs three duties:

Protocol adaptation – converts PLC‑specific protocols to standard MQTT/HTTP interfaces.

Point standardization – maps device‑specific names to unified identifiers (e.g., "Motor01_Speed" → "Device001—主轴转速—rpm").

Edge caching – buffers data during network outages, then re‑transmits with de‑duplication.

After the gateway, the platform receives a uniform data stream, isolating protocol changes to the edge layer.

3. Design Real‑Time Data Transmission

Three time concepts must be distinguished:

Sampling period – how often the PLC is read.

Reporting period – how often data is sent to the platform.

Event time – the actual timestamp when the condition occurred on the device.

For high‑frequency variables (e.g., temperature) a threshold can be set (e.g., upload only when change > 0.1 °C). Critical events such as alarms, start/stop, or quality switches should use event‑triggered uploads. The practical rule is periodic sampling + change‑based reporting + event triggers .

Accurate timestamps are essential; otherwise a 10‑minute network outage could make a past shutdown appear as a current event.

4. Platform Storage Pitfalls

Creating a single real‑time table (device_id, point, time, value) leads to problems after months: renamed devices, changed units, re‑allocated lines, or PLC program updates break the schema. A three‑layer storage model is recommended:

Raw data layer – stores original device ID, point, raw value, event time, receive time, and quality flag for traceability.

Standard data layer – unifies identifiers, units, and fields across devices (e.g., mapping POWER, PWR_VAL, KW01 to "Device power (kW)").

Business metric layer – derives OEE, uptime, downtime, production rate, energy per unit, etc., from the standardized data.

Each layer must handle duplicate, out‑of‑order, and missing data by defining unique keys, de‑duplication rules, and replay strategies.

5. From Data Display to Event Computation

Many projects stop at a real‑time dashboard showing status, temperature, or production count. The next maturity step is to convert raw signals into business events. For example, a RUN flag changing from 1 to 0 can be turned into a "stop event" with duration, linked to production plans to assess impact. Similarly, cumulative production differences yield minute‑level output, which can be compared to target cadence to detect slow‑downs.

Combining power data with output produces unit‑energy metrics; correlating alarms with work orders yields fault frequency and mean‑time‑to‑repair statistics.

These transformations follow the pipeline: PLC signal → standardized data → real‑time metric → anomaly event → business action . Real‑time tasks (e.g., FineDataLink 5.0) perform field standardization, filtering, conversion, and enrichment before writing to downstream stores or dashboards.

Conclusion

Real‑time PLC data collection is not merely a connectivity problem; it spans industrial automation, network communication, real‑time computation, data governance, and business analytics. Success depends on selecting valuable data, unifying ingestion, ensuring continuity during network failures, standardizing formats, and ultimately turning device signals into actionable business insights.