MQTT | A Technical Workshop

In our latest webcast we showed how FrameworX can help with your MQTT needs. You can watch the full presentation here!

Transcript:

Dave Hellyer:
So — thank you, everyone, for joining today’s Tatsoft MQTT workshop. Prior to this we introduced version 9.2 in a workshop; today we’ll focus on specific enhancements and improvements we’ve made.

This session is more technical: we’ll go through configuration tools, show how things are pulled together, and take questions. Submit questions in the chat; we’ll try to answer live or gather them and address in batch at the end. We’ll also distribute a Q&A summary afterward.

A little about us: I’m Dave Hellyer, VP of Business Development for Tatsoft. Philip (one of our senior development engineers and today’s SME) is here with me. We’ve been Tatsoft for about 13 years; our platform is mature and growing. We come from industrial DNA — decades of automation experience — and we build the platform from that real-world knowledge and customer feedback.

We originally focused on OEM private-labeling; today we also target system integrators and end users. Headquarters are in Houston, Texas; I work from the Chicagoland office in Arlington Heights; Philip is in Houston.

FrameworX is cross-platform — built on .NET — and runs on Windows or Linux. We emphasize an open platform and broad connectivity: devices, databases, online resources — we include connectivity tools out of the box. Our customers span pharmaceuticals, steel, oil & gas, water, rail, transportation, and more.

Our product lineup:

  • FrameworX — the core platform (SQL-oriented).
  • FrameworX Unlimited — the full toolset: unlimited I/O, unlimited simultaneous runtime users, unlimited concurrent developers.
  • FactoryStudio — helps right-size solutions (1500/5000 point tiers, etc.).
  • Edge HMI — scaled-back HMI for field/operator interfaces (not server/SCADA).
  • Edge Gateway — data migration tool: connectivity to real-time sources and databases, store-and-forward, scripting. Good for collecting edge data and moving it to central systems.

Version 9.2 highlights include the dynamic tag provider and improvements to MQTT tooling (an MQTT simulator, embedded broker, Sparkplug B support, Azure connectivity, store-and-forward enhancements). Philip will demo the MQTT tools and simulator.

Philip — over to you.

Philip (demo intro):
Good morning. Today I’ll present two applications:

  1. Data simulator (publisher/gateway) — simulates random SCADA values (acts like a gateway reading Modbus, ControlLogix, Siemens, OPC, etc.) and publishes to an MQTT broker. For this demo we’ll use the embedded FactoryStudio broker, but any broker is supported.
  2. Client application (consumer/HMI) — subscribes to broker topics, creates displays, visualizes, and can historize data (SQL Server, SQLite, Canary, etc.). Clients can be HTML5, iOS, Windows, etc.

You can publish from the simulator, then consume via a FrameworX client and historize the data anywhere you want.

Demo — Simulator & Data Structure

  • Start by designing the data structure (example: a blue-line structure with tanks, valves, pumps, properties such as pH, level, pressure, temperature). Create templates for assets (e.g., Tank template) and then instantiate tags from those templates (BlueLine1, BlueLine2, etc.).
  • Each property is a tag with its configuration (data type, start value, retention, domain, etc.). Devices are abstracted — could be Modbus, ControlLogix, Siemens, OPC UA — anything.

Devices → Channels → Nodes → Points

  1. Channel: choose protocol (MQTT/Sparkplug B, OPC UA, Modbus, or a simulator protocol). For the demo we use the “CT Simulator” to generate random SCADA values; another channel is MQTT/Sparkplug B for publishing.
  2. Node: uses channel config (broker URL, port, client ID, username/password, x509 certs, QoS, keepalive, etc.). For Sparkplug B, set QoS (at-least-once, exactly-once as needed).
  3. Points: mapping of each property/tag to topic/address. For a simulator this is automated; for real devices you map addresses.

Simulators

  • Two ways to simulate:
    1. Built-in CT simulator in FactoryStudio (random ranges per point).
    2. External mqttspb_simulator.exe (in install folder) — configure broker URL, node IDs, number of devices per node, then send continuous Sparkplug B payloads.
  • The embedded broker (tmeqtt broker / FactoryStudio embedded broker) can be used for testing.

