How to Connect PLCs to Cloud and IT Systems Using OPC Router

Connecting PLCs to cloud platforms and IT systems requires middleware that speaks both OT and IT protocols in the same breath. OPC Router does this by pulling tag data from OPC UA or OPC DA servers — TOP Server is the common source — and pushing it to REST APIs, MQTT brokers, SQL databases, or cloud services like Azure IoT Hub and AWS IoT Core through pre-built connector modules, no custom code required. Once an OPC server is already exposing PLC data, wiring a single PLC-to-cloud path in OPC Router typically takes under an hour. The rest of this guide walks through that setup step by step for 2026 deployments.

Most plant floors already have PLC data sitting in an OPC UA or OPC DA server, but getting that data into a cloud dashboard, a SQL historian, or an ERP system is a separate problem — one that usually turns into a custom scripting project if you let it. This guide covers the middleware approach instead: install a connector platform once, map your tags, and let it handle the protocol translation and scheduling. The steps below reflect how OPC Router is actually configured in production environments, not a theoretical workflow.

What You’ll Need

An OPC UA or OPC DA server already exposing PLC data (TOP Server or an equivalent OPC server)
OPC Router installed on a Windows host with network access to both the PLC/OT network and the target IT or cloud endpoint
Credentials or API keys for the destination system — MQTT broker, REST endpoint, SQL database, or cloud IoT hub
A tag list or point mapping pulled from the PLC program
Admin rights to open outbound firewall ports if the path crosses a DMZ

Step 1: Confirm PLC Data Is Already Exposed via OPC UA or OPC DA

This step verifies the foundation before any cloud work starts. OPC Router does not talk to a PLC’s native protocol directly — it consumes OPC UA or OPC DA tags, so an OPC server has to sit between the controller and the middleware layer. Open TOP Server (or whichever OPC server manages the PLC driver) and confirm the relevant tags show good quality with live values, not stale timestamps. If tags are missing or showing bad quality, fix that at the OPC server level first — chasing it downstream in OPC Router wastes time. Expected outcome: a short list of validated OPC UA or DA tags ready to reference in the next step.

Step 2: Install OPC Router and Add the OPC UA Client Connection

Install OPC Router on a Windows machine that can reach both the OPC server and the destination network segment — this is often a dedicated edge PC or a VM in a DMZ. Inside OPC Router’s configuration console, add a new connection and select the OPC UA client type, then point it at the endpoint URL of your OPC server (or OPC DA if that’s what’s available). Browse the address space, select the validated tags from Step 1, and confirm live values populate in the connection preview. A common mistake here is pointing the client at the wrong OPC UA endpoint port — double-check that the security policy and port match what the OPC server publishes, not a default guess.

Step 3: Build the Connection Linking PLC Tags to a Destination Connector

This is where OPC Router earns its place in the stack, because it’s the step that actually bridges OT and IT rather than just reading tags. In the flow editor, drag the OPC UA source items onto one side and a destination connector — MQTT, REST, SQL, or a cloud module for Azure IoT Hub or AWS IoT Core — onto the other, then draw the mapping between them tag by tag. OPC Router ships with connector modules for each of these targets, so the destination side doesn’t require writing an API client from scratch; you’re configuring endpoint URLs, topics, or table/column mappings inside the module’s settings panel. For a SQL destination, map each PLC tag to a column and decide whether writes are inserts or upserts. For an MQTT or cloud destination, set the topic structure or device twin path and pick a payload format — JSON is the default most integrators use for compatibility with downstream dashboards. Add a trigger condition if you only want writes on value change rather than continuous polling, which cuts unnecessary network and cloud ingestion load. Test the mapping with a single tag before scaling to the full list — this isolates configuration errors early instead of debugging twenty tags at once. Expected outcome: a live connection where a value change on the PLC side shows up on the destination side within the polling or trigger interval you configured. This is also the step where OPC Router’s licensing model matters — connections and connector modules scale with the license, so check current licensing details on the Software Toolbox site before building out dozens of parallel connections.

Step 4: Add Transformation Logic If Needed

Raw PLC values often need scaling, unit conversion, or renaming before they’re usable in an IT system. OPC Router’s flow editor includes script and formula blocks that sit between the source and destination nodes, so a raw integer from a PLC register can be converted to engineering units or a human-readable tag name before it hits the database or cloud endpoint. Skip this step if the destination system can handle raw values, but for anything feeding a dashboard or report, do the conversion here rather than downstream — it keeps the transformation logic in one place. Expected outcome: destination values that match engineering units, not raw register output.

