N3uron to Canary Historian over MQTT Sparkplug B: primary host and store and forward

Where PLCs sit at remote sites or on networks that the Historian cannot reach directly, MQTT gives another way into the Canary Historian. N3uron at the edge reads the Allen-Bradley controllers and publishes their tags as Sparkplug B messages to a broker, and Canary's MQTT collector subscribes and logs them. This article follows that path using N3uron's and Canary's documentation, with the settings on each side that decide whether data survives a network outage. The other ways to log Allen-Bradley tags are covered in Logging Allen-Bradley PLC data to Canary.

Reading the PLC with N3uron

N3uron's EtherNet/IP Client module covers ControlLogix-class controllers including CompactLogix, as well as PLC-5, SLC 500, MicroLogix and Micro800. Its browser lists the tags in the controller, and they are dragged into the N3uron data model or picked when a tag is configured. The PLC program does not change for this; what changes is the read load, set by the scan rates in N3uron.

Publishing with the Sparkplug Client

N3uron's Sparkplug Client module publishes N3uron tags in Sparkplug B topic and payload format, version 2 or version 3; version 3 needs N3uron 1.21.4 or later. Each node has a Group ID and an Edge Node ID, and the pair must be unique on the broker. Values are sent only when they change, and N3uron's documentation lists several brokers in a cluster, so the client moves to the next broker when one is unavailable. Connections can use plain MQTT on port 1883 or MQTTS on port 8883, with a password, a client certificate or both.

Receiving with Canary's MQTT collector

Canary's MQTT collector is configured in the Canary Admin client and accepts Sparkplug B 3.0, Sparkplug B 2.2 or JSON payloads; Canary states that Sparkplug B 3.0 is supported from version 23. Tags are organised in connection groups, and each group is a logging session that writes to a DataSet. Subscriptions start with spBv1.0/ and, according to Canary's configuration article, should be made at the node level so that the collector has the node context it needs for templates. A tag limit per DataSet can be set, and the collector then opens a new DataSet with a number added to the name.

Canary's article also warns that removing the leading part of tag names can create duplicate names, and it recommends enabling device birth requests in almost every case. One connection group can send the same data to more than one Historian by listing them.

When the link drops: primary host and store and forward

This is where the two sides have to be set together. In Canary's collector, the Primary Application option makes publishers that can buffer hold their data while the collector is disconnected; Canary's overview article explains that the collector then announces itself on a STATE topic under its MQTT Client ID. In N3uron, the Primary Host ID names that application, and with status checking enabled N3uron pauses publishing while the primary host is offline and looks for a broker where it is online.

N3uron's store and forward keeps timestamped records while the node or the primary application is disconnected, and publishes them as historical records when the link returns; the retention is set in days. Canary's article adds that "Store No Data On Disconnect" should be left off when the collector is primary and the publishers buffer. Reading the two documents together, the ID entered in N3uron should be the Client ID set on Canary's collector; we would test this on a broker before the plant relies on it.

Canary's documentation also notes a side effect: while the collector is the primary application and offline, other clients subscribed to the same topics receive no data either.

What to agree before configuring

• The PLC tags to publish, with engineering units and the scan rates in N3uron.
• Group ID and Edge Node ID names, and the tag path that becomes the topic structure.
• Which broker or brokers, which ports, and how clients authenticate.
• Whether Canary's collector is the primary application, and the store and forward retention in N3uron.
• The DataSet names and tag limit per DataSet on the Canary side.

How TDL approaches it

TDL Industrial Automation is an N3uron Certified Integrator and a Canary Certified Partner, listed on Canary's partner page for Vietnam. Most plants we work in run Allen-Bradley controllers, so we start from the PLC tag list and the network: where N3uron can run next to the PLCs, where the broker sits, and which firewall openings the outbound MQTT connection needs. More on historian services: Canary Historian in Vietnam.