Broker bridge availability and capability

Hi team,

I see that Chariot MQTT server supports bridging, but I wanted to know if:

  1. is Bridging supported between two Distributor modules?
  2. Are events stored and forwarded if connection is lost between brokers?
  3. Bi-directional control?

Typical application is when you have an enterprise broker and site broker, with both having historians that cannot miss any data. Also if the field devices producing the data supports SpB but not multiple brokers.

On your questions

  1. MQTT Distributor does not support bridging
  2. No
  3. What do you mean by bi-directional control? When bridging is enabled on Chariot, MQTT messages are passed between the servers in both directions.

Generaly for redundancy and scale we suggest multiple MQTT Servers at the same level. For passing messages between networks we would recommend something like this:

  • Ignition Gateway 1 (Edge Node): MQTT Transmission
    ** Transmission pointed to Ignition Gateway 2
  • Ignition Gateway 2 (Site Server): MQTT Distributor, MQTT Engine (connect to localhost MQTT Server), and MQTT Transmission
    ** Transmission picking up tags from local MQTT Engine and pointed to Ignition Gateway 3
  • Ignition Gateway 3 (Enterprise Server): MQTT Distributor and MQTT Engine (connect to localhost MQTT Server)

Hi Wes,

Thanks for the reply and answering my questions. Yes, with question 3 I basically meant “Can I control site/edge devices from enterprise level over the bridge?”. The answer for that being Yes then.

I understand the architecture 100% that you suggested. But given the following scenario:

  1. GW Site & GW Enterprise both go down
  2. GW Edge will start to S&F
  3. GW Site comes back online
  4. GW Edge forwards all historical data to GW Site (via site engine->site Ignition->site historian)

GW Enterprise comes back online and is now missing data. Now I assume the idea is that site GW Ignition Transmitter should S&F between Site and Enterprise, but how does site transmitter catch S&F data from site engine? Will I need to enable latching?

If you use ‘in-order’ flushing on the history store you can preserve the data with this tiered architecture. There is a corresponding setting in MQTT Engine called ‘Store Historical Events’. When flushing in-order this must be unchecked to force incoming historical events to be written to the tag (which in turn results in a tag change event). When data is flushed from the Edge in this manner, Transmission at the Site Gateway will know the Enterprise Gateway is not online and now store the data at the Site Gateway until the Enterprise Gateway comes back online.

Hi Wes

This is great info thank you, this seems like the correct way of setting it up then.

Hi Wes,

I have been playing with the setup you suggested, for the most part it has been working great. I just ran into one issue. It seems that when I shut down site ignition for a while and restart it, the historical data reached the site historian but not the enterprise historian. I logged into both brokers (site and enterprise) with an mqtt client and it seems that the historical data only reaches the site broker. I think it is because the site engine module starts up before the site transmitter module, missing the tag change events. Could that be the case?

I have restarted the site ignition a few times and results are inconsistent. Sometimes a large chunk of historical data does reach the enterprise level, sometimes nothing.

Ah right - there are some timing caveats. I’d recommend using the primary host feature and the Primary Host Control tags feature in the advanced section of the MQTT Engine General tab:

With the above config, and a tag like this:

MQTT Engine will publish a primary host state message when that tag transitions to true. You can use this to delay the startup of MQTT Engine which in turn will allow MQTT Transmission to fully start up.

You also need to make sure and set up primary host in the Transmission Server Set as well and it must match the ASCII string you use on the Engine side.