PLC data reaches enterprise applications through a controlled collection boundary. The term here means a SCADA system, historian, OPC server, industrial PC, or controller bridge that reads plant protocols and publishes a normalized data set upstream. In production, this boundary is preferable to cloud software opening sessions directly to every controller.
Data-path mechanism
A PLC normally owns deterministic control data, while an IoT platform consumes contextualized time-series or event data. Those roles impose different connection patterns. Controller protocols expose addresses, tags, or registers; an aggregation layer converts them into named points with values, timestamps, and communication quality. An upstream connector can then publish those points through MQTT, an OPC interface, or a database path.
Common production paths include device → SCADA/historian → enterprise system and device → OPC server → MQTT broker → cloud. Another observed path used ibaPDA to read production-line PLCs, its OPC UA server to expose the data, KEPServer to consume it, and then a cloud data warehouse or third-party application to receive it. Multiple layers are justified only when each performs a defined function such as acquisition, buffering, namespace normalization, or northbound delivery.
Direct PLC-to-cloud communication is appropriate only when the controller provides the required protocol and security functions, the added communications load is acceptable, and lifecycle ownership is clear. It does not remove the need to define data quality, timestamps, buffering, and recovery behavior.
Check 1: Existing collection boundary
Start at the local SCADA or historian rather than at the cloud endpoint. Read one known process value at the controller and compare it with the corresponding collected point.
| Reading | Meaning | Next check |
|---|---|---|
| Matching value, current timestamp, and good communication quality | The existing system already provides a usable plant-side boundary. | Proceed to Check 3 and select its northbound export. |
| Point exists but is stale or has bad quality | The acquisition path is faulty; adding an IoT connector would only forward unreliable data. | Repair the driver, network path, address mapping, or controller access first. |
| No point exists | The required signal has not been acquired. | Proceed to Check 2 and identify a readable controller protocol. |
A centralized SCADA or historian can synchronize data from local systems without creating another controller connection. This reduces duplicate polling and preserves the established tag definitions. Confirm that the exported point retains communication quality and source timing; a numeric value without either can hide a failed connection behind the last valid sample.
Check 2: Controller protocol capability
Read the controller model documentation and its configured communications interfaces. The deciding reading is whether a supported client can retrieve the required data through a protocol already enabled on the installed controller.
| Observed capability | Decision | Next check |
|---|---|---|
Native OPC UA or MQTT with the required data exposed |
A separate protocol converter may be unnecessary. Keep the PLC focused on publishing only the approved data set. | Proceed to Check 3 and evaluate the upstream endpoint. |
Readable PLC protocol or Modbus, but no suitable northbound protocol |
Use a multiprotocol OPC server or industrial gateway as the translation boundary. | Proceed to Check 3 using the gateway output. |
| No compatible client for the installed interface | Add a protocol converter, OPC server with the correct driver, or controller bridge. | Validate the new southbound connection before configuring cloud delivery. |
Legacy hardware changes the interface choice, not the architecture. In one S7 installation, anS7-1500 was installed as a bridge because the S7-300 could not provide the required OPC UA communication. Treat that bridge as an explicit mapping boundary: document each source item, its destination tag, data type, update condition, and failure indication.
Check 3: Northbound delivery route
Inspect the destination interface and decide which plant-side component will own delivery. The expected reading is a documented endpoint accepted by both the collector and the consuming application.
| Route | Use when | Main engineering check |
|---|---|---|
| SCADA or historian export | The required points are already collected and the enterprise system accepts the export format. | Verify timestamp, quality, and recovery after an interrupted connection. |
Multiprotocol OPC server to MQTT
|
Several PLC or Modbus protocols must feed a broker or IoT collector. | Verify topic mapping, data types, publication behavior, and reconnect handling. |
| OPC server to cloud warehouse or third-party application | The consumer has a compatible connector and needs normalized points. | Verify namespace stability and that communication quality is not discarded. |
| Controller bridge | The source controller cannot expose a protocol accepted by the collection layer. | Verify mapping freshness and define what the bridge publishes when its source is unavailable. |
Kepware and Matrikon are examples of multiprotocol OPC servers used to read PLCs and Modbus devices before exporting data to MQTT or another consumer. A path such as device → Ignition → MQTT broker → cloud applies the same boundary principle: the plant platform acquires and contextualizes data, while the broker decouples producers from consumers.
Check 4: Data fitness and controller load
Before expanding the point list, compare every requested item with an operational use case. Record its source address or tag, engineering unit, data type, quality behavior, timestamp owner, update condition, and destination name. Reject points that lack an owner or defined consumer; indiscriminate collection increases traffic and produces an unstable namespace.
Watch controller communications diagnostics while enabling the collector. A healthy reading shows successful requests, current values, stable quality, and no growing error count. A rising timeout or retry count points to an unsupported request pattern, excessive grouping, a network fault, or too much communications work. Divide large acquisitions into logical groups and retest after each addition rather than activating the whole namespace at once.
For event-sensitive data, determine whether polling can observe the transition. A value that changes and returns between polls can be missed. Resolve that case in the controller or plant-side collection layer with a latched event, counter, or event record; changing the cloud dashboard cannot recover a transition that was never acquired.
Resolving architecture procedure
- Select the existing SCADA or historian as the source when it already holds current, good-quality data. Otherwise select one OPC server, industrial gateway, or documented controller bridge as the plant-side collection boundary.
- Configure the southbound driver for the installed PLC or Modbus interface. Start with one known point whose live state can be changed or independently observed.
- Map the approved point list. Preserve data types, engineering meaning, source timing, and communication quality. For a bridge, add a visible indication of source-link failure.
- Configure one northbound path accepted by the destination, such as
MQTT, OPC access, or a warehouse connector. Keep controller-facing sessions inside the plant collection layer. - Start the collector with the small test set, compare its readings with the controller or local HMI, and then add point groups while watching communication diagnostics.
- Document ownership of the PLC driver, gateway configuration, broker or destination mapping, certificates or credentials, tag namespace, and recovery test.
Verification readings
- Check 1: Source value. Expect the collector value and data type to match the known PLC or Modbus source.
- Check 2: Quality and freshness. Expect good communication quality and a timestamp that advances according to the configured update behavior.
- Check 3: End-to-end mapping. Change or observe a test point and expect the correct destination item to update without cross-mapping, scaling, or type conversion errors.
- Check 4: Failure indication. Interrupt the source link in a controlled test and expect bad or stale status upstream rather than an indefinitely credible last value.
- Check 5: Recovery. Restore the link and expect automatic reconnection, current data, correct quality, and no duplicate or permanently missing mapping.
- Check 6: Full-load operation. Activate the approved point groups and expect stable controller communications, current destination values, and no rising timeout or retry count.
FAQ
How do I connect a legacy PLC to an IoT platform?
Use a SCADA driver, multiprotocol OPC server, industrial gateway, or controller bridge that reads the legacy protocol. Publish the normalized values northbound through MQTT, OPC access, or the destination's supported connector.
How do I choose between SCADA export and an OPC server?
Use the SCADA or historian when it already contains current points with valid timestamps and communication quality. Add an OPC server when the required devices are not collected or when protocol translation is the missing function.
How do I get S7-300 data into OPC UA?
Use a compatible external server or a documented controller bridge. One production approach mapped S7-300 data through an S7-1500 because the older controller could not provide the required OPC UA communication.
How do I publish PLC data to MQTT?
Read the PLC with a compatible SCADA platform, OPC server, or gateway, then configure that boundary to publish the approved point set to the MQTT broker. Verify topic mapping, data types, quality handling, and reconnection.
How do I verify a PLC-to-cloud connection?
Compare one known source value end to end, confirm current timestamps and good quality, test source-link loss, and restore the link. The final reading must show current data with correct quality and no rising controller timeout or retry count under the approved point load.