Brownfield PLC Tags Are the IoT Integration Surface

Brownfield PLC Tags Are the IoT Integration Surface

New industrial IoT projects often start with a clean data model: assets, metrics, units, sampling rates. Then the site tour happens. The plant already has a PLC tag list that operations has used for a decade. That list is the real API.

We have watched platforms fail because they invented new names for points the historian and the operators already know. The gateway mapped them "close enough." Alarms fired on the wrong tag. Trust disappeared in a week.

The tag list exists before your platform does

A brownfield line already publishes hundreds or thousands of points. Some are control. Some are diagnostics. Some are leftovers from a vendor visit in 2019. Operations knows which ones they look at on a shift.

The integration job is to subscribe to that list, not to replace it. We start with an export from the PLC or OPC-UA server and sit with an operator for one hour. They mark: act on, display only, ignore.

Anything marked ignore stays off the MQTT topic that feeds the new platform. Shipping unused tags looks complete and makes every dashboard slower and every alert noisier.

Map names, do not translate physics

Two approaches. Rebuild the plant in your asset model and write adapters that compute "motor_temp_c" from B3:12. Or keep B3:12 as the canonical identifier and attach metadata: unit, rate, asset, owner.

Rebuilding feels modern. It also creates a second naming system that only the vendor understands. When a technician changes a scan rate on the PLC, your computed point is now wrong and nobody searches for B3:12 in your ticket system.

We keep the PLC tag as the primary key. Metadata is a layer on top. If the platform cannot store B3:12 as an ID, the platform is not ready for that site.

Scan rates are part of the contract

A tag that updates every 50 ms is not the same object as a tag that updates every 5 s. Treating both as "temperature" in a single stream overflows the gateway and starves the slow, important points.

We group subscriptions by rate class: control (sub-second, on-prem only), operations (1–5 s, may leave the site), audit (1 min or change-of-state). Control tags do not go to the cloud MQTT broker. Operations tags do, with the PLC name intact.

The tradeoff is more topics and a less pretty data model. The gain is that a firmware or gateway change cannot silently downsample a control point.

A failure mode with "helpful" scaling

One integrator scaled a raw analog 0–32767 into engineering units in the gateway, then discarded the raw value. A PLC program change shifted the range. The platform showed a plausible, wrong temperature for eleven days.

The mitigation is to publish raw and scaled, or raw plus the scaling formula as metadata. If you must pick one, pick raw and scale at the edge of the application that needs units. Never drop the native tag value.

Commissioning is a tag review, not a go-live party

Before the hardware PO for additional sensors, we require a signed tag map: PLC name, rate class, owner, act/display/ignore. New sensors are only justified for points that do not exist on the PLC and that operations marked as needed.

That review has cancelled more sensor orders than it has approved. That is the point.

Final takeaway

Treat the existing PLC tag list as the IoT contract. Keep the names, keep the raw values, and only add devices for points the plant does not already have.