Industrial AI should complement Ignition, not replace it

Start with the installed reality

A brownfield plant rarely needs another technology program whose first step is replacement. Existing Ignition projects embody years of tag structures, alarm philosophy, screens, operator habits, security roles and integration knowledge. Rebuilding all of that to adopt a new AI capability increases risk before any business value is proven.

A complementary architecture asks a simpler question: what capability is missing, and what is the smallest governed interface needed to add it?

Use clear product boundaries

Computer vision should own image acquisition, inference, evidence and model lifecycle. MES should own work-order execution, genealogy, quality and manufacturing records. A digital twin should own model-based scenarios and declared assumptions. Ignition can continue to own SCADA/HMI and the operator interaction patterns already proven at the site.

This separation makes integration easier to support because each platform has one primary job. It also reduces the temptation to push every new function into a single monolithic project.

• Ignition - operational application and SCADA foundation
• VisionX - visual evidence and machine vision
• Fabrix - manufacturing execution and genealogy
• Cortex - digital twin and what-if context
• Sentrix / Delfi - governed cross-system reasoning and interaction

Prefer evidence in the operator workflow

When a specialized system detects something important, the operator should not always need another browser tab. A visual inspection result, quality hold, work-order status or AI explanation can be surfaced back into the existing Perspective experience while the source application retains its own audit and lifecycle responsibilities.

This pattern allows new capability to feel native to the operation without pretending that every function must physically run inside Ignition.

Do not rebuild established ecosystem plumbing

MQTT, Sparkplug, historians, EAM and other established Ignition ecosystem components already solve important infrastructure problems. A differentiated product should consume those capabilities where appropriate rather than recreate them simply to claim a larger footprint.

The higher-value opportunities are above the plumbing: evidence correlation, cross-system workflows, application intelligence, domain-specific models and governed decision support.

A better pilot contract

A good integration pilot should name the systems that remain unchanged, the exact data exchanged, the operator experience, the failure behavior when a connection is lost, and the acceptance criteria. This converts “AI with Ignition” from a broad idea into a measurable engineering exercise.

The customer can then expand by line, plant or use case without rewriting the operational foundation.

• No replacement prerequisite
• Read-only first where possible
• Explicit failure and degraded-mode behavior
• Measured acceptance criteria
• Repeatable integration contract