Getting plant-floor data into web dashboards without putting the control network at risk

Why this is harder than it looks

On paper it's a data-plumbing job: values exist in PLCs and a historian, and a web page needs to show them. In practice the plant floor was designed to be isolated, the systems on it were chosen for reliability rather than for being easy to query, and the people responsible for them are rightly cautious about anything new touching production.

A common failure mode isn't a technical one. It's a dashboard project that stalls in security review because nobody decided up front where data crosses from OT to IT, which account it uses, and what happens if the dashboard misbehaves. Settle those first and the build is the straightforward part.

Know where your data actually lives

Most plants have some combination of these layers. The right source for a dashboard is usually the highest one that already holds the data at a resolution you need.

If a tag is already in the historian, read it from the historian. You inherit its buffering, its time stamps and its compression settings, and you add zero load to the controllers. Go to an OPC UA server when you need values the historian doesn't collect or a faster refresh than it stores. Polling a controller directly from anything outside the control network should be the exception, and your controls engineers should be the ones deciding it.

Four architecture options

Almost every design we'd consider is a variation on one of these. They differ mainly in where the data crosses into the business network and who owns that crossing.

1. Historian API from the DMZ. A service in the DMZ (or on the business side, through a firewall rule terminating in the DMZ) queries the historian's own interface. For PI, that's typically PI Web API, a REST interface over HTTPS; for FactoryTalk Historian, the options depend on version and licensing, so confirm them with your Rockwell contacts. This is the lowest-risk starting point for trend charts, shift reports and anything that tolerates data that's seconds to minutes old.

2. Historian replication into the DMZ. Some PI sites already replicate a subset of tags to a second PI server in the DMZ precisely so business-side consumers never touch the plant historian. If you have that, point the dashboard's API at the DMZ copy and the conversation with security gets much shorter.

3. OPC UA subscription through a gateway. For live values, an OPC UA client in the DMZ subscribes to a server such as Kepware or FactoryTalk Linx Gateway. Subscriptions report changes rather than being polled, which keeps load predictable. Use the SignAndEncrypt security mode with certificate trust managed deliberately, and a server-side user that can browse and read only the tags the dashboard needs.

4. Outbound publish from an edge gateway. An edge service inside the plant reads OPC UA or the historian and publishes selected values outward, commonly over MQTT or HTTPS, to a broker or API in the DMZ or the cloud. The connection is initiated from the inside, so no inbound path into the plant is needed. Kepware's IoT Gateway and cloud offerings such as AWS IoT SiteWise Edge follow this shape. It suits multi-site views and cloud-hosted dashboards, at the cost of one more component to operate.

Network segmentation your controls team will accept

Most manufacturing networks are organized, formally or informally, along the lines of the Purdue model: control devices at the bottom, site operations above them, the business network at the top, and an industrial DMZ between operations and business. ISA/IEC 62443 builds on the same idea of zones and the conduits between them. You don't need to be an expert in either, but your design should speak their language.

• No direct path from business to control. Traffic from the business network terminates in the DMZ. Nothing on the business side, including the dashboard's servers, opens a session to a PLC, an HMI or the plant historian.
• Few, documented conduits. Each firewall rule between zones has a named purpose, a source, a destination and a port. OPC UA's registered port is TCP 4840, but many servers default to others (Kepware's documentation lists 49320 among its default UA server ports), so check what your servers actually use rather than assuming.
• Separate credentials per zone. The account the dashboard API uses in the DMZ should not exist on the plant side, and vice versa.
• Remote access is a separate problem. Don't solve vendor or engineer remote access with the same path the dashboard uses.

Make read-only a property of the design, not a promise

"The dashboard only reads" is a statement about today's code. Security teams want it to be true even if the code changes. Enforce it at every layer you can:

Designing the dashboard layer

Once data is safely in the DMZ, the web side is familiar territory, with a few plant-specific habits worth keeping.

• Agree refresh rates per screen. A shift summary can update every few minutes; a line status board might want a few seconds. Very few web dashboards need true sub-second data, and asking for it everywhere is what drives risky direct-to-controller designs.
• Put an API and cache in the middle. Fifty browsers open on the same line view should cause one read from the gateway, not fifty. The API caches recent values and pushes changes to browsers, over WebSockets or server-sent events for live screens.
• Carry quality and time stamps through. OPC UA and historians both report whether a value is good, uncertain or bad, and when it was recorded. Show stale or bad data as stale or bad instead of as a confident number.
• Join plant data with business context. The most useful dashboards combine historian values with MES or quality data: which order was running, which shift, why the line stopped. If that context still lives on paper, a mobile app for plant-floor teams can capture it where the work happens.
• Use your existing sign-in. Authenticate against the company identity provider (Microsoft Entra ID, Okta or similar) over OIDC or SAML, and control which plants and lines each role can see.

On-premises, cloud or both

The dashboard API and front end can run on a server in the plant's business network, in your company data center, or in a cloud account such as AWS. The deciding factors are usually who will run it, whether dashboards need to work when the plant's internet link is down, and whether you want to compare several sites in one place.

A common middle ground is to keep collection and the DMZ gateway on site, publish a curated set of values outward, and host the multi-site dashboard in the cloud. Whichever you choose, define the infrastructure as code so the environment can be rebuilt and reviewed, and keep a separate test environment that reads from a test tag group or a simulator rather than production.

Questions to settle before you build

Our experience includes extensive work with Rockwell FactoryTalk, some work with OSIsoft PI, manufacturing execution systems, web and mobile HMIs, and dashboards for control systems and production data. If you'd like to see how we'd approach your plant, the manufacturing page covers what we build, and how we work explains the fixed-price process.

Sources

• Welcome to PI Web API and Introduction to the PI to PI Interface (AVEVA)
• FactoryTalk Linx Gateway (Rockwell Automation)
• IoT Gateway overview and service port assignments (PTC Kepware)
• Use AWS IoT SiteWise Edge gateways (AWS)
• OPC UA online reference (OPC Foundation)
• ISA/IEC 62443 series of standards (ISA)