Beyond Gateway diagnostics: the case for application intelligence in Ignition

Ignition already has the raw signals

The Ignition Gateway Diagnostics area provides metrics, logs, execution status and system performance. The 8.3 Metrics Dashboard includes Perspective metrics such as bindings, components, expressions, fetches, scripts, property changes and per-session queue activity. Perspective session details also expose message rates, bytes, queue state, task duration, pages, view counts and binding counts.

For multi-Gateway environments, the Enterprise Administration Module adds centralized health reporting, version management, backups, upgrades and other administrative tasks. Any new observability product should therefore complement these capabilities rather than duplicate them.

The missing question is often “what changed?”

A diagnostic value becomes much more useful when it is compared with the application’s normal behavior and correlated with a deployment, a screen change, a database slowdown or a remote-provider issue. A plant engineer should not have to manually compare ten diagnostic screens to determine why a Perspective page became slow after Tuesday’s release.

Application intelligence adds time, topology and release context: what was normal, what changed, who was affected and which dependency changed at the same moment.

• Baseline P50/P95 behavior by page or project
• Correlate deployment/version changes with performance
• Detect growth in queue length, reconnects or script duration
• Rank likely contributing dependencies instead of listing every metric

Measure the operator experience, not just the server

A Gateway can appear healthy while one operator workflow feels slow. Perspective already exposes useful session and page information. A higher-level layer can aggregate this by site, line, device type, project and workflow to show which screens create the most waiting time or reconnects.

The purpose is not employee surveillance. The useful unit is application behavior: page/view performance, error state, navigation path around an incident and the infrastructure dependency involved. Privacy and retention controls should be designed in from the first version.

Build an incident timeline

When a production issue occurs, the most valuable screen is often a timeline that aligns application events with operational events. A single investigation view can place Gateway warnings, Perspective errors, tag-quality changes, database latency, alarm events, work-order context and visual evidence on the same clock.

An AI explanation can then summarize that evidence, but the evidence must remain inspectable. The explanation is the final layer, not the monitoring architecture itself.

• Application event
• Gateway/runtime event
• OT data-quality event
• Alarm or production event
• Deployment/configuration change
• Optional VisionX/Fabrix evidence

Respect EAM and the administrative boundary

EAM already manages fleet-wide Gateway administration, synchronization, backups and recovery. Application intelligence should not compete for those responsibilities. Instead it can consume approved health/version context and focus on performance baselines, experience, correlation, semantic drift and root-cause assistance.

That boundary creates a clearer partner story: EAM remains the administrative control plane; the new layer explains application behavior and operational impact.