You can run modules independently to conserve CPU — e.g., only run Devices for the simulator.

Demo — Client / Providers / Dynamic Tag Provider

To consume published data:

  • Use Tag Providers (provider technology) to connect to brokers/historians (MQTT/Sparkplug B, OPC UA, Canary, Rockwell, FrameworX itself). Tag providers allow browsing the structure and reading data without creating manual tags or mapping points. No channel-node-point mapping required on the consumer side.
  • Create a provider: choose protocol (Sparkplug B), configure primary station (broker URL, credentials), test connectivity, then browse objects that are being published.
  • Import provider objects into Assets: use Insert asset from provider (imports an asset subtree from the broker into FrameworX assets). Imported assets update dynamically as publisher adds/removes assets.

UI: displays & symbol workflow

  • Create a selected-asset helper tag (string/text) to hold the path of the currently selected asset. Use it to drive dynamic displays.
  • Draw an asset component on the display. Use that selected-asset tag in dynamic bindings so UI updates when selection changes.
  • Create and save Symbols: reusable UI components (e.g., pump/tank symbol). Symbols live in the symbol library and update everywhere when you edit them.
  • Bind symbol parameters (PH, temperature, pressure, selected asset) to tags/fields — dynamic binding supports re-use.

Example displays

  1. Single-symbol display — one symbol bound to the selected asset showing live values.
  2. Dashboard display — symbol + trend chart (multiple pens: pH, pressure, temperature) + data grid + gauge. Trend uses pens that map back to asset points; grid is data-driven from a tag/data source. Supports zoom, pan, themes.
  3. Dynamic multi-symbol display (code-driven) — code (≈ <50 lines) that:
    • Reads children under a selected level (via provider/broker),
    • Loops through items and constructs a dictionary of parameter names/values (temperature, pH, pressure, level, name),
    • Programmatically creates symbol instances and places them in a scrollable container, passing the dictionary as parameters.
    • Result: display auto-creates N symbols based on the number of assets published — truly self-aware.

Tip: capture screenshots or replay the presentation to review the small code snippets.

Additional MQTT features shown

  • Azure IoT Hub integration — available via an Azure extension/toolkit. Configuration involves Azure-side setup plus device/channel/node configuration in FrameworX. We have documentation and can share step-by-step guidance.
  • Store-and-forward (MQTT & Historian):
    • MQTT: if broker connection is lost, data can be stored locally (SQLite) and forwarded once connection resumes. Prevents data loss.
    • Historian: same concept — local historian buffering and forwarding when connectivity returns.

The store-and-forward database uses SQLite (preinstalled with FactoryStudio). Limits are essentially tied to disk capacity; typical store-and-forward is suitable for expected outage durations (days/weeks depending on disk).

Dave Hellyer — HiveMQ integration & closing:
We include an embedded broker and Sparkplug B client in the product free for building/testing. For enterprise-grade requirements, Tatsoft partners with HiveMQ — we can help you obtain and integrate HiveMQ broker for larger scale and advanced features.

We run training — upcoming course is March 15–17 (mornings) — email me at [email protected] for details. We may resume in-person training in Chicagoland.

Q&A highlights (selected)

  • AWS IoT: Currently Azure IoT is supported; AWS integration is under development / QA (not yet released).
  • Dynamic Tag Providers: FrameworX supports MQTT, OPC UA, Canary Labs, Rockwell, FrameworX native provider. Work in progress: OSIsoft, GE historian, and more tag providers planned.
  • Reporting tool: Built-in text-based reporting tool (included from Edge HMI upward). Layout-based, supports embedding graphics (snapshot at report time), trend charts, tabular data, scheduled PDF/email distribution.
  • Store-and-forward limits: Uses local SQLite; practical limits are disk-based. SQLite is included with FactoryStudio install — no extra license or install required.
  • Roll-your-own Provider API: Not available yet. The 2k API will add more tag provider connectivity functionalities in future.
  • Localization: Language localization supported — report strings and UI text can be localized by language settings.
  • Scripting and reports: Reports are layout-driven (no embedded report scripting language). You can use scripting (VB.NET, C#, Python) elsewhere to prepare data/tables, then present those results in reports.