Home / Support / Integration Hub / Ignition SCADA
Software Architecture Guide

Ignition SCADA: Mapping Modbus Fieldbus to MQTT Engine

Stop TCP bridging legacy serial ports. Leverage Edge Gateways to separate your polling cycles and stream clean, pre-parsed JSON or Sparkplug B directly into Ignition’s MQTT Engine.

1. The Problem with Legacy Serial Polling

Inductive Automation’s Ignition is arguably the most powerful modern SCADA platform. However, many system integrators still attempt to connect remote RS485 devices (like power meters or VFDs) to centralized Ignition servers using simple “Serial-to-Ethernet” transparent forwarders.

This legacy architecture means the Ignition Gateway’s native Modbus driver is forced to do synchronous polling over long distance WAN connections. It causes high latency, results in cascade TCP timeout errors when only a single packet is lost, and produces “Stale” tags that prevent system from scaling to multiple sites.

2. Edge-Decoupled Architecture (The MQTT Pattern)

The modern IIoT standard isolates the IT software from the OT physical layer. By deploying an Edge Gateway directly at the remote switchboard or pump station, the Modbus polling cycle stays strictly local.

Legacy: Ignition Native Modbus

  • Ignition actively queries the remote network constantly, burning bandwidth.
  • If the VPN or Cellular link drops for 2 seconds, tags go Stale.
  • High CPU load on the Ignition server when managing 5,000+ remote Modbus tags.

Modern: Edge Gateway to MQTT

  • The Edge Node polls devices locally at high speed (no WAN latency).
  • Report-by-Exception (RBE): Only publishes data to Ignition when values change.
  • Zero Modbus configuration inside Ignition. All data arrives as clean MQTT topics.
🔓 Ignition MQTT Engine Cheat Sheet

3. Payload Configuration: Sparkplug B vs. Custom Namespaces

To ensure Ignition’s MQTT Engine automatically parses your field data into structured tags (UDTs), your Edge Gateway must format the Modbus payload correctly before publishing.

Route A: Sparkplug B (Auto-Discovery)

If your Edge Gateway supports the Eclipse Sparkplug B specification, Ignition requires zero configuration. The gateway publishes a NBIRTH certificate, and Ignition automatically builds the folder structure and tags in the Tag Browser instantly. This is the gold standard for enterprise rollouts.

Route B: Custom JSON (Custom Namespaces)

If using a generic MQTT payload, configure your Edge Gateway to output a flattened JSON structure. In Ignition’s MQTT Engine settings, navigate to Custom Namespaces and map the topic.

Gateway JSON Output & Ignition Tag Mapping:

// Published to Topic: telemetry/plant1/chiller_meter_1 { “timestamp”: “2026-10-14T08:30:00Z”, “gateway_id”: “VT-DTU-Plant1”, “devices”: { “Chiller_Meter_1”: { “Voltage_A”: 230.5, // Ignition generates Tag: [MQTT Engine]telemetry/plant1/chiller_meter_1/devices/Chiller_Meter_1/Voltage_A “ActivePower_kW”: 45.2, // Ignition generates Tag: [MQTT Engine]telemetry/plant1/chiller_meter_1/devices/Chiller_Meter_1/ActivePower_kW “Status”: 1 } } }

Designing an Enterprise IIoT Network?

Download the official OT-to-IT network topology blueprint for secure Ignition SCADA deployments.

Download PDF Blueprint

Ready to Decouple Your Modbus Polling?

Don’t overwhelm your Ignition Gateway with hundreds of Modbus TCP queries. Use Valtoris Edge Gateways to poll your PLCs and meters locally, parsing the data into clean JSON payloads and publishing directly to your MQTT Distributor.