Solace with Ignition and HighByte: Integration Patterns for the Plant Layer

Solace with Ignition and with HighByte is the most common question a plant team asks once Solace is on the table, because Ignition is how many plants see their data and HighByte is how many plants model it. Both Inductive Automation and HighByte appear in Solace’s technology partner directory as of October 2026. This page sets out four integration patterns using only what the three vendors document publicly, says where each fits, and lists what to test. Joltek has no commercial relationship with Solace, Inductive Automation or HighByte.

It belongs to Solace in manufacturing in the Solace cluster.

What the partnership listings say, and do not say

HighByte. Solace’s partner directory describes the pairing in one line: “HighByte and Solace give manufacturers an event-driven foundation for modern digital operations.”

Inductive Automation. The directory lists Inductive Automation and Ignition with Inductive Automation’s own company description.

What we did not find: a jointly published reference architecture, a certified Solace module for Ignition, or a dedicated Solace connection in HighByte’s public product material. So the patterns below rely on standard MQTT, which all three products support, rather than on a special integration. That is not a weakness in itself; it just means the testing is yours.

How Ignition moves data over MQTT

Inductive Automation’s IIoT architecture documentation describes three roles, delivered through Cirrus Link’s MQTT modules:

1. Publishing at the edge. Ignition Edge, or a gateway with the MQTT Transmission module, reads PLCs through Ignition’s drivers and publishes to an MQTT broker as a Sparkplug edge node. Our post on connecting Allen-Bradley PLCs to Ignition covers the driver side.
2. The broker. In Inductive Automation’s words, “an Ignition Gateway with the MQTT Distributor Module installed, or a third-party server, such as a Chariot MQTT Server”.
3. Consuming. An Ignition Gateway with MQTT Engine subscribes and makes the data available for screens, history and reporting. It acts as the Sparkplug host.

Store-and-forward is built in. When MQTT Transmission is configured with a Primary Host ID, Cirrus Link documents that it stores data locally while the host’s STATE is offline and publishes it when the host returns. That behaviour depends on the retained STATE message, which is why the broker’s retained-message support matters (see Solace Sparkplug).

How HighByte moves data

HighByte’s Intelligence Hub page describes a modelling layer rather than a broker:

• Models and instances to turn raw tags into consistent asset definitions (“model hundreds of common assets in minutes with templatized inputs and instances”).
• Pipelines that move raw or modelled data “on an interval, event, or callable basis”.
• MQTT output with “both JSON and Sparkplug payloads”, and an embedded MQTT 3.1.1 and 5 broker.
• Store-and-forward “to buffer data to disk if target connection is lost”.
• An Industrial MCP Server so AI agents can query connected systems.

Four Solace Ignition and HighByte patterns

Pattern	What runs where	When it fits	What to test
A. Ignition at the plant, Solace above	Transmission and Engine on an Eclipse-listed plant broker; selected data forwarded to Solace	Ignition-heavy plants that want to keep their tested Sparkplug stack	How data is forwarded (a bridge, a module or scripts), and which side owns the forwarder
B. Solace as Ignition’s broker	Transmission and Engine connect to a Solace software broker at the site, which is also a mesh node	One broker product everywhere; IT runs the plant broker	Retained STATE, Will messages on failover, store-and-forward flush, QoS settings
C. HighByte to Solace	Intelligence Hub models the data and publishes JSON over MQTT to a Solace node	Modelled, ISA-95-shaped data for enterprise consumers	Topic mapping, payload schema ownership, store-and-forward sizing
D. HighByte broker as plant UNS	HighByte’s embedded broker serves the site; Solace links sites	Sites standardised on HighByte with modest broker needs	Broker sizing and HA at the site, forwarding to Solace

Our starting point for most plants is A plus C. Ignition keeps Sparkplug where it is tested, HighByte shapes the enterprise view, and Solace carries that view between sites and into IT systems. Pattern B makes sense when a central team wants one broker technology at every site and accepts the testing that comes with it. The unified namespace page covers how the modelled tree should look.

A scenario (illustrative). A packaging plant runs Ignition on four lines with MQTT Transmission at each line and the MQTT Distributor on the SCADA server. Corporate wants OEE and quality holds from this plant and three others in one data platform. Pattern A leaves the lines untouched. HighByte, already licensed for a data-lake project, publishes a modelled line/state and line/event tree to a Solace node in the plant’s DMZ, and the data platform reads from its own queue. If the WAN drops, HighByte buffers to disk and the Solace queue holds what has already arrived.

Questions to put to each vendor

Because no joint reference design is published, the clearest way to de-risk any of these patterns is to ask each vendor the same short list and compare the answers.

To Solace:

• Are MQTT retained messages supported in production on our broker version and edition, given their Controlled Availability status?
• How should a Sparkplug host detect a lost edge node after an HA failover, when no Will message is sent?
• Which customers run Ignition or HighByte against a Solace broker, and can we speak to one?

To Inductive Automation and Cirrus Link:

• Is a third-party broker that is not on the Eclipse Sparkplug list a supported configuration for MQTT Transmission and MQTT Engine?
• How is store-and-forward flushed after a long outage, and at what rate?

To HighByte:

• Which MQTT settings (QoS, retain, session expiry) do you recommend toward an enterprise broker, and how large can the store-and-forward buffer grow?
• Who owns the modelled schema once enterprise systems depend on it?

JMS has also been discussed as a route between Ignition and Solace on the Ignition forum; treat that as a community idea to evaluate, not a supported product path.

Where it gets hard

• No joint reference design. Each vendor supports its own product. Agree in writing who owns the forwarder, the topic map and the incident when data stops.
• Sparkplug on Solace is self-tested. Pattern B inherits every caveat on the Sparkplug page, including Will messages not being sent on broker failover.
• Two store-and-forward layers. MQTT Transmission and HighByte both buffer. Size both, and decide which one is authoritative after an outage so data is not replayed twice.
• Payload ownership. Sparkplug Protobuf on one side, HighByte JSON on the other. Someone must own the schema that enterprise consumers depend on; a catalogue such as Event Portal helps.
• Licensing on three sides. Ignition modules, HighByte and Solace are licensed separately. Price all three before choosing a pattern.

For the plant-side context, see our SCADA and historians overview. For the site-to-enterprise transport, continue to multi-site edge to cloud, or see the full partners and ecosystem page.