The Industrial IoT Blog

A few years ago, if you told me we’d be using large language models on top of plant data, I would’ve said: “Cool demo. Not sure it survives contact with a real site.”

Now I’m more convinced. Not because LLMs magically understand manufacturing. They don’t. I’m convinced because we found a few practical, boring-looking use cases where LLMs helped real people do real work faster, as long as we put them on top of a solid Unified Namespace (UNS) and treated them like an assistant, not an oracle.

Here are the practical ways we used LLMs on top of industrial data. Sanitized. Truth-only. No fairy tales.

First, the unsaid truth. LLMs don’t fix messy data

The best “AI project” I’ve seen in a plant wasn’t an AI project. It was cleaning up naming standards, tag models, and context.

If your data is scattered across:

• a historian with inconsistent tag names
• a SCADA system where everything is “Tag_1234”
• spreadsheets people swear are “the source of truth”
• PLC tags that mean one thing at Site A and another thing at Site B

Then an LLM will just produce confident nonsense faster.

A UNS helps because it forces you to answer hard questions:

• What is this asset?
• What is this measurement?
• What is the unit?
• What is the state model?
• What is the relationship between this line, this machine, and this batch?

When we had that, the LLM became useful. When we didn’t, it was mostly a chatbot with good manners.

Use case 1: Plain-English search across tags and assets

This was the first win, and it was almost embarrassingly simple.

People don’t want to search for:

PlantA/Area3/Line2/Filler01/Status/Mode

They want to type:

“Show me the filler mode changes from yesterday”

or

“Which machine caused the most downtime on Line 2 this week?”

So what we did was combine:

• a UNS with consistent hierarchy and naming
• a searchable catalog of tags, assets, and descriptions
• an LLM that translated a user question into a structured query

Not “LLM, please answer from vibes.” More like:

1. Identify the asset(s)
2. Identify the signals (status, speed, downtime, alarms)
3. Identify the time window
4. Generate a query against the historian or time-series store
5. Return results with links, units, and timestamps

The LLM wasn’t the brain. It was the translator.

What changed operationally: controls engineers and reliability folks found data faster without remembering exact tag paths. That alone saved real time during investigations.

Hard rule we kept: the model never “estimated” values. It only returned values actually queried from the source system.

Use case 2: Faster downtime triage with narrative summaries

Downtime triage is where humans lose time. Not because they’re slow. Because the data is noisy.

A typical “micro-stop” story looks like:

• machine state flickers
• alarm list explodes
• operator notes are… creative
• timestamps don’t line up perfectly
• some events are missing

We used the LLM to generate a draft narrative like:

• what happened first
• what changed next
• what alarms appeared around that window
• when the machine returned to steady state

But we constrained it heavily:

• The LLM received a structured event timeline (from the UNS context plus alarms and states).
• The output had to cite exact timestamps and signal names from that timeline.
• If the timeline was incomplete, it had to say “unknown” instead of guessing.

Example of what this looked like in practice:

“Between 10:14:22 and 10:16:05 the machine state moved from Running to Starved. A ‘Downstream Blocked’ alarm appeared at 10:14:30. Speed dropped from 220 to 0 over 12 seconds. The system returned to Running at 10:16:05.”

That’s the kind of thing a human can write. But writing it 15 times a day gets old.

What changed operationally: quicker first-pass triage. People still did root cause analysis. We just reduced the “blank page” problem.

Use case 3: Operator and technician “what do I do now?” assistant

This one surprised me. The value wasn’t in answering deep technical questions. It was in helping people navigate documentation and procedures.

In most plants, procedures exist. The problem is:

• they’re hard to find
• they’re written in a way nobody talks
• people don’t know which procedure applies to which asset variant

Because the UNS already links:

• asset identity
• model/type
• firmware versions (sometimes)
• line context
• associated documents

We could let a technician ask:

“What’s the restart procedure for this skid after a power dip?”

or

“Where is the calibration SOP for this transmitter?”

And the assistant would respond with:

• the most relevant procedure link
• the specific section
• a short summary in plain English

Important constraint: the assistant did not invent steps. It only summarized existing approved documents. If there was no approved doc, it said so.

What changed operationally: less hunting. Less tribal knowledge dependency.

Use case 4: Data quality and naming standard enforcement

Nobody wakes up excited to enforce naming standards. But everyone suffers when they’re ignored.

We used the LLM as a reviewer.

When new tags or assets were added, the LLM checked:

• naming convention compliance
• missing descriptions
• unit mismatches (psi vs bar, C vs F)
• duplicated signals that “look the same but aren’t”

This worked well because the UNS gives structure. The LLM could say:

“This tag name doesn’t match the pattern for this asset class.”

or

“Description is empty. Add what this measures and where.”

It’s like spellcheck. For engineers.

What changed operationally: cleaner UNS over time. Fewer “mystery tags.”

Use case 5: Converting engineering speak into business speak

Here’s an unpopular opinion. Most “AI in manufacturing” fails because teams try to impress leadership with tech, instead of translating impact.

We used the LLM to help convert plant metrics into a plain summary for non-technical stakeholders:

• “Top 3 constraints this week”
• “Where we lost time”
• “What improved”
• “What we’re doing next”

But again, we forced it to base statements on actual numbers coming from the data, not generic advice.

What changed operationally: better alignment. Less time in meetings explaining basics.

What didn’t work (at least not for me)

A few things looked good in demos and didn’t hold up:

1. “Ask the LLM anything about the plant”: Too broad. Too many edge cases. Too much hallucination risk.
2. Letting the model directly recommend parameter changes: In regulated or safety-conscious environments, this is a non-starter unless it’s tightly controlled, validated, and reviewed. And even then, good luck.
3. Skipping governance: If you can’t answer “where did this data come from” and “who approved this procedure,” the whole thing becomes a liability fast.

The practical pattern that worked

The pattern that consistently worked looked like this:

1. UNS provides structure and context (assets, relationships, consistent naming)
2. LLM converts intent into a structured action (query, retrieve, summarize)
3. System returns real results (time-series, events, docs)
4. LLM summarizes with constraints (no guessing, cite timestamps, show units)
5. Human remains accountable (review, decisions, changes)

Not flashy. Very effective.

Final thought

LLMs on top of a UNS can be genuinely useful. But only if you treat the UNS as the foundation and the LLM as a helper.

If someone asks me, “Should we start with AI or with UNS?” I’ll give the boring answer every time.

Start with the UNS. Then add AI where it removes friction.

Because in manufacturing, “pretty good” isn’t good enough. Not when downtime costs money, and mistakes cost more than money.