Plant Data and Integration

Getting trustworthy data off the floor and into systems that act on it. Tag standardisation, contextualisation, and the unglamorous work that makes analytics possible.

What lives in this layer

Plant data is the plumbing between every other layer: how a value in a PLC becomes a number someone in planning, quality or finance can rely on. We file it under ISA-95 Level 4 because that is where the data is finally consumed by business systems, but the work touches every level below it.

The building blocks are well known:

• OPC UA, the standard way to read structured data from controllers and servers, with a proper information model and security built in.
• MQTT, a lightweight publish and subscribe protocol where devices send data to a broker when it changes, instead of waiting to be asked.
• Sparkplug B, a specification on top of MQTT that defines topic structure, payload format and device state, so that two vendors’ MQTT clients can actually understand each other.
• Historians, which store time series data with timestamps and quality flags.
• A unified namespace (UNS), an architecture pattern where the current state of the plant is published to one structured, event driven hierarchy that any system can subscribe to.
• ERP and MES integration, where production counts, consumption, downtime and quality results move up and orders, recipes and specifications move down.

If MQTT is new to your team, our guide to MQTT in manufacturing covers the basics.

The problems we see most

Data nobody trusts. A dashboard shows OEE at a number the supervisors know is wrong, so they stop opening it. Usually the cause is not the dashboard. It is a counter that resets on a PLC download, a state tag that means different things on two lines, or a shift calendar that lives in a spreadsheet.

Polling that misses events. A system that asks the PLC for values every few seconds will miss a fault that comes and goes inside that window, and it will timestamp everything at the moment it asked rather than the moment it happened. We explain the mechanics in PLC scan cycles, polling and SCADA data. Report by exception and edge timestamps fix most of it.

Tag naming chaos. Every integrator who touched the plant brought their own convention. The same motor is M101_RUN on one line and Line2.Conv.Mtr.Running on another. Until names and units follow a standard, every report is a mapping exercise and every new connection starts from scratch.

Point to point spaghetti. Each new system gets its own connection to each PLC. Eventually nobody knows which interfaces are live.

The decisions this layer forces

We are vendor neutral, but not opinion neutral. These are the calls we make most often.

Standardise before you integrate. A naming standard, a state model and a list of the few dozen signals that actually matter will do more for data quality than any platform purchase. We would rather spend the first weeks there than on a broker.

A UNS helps when many systems need the same data. If you have several lines, several consumers (SCADA, MES, historian, analytics, ERP) and a plan to keep adding them, a structured namespace over MQTT removes most of the point to point links. If you have one line and one reporting need, it is overkill. A historian and a well built report will get you there faster.

Decide where context gets added. Raw tags need asset, line, product and order context to be useful. We prefer adding it as close to the source as practical, at the edge or in SCADA, rather than reconstructing it later in a data lake.

Keep data local first. The plant should not lose visibility when the internet link drops. We make the case in why local data matters in manufacturing.

How it connects to adjacent layers

Clean data starts in the controls layer with sensible tag structures, and it travels over the OT network, which must be segmented before IT systems connect to it. SCADA and historians are often the first consumers and the natural place to add context. Edge and I/O is increasingly where data is collected and published. Above it, MES and batch is usually the most demanding consumer of all.

Where Joltek helps

Most plant data work starts with an IT/OT integration engagement: mapping what exists, setting the standard and designing the architecture before anyone buys a licence. If you are not sure where the data problems sit, a plant systems assessment finds them. When the goal is a downtime or OEE number people believe, see OEE and downtime improvement. For a longer horizon, we fold the data architecture into a modernization roadmap.