I watched an Ignition 8.3 presentation at the ProveIt! Conference in Dallas, and it was one of the cleaner “this is how you scale IIoT” demos I have seen in a while.
Not because it had flashy dashboards. Not because someone asked an AI assistant about OEE on stage.
It was good because it showed the boring stuff that actually makes deployments repeatable. How you model data once, publish it in a structured way, and then roll it out to more sites without rebuilding everything from scratch.
A lot of conference demos are basically “look, we made a dashboard.” This one felt different. It was more like, “Here is how you build something you can actually deploy to 10, 20, or 50 sites without losing your mind.”
Not perfect. Not magical. Just clean. Practical. Repeatable.
The Architecture. Edge, Site, Enterprise
The architecture was straightforward. Edge gateways in each area. A site layer that aggregates. An enterprise layer that sees across sites.
In the demo, multiple areas per site were running Ignition Edge. Then a site-level Ignition server. Then an enterprise Ignition layer pulling it all together.
That sounds normal until you remember what real plants are like.
Networks drop. VLANs are misconfigured. Firewalls change without warning. Somebody reboots a switch because “it was acting weird.”
If your architecture cannot survive that reality, it is not an architecture. It is a slide.
What I liked was the emphasis on edge resilience. Store-and-forward. Buffering. Backfilling with correct timestamps. Local HMI continues even if the WAN link is down. That is not a nice-to-have. That is table stakes.
Also, this layered model matches how organizations actually work. Plants do not want to lose local autonomy. Corporate does not want 25 completely different designs. This pattern respects both.
The Real Star. Sparkplug, UDTs, and Self-Discovery
Here is where it actually got interesting.
They leaned hard into MQTT with Sparkplug B, combined with object-based modeling using UDTs.
Templates are defined once. Instances are created at the edge. Those templates and instances are published in a structured way. Downstream systems can discover them automatically, instead of requiring custom configuration every time a new line comes online.
So instead of “Site 4 is a new project.” it becomes “Site 4 is another instance of the same model.”
That self-discovery point is huge.
Most multi-site programs fail slowly because every site becomes a snowflake. One site uses different tag names. Another uses different units. A third has a different idea of what “Line 1” means. Then the central team writes custom glue logic forever.
My honest opinion. Most Unified Namespace efforts fail because people publish raw values with pretty topic names and call it done. If you do not standardize the model and enforce it, your UNS becomes a junk drawer very fast.
If the data model is not disciplined, stop talking about AI and digital twins. Fix naming, structure, and context first. Otherwise you are just scaling confusion.
Event Streams. From SCADA to Event Router
They also introduced an Event Streams capability. It was framed as routing industrial events to multiple destinations. MQTT. Cloud Pub/Sub. Direct inserts into cloud services. Data platforms like Snowflake or Databricks.
This is the moment where Ignition stops being “just SCADA” and starts acting like an industrial event router.
Instead of hardcoding one integration per system, you define events once and route them to multiple consumers. That is how you decouple producers from consumers. That is how you avoid writing custom pipelines every time a new analytics team shows up.
Again. Not flashy. But foundational.
DevOps, GitOps, and Sub-Three-Minute Commissioning
The most impressive section was not AI. It was DevOps.
They showed Git-based configuration. Pull request. Merge. Release. Promotion across environments. Automated deployment using Kubernetes and GitOps-style patterns. Gateways updated automatically.
They even demonstrated commissioning a new “site” in under three minutes using templates and automation.
Even if the demo conditions are best case, the pattern is the point.
Because most real factories still deploy like this:
- Export a gateway backup.
- Copy it somewhere.
- Rename a few things.
- Restore it at 2 AM.
- Hope nothing breaks.
That approach dies the moment you try to scale beyond a handful of gateways. It definitely dies at 50 sites.
Config-as-code changes the game. When infrastructure and gateway configuration are versioned, peer-reviewed, and promoted in a controlled way, you stop guessing what changed. You stop relying on tribal knowledge.
That is the difference between a demo and a platform.
MCP and AI. Only as Good as Your Model
They also showed an MCP module exposing tags, alarms, history, and metadata so AI tools can query plant context directly.
It is cool. It is powerful.
It is also dangerous if people think AI can fix bad modeling.
If your naming is inconsistent and your context is sloppy, AI will confidently give you nonsense. It will sound smart. It will be wrong.
If your model is clean, disciplined, and consistent, AI becomes a force multiplier. You can explore losses, bottlenecks, anomalies, and trends faster. You can ask better questions. You can reduce the friction between operations and analytics.
AI does not replace data modeling. It amplifies it. Good or bad.
Final Thoughts
If I boil the whole demo down, the real value was not the flashy elements. It was the fundamentals:
- Edge resilience with buffering and backfill
- Object-oriented modeling using UDTs
- Structured publish-subscribe with MQTT and Sparkplug B
- A real Unified Namespace hierarchy across sites
- Config-as-code with automated DevOps and GitOps deployment
Everything else builds on top of that.
Without those, you do not have a scalable industrial platform. You have a nicer-looking SCADA system with more integrations glued on the side.
With those, you have a foundation that can actually scale across plants, regions, and business units without turning into an integration nightmare.
That is what industrial platforms are supposed to look like.
Clean. Structured. Disciplined.
And boring in exactly the right ways.
This post reflects my personal opinions from sessions I attended at the ProveIt! Conference 2026.
I am not affiliated with the companies mentioned, and this content is not sponsored. Company names and trademarks belong to their respective owners.
Company referenced: inductiveautomation.com
Leave a Comment