Step 5: Test the Data Flow End to End

Run the connection manually and watch values arrive at the destination in real time — a cloud IoT hub’s device explorer, a SQL table query, or an MQTT client subscribed to the topic. Change a value on the PLC (or simulate it in the OPC server) and confirm the update propagates within the expected interval. A common mistake at this stage is testing only with static values, which hides timing and data-type mismatches that only show up under live changes.

Step 6: Schedule or Trigger the Connection for Production

Set the connection to run continuously, on a polling interval, or on a value-change trigger depending on how time-sensitive the data is. Production connections tied to safety or quality data typically run on shorter intervals or triggers rather than long polling cycles. Save the configuration and set OPC Router’s service to start automatically with Windows so the connection survives a server reboot without manual intervention.

Step 7: Monitor Logs and Set Up Alerting

OPC Router logs connection status, errors, and data flow activity — check this log during the first week of production to catch intermittent network drops or authentication expirations before they become a pattern. Set up an alert (email or a monitoring tool tied to the log file) for connection failures so a dropped link to the cloud endpoint doesn’t go unnoticed for days.

Troubleshooting and Common Mistakes

Connection times out crossing a DMZ. Confirm the firewall allows outbound traffic on the OPC UA port (commonly 4840) and that the destination cloud endpoint’s port is open in both directions if it requires a handshake.

Tags show good quality but values never update. Check the polling or subscription interval on the OPC UA client connection — a rate set too slow will look like a stalled connection even though quality is fine.

Cloud connector authentication fails intermittently. API keys or tokens for services like Azure IoT Hub often expire or rotate; confirm the credential stored in OPC Router matches the current active key.

Data type mismatches when writing to SQL. Add a transformation step to cast PLC integers or floats to the exact column type the database expects before the write.

High CPU usage on the OPC Router host. Reduce the polling rate on high-tag-count connections or split the workload across more than one connection rather than one massive tag list.

Tools and Resources Used

OPC Router — the middleware layer covered in this guide; connects OPC UA/DA sources to MQTT, REST, SQL, and cloud connector modules for Azure IoT Hub, AWS IoT Core, and similar platforms. Licensing scales by connector module, so check current pricing on the Software Toolbox site.
TOP Server — the OPC server most commonly paired with OPC Router to expose PLC data as OPC UA or OPC DA tags.
A cloud IoT platform (Azure IoT Hub or AWS IoT Core) — the typical destination when the goal is centralized cloud visibility rather than an on-premise database.

FAQ

What is OPC Router used for?
OPC Router is middleware that connects PLC data exposed through OPC UA or OPC DA servers to IT and cloud systems — databases, MQTT brokers, REST APIs, and cloud IoT platforms — through pre-built connector modules instead of custom scripts.

Can OPC Router connect PLCs to Azure IoT Hub or AWS IoT Core without a separate OPC server?
No — OPC Router consumes OPC UA or OPC DA tags, so a PLC’s data has to already be exposed by an OPC server like TOP Server before OPC Router can route it to a cloud platform.

Does OPC Router only work with OPC UA, or does it also support OPC DA?
OPC Router supports both OPC UA and the older OPC DA standard as client connections, which matters for plants running legacy PLC drivers that haven’t migrated to UA yet.

How is using OPC Router different from writing a custom PLC-to-cloud integration?
A custom script has to handle protocol translation, retries, and authentication manually; OPC Router’s connector modules and flow editor handle those mechanics through configuration, which is why connecting PLCs to cloud and IT systems with OPC Router usually takes hours instead of weeks of development.

What happens if the network connection between the PLC and the IT system drops?
OPC Router logs the failure and, depending on the connection settings, retries on the configured interval — this is why setting up log monitoring and alerting in Step 7 matters for production deployments.

Can OPC Router write data back down to the PLC, not just send data up to the cloud?
Yes — connections in OPC Router can run in either direction, so a value from a database or cloud system can be written back to an OPC UA tag and down to the PLC, not just read out.

Conclusion

Connecting PLCs to cloud and IT systems doesn’t require a custom integration project once an OPC server is already exposing the data — OPC Router handles the protocol translation, connector configuration, and scheduling through its flow editor, and a single connection path can be live within an hour of installation. Start with Step 1: confirm the OPC UA or OPC DA tags are already validated in your OPC server, then build outward from there in OPC Router rather than trying to script the connection from scratch in 2026.