In this webinar, experts from Tatsoft and HiveMQ discussed the key components of a modern edge to cloud IIoT architecture, identified key challenges to its implementation, and demonstrated Tatsoft’s recent product release of FactoryWork and FactoryStudio, which includes support for MQTT and Sparkplug.You can learn more about this partnership and download the Edge to Cloud demo here: https://tatsoft.com/hivemq/
Transcript:
Hello everyone, and a very warm welcome to our joint webinar with Tatsoft: Designing an Edge-to-Cloud Architecture for IIoT. It’s a pleasure to have you all here.
I am super excited to introduce our speakers for today:
- Ian Scarrett, Head of Marketing at HiveMQ
- Marc Taccolini, Founder and CDO of Tatsoft
Joining Ian and Marc are Harry McCullum, Dave Helier, and Eric from Tatsoft, who will be helping with Q&A and the demo.
Before we get started, I’d like to share a couple of housekeeping notes:
- This session is being recorded and will be shared later in a follow-up email.
- If you have any questions during the session, please submit them in the Q&A panel.
- Please refrain from using the chat panel.
- We will have a dedicated 15-minute Q&A after the presentation.
- If you have any unanswered questions afterward, feel free to email us.
- We will also run a live poll during the Q&A and a survey immediately after the session. We kindly ask you to participate and share your feedback.
Without further ado, I’ll hand it over to Marc.
Marc, you can start sharing your screen.
Marc:
Thank you very much, and thank you all for being here. Let me share my screen, and let’s get started.
Today we are going to talk about designing an architecture from the Edge to the Cloud, leveraging the new technologies provided by HiveMQ. But before diving into that, I want to share a bit of background about us.
Our company is based in Keystone, Texas and Chicago, and was created based on decades of experience. From the very beginning, we have worked with both OT and IT technologies. We created a completely new platform for Industry 4.0 — built with no legacy code — leveraging modern technologies such as cross-platform deployment and PLC integration. You can develop on Windows and deploy on Linux, and the system was designed to be easy to use for OEMs and brand-label solutions.
Our core product is called FrameworX, a platform to create real-time industrial applications.
In one slide, you can think of FrameworX as solving all connectivity needs to the factory floor — with 70+ built-in industrial protocols — along with easy integration to historians and databases, advanced dashboards, graphical tools, and simple connectivity to your ERP. From that chart, you can imagine FrameworX as the enabling technology to create custom solutions for data connectivity, aggregation, visualization, and even some analytics.
For full analytics and historian capabilities, we integrate with top-tier systems such as Canary.
The way we deploy the platform is simple:
We provide a single development environment — FrameworX Studio — and from there, you can deploy:
- Low-end edge HMIs
- IoT gateways
- Local UIs at the machine or factory level
- Enterprise systems with FrameworX Unlimited, supporting hundreds of thousands of tags
We support both sides: Edge devices publishing data upstream, and Enterprise applications consuming, visualizing, and managing that data.
All the typical SCADA and IIoT requirements — graphics, alarms, events, notifications, OPC, scripting, custom interfaces — are available out of the box in one unified tool. You don’t need to cut and paste multiple independent applications together.
Before diving into the demo, I want to revisit some historical context about industrial data — because it influences how we design modern architectures.
Modern architectures need:
- Open technologies so components are interchangeable and you’re not locked to a single vendor.
- Distributed storage that avoids unnecessary duplication but allows data to live where it makes the most sense.
- A unified naming model (a unified namespace) so different applications can reference the same asset model without repeated rework.
For these reasons, MQTT / Sparkplug-style broker architectures are a great fit. The broker becomes the real-time hub for the unified namespace; above it you can add data normalization, transformation, and routing. FrameworX handles that normalization and routing so data published from the edge reaches the broker in the right shape.
Because the broker is central, we partnered with HiveMQ to provide customers with a professional, enterprise-ready MQTT broker. Starting with FrameworX 9.2, a HiveMQ instance is installed by default (out of the box) so you can immediately try up to 25 clients without a license, and scale up for larger deployments.
With that, I’ll hand over to Ian to talk more about HiveMQ and their approach.
Ian Scarrott (HiveMQ)
Thanks, Marc — and thanks to Tatsoft for the great introduction and demo.
A little about HiveMQ: we are a Germany-based company just outside Munich. We’ve been focused on HiveMQ since around 2014, and our core product is an enterprise MQTT broker.
What we help customers do is connect devices to the cloud — whether those devices are factory equipment, solar farms, or connected vehicles — and reliably move data both from devices to cloud and from cloud back to devices. Key value points for our customers are:
- Reliability / High availability — business-critical systems cannot drop data.
- Scalability — support for millions of devices and very high message throughput.
- Cost-efficient connectivity — important for cellular or satellite networks.
- Security — end-to-end certificate and auth support.
- Observability — tools to debug and troubleshoot clients and broker health.
- Integration — SDKs and extensions to integrate with enterprise and OT systems.
At the core of our platform is the clustered HiveMQ broker. The broker can run in clusters across Kubernetes, OpenShift, public clouds (AWS, Azure), or on-prem data centers. We also provide the Control Center for monitoring the broker and clients, and an Enterprise SDK for broker-side extensions (for example, forwarding to enterprise services or directly into systems like Canary).
I’ll now hand back to Marc for the demo walkthrough.
Marc Taccolini — Demo Walkthrough
Thanks, Ian. I’ll show a simple, reproducible demo that illustrates a complete Edge-to-Cloud architecture on a single machine (or VM) so you can reproduce it locally.
Demo architecture overview (software components)
We use three main pieces in this demo:
- Edge application (FrameworX Edge project)
- Reads data from PLCs/controllers (Modbus, OPC UA, etc.) and normalizes it.
- Publishes organized data to MQTT (following a unified namespace/Sparkplug-like topic model).
- MQTT broker (HiveMQ)
- Acts as the unified namespace hub, receives data from both edge projects and directly from device simulators.
- Enterprise application (FrameworX Enterprise project)
- Subscribes to broker topics, stores historical data (e.g., Canary or other historian), performs analytics, and publishes results back to the broker.
We also include a small simulator that publishes MQTT messages directly to HiveMQ so you can see combining data sources (edge + direct device publishers).
Building the Edge project
- Create asset templates (e.g., solar panel template).
- Define object model (arrays and templates let the model be very compact).
- Add device connections (Modbus, OPC UA — or any of our 70+ protocols).
- Points are routed and normalized — the Edge project maps raw device values into the asset model and applies scaling where needed.
- Publish via MQTT to the broker using the unified namespace topic structure.
This configuration can be done in ~10 lines of project setup for the simple demo we showed. If devices support templates, you can map entire templates without mapping points one-by-one.
Enterprise application and dynamic tag providers
In FrameworX Enterprise the interesting modern capability is the dynamic tag provider:
- You don’t pre-create thousands of tags in the application.
- Instead, the application dynamically browses the broker’s namespace and consumes whatever is available — no tag mapping required.
- Displays and analytics are data-model-driven: add or remove assets and the application reacts automatically.
For UI displays, the same project can publish HMTL5/JS-based pages and native UI clients. Users don’t notice where the data came from — whether simulator, Edge app, or enterprise analytics — they just see the consistent asset model.
Analytics and compute
Small analytic scripts (C# or VB.NET, or Python for advanced use) can query a set of assets and compute totals, averages, or other KPIs. These analytics can:
- Run at the enterprise app and publish results back to the broker (recommended — keep compute off the UI).
- Or run at the Edge when lower-latency or local storage is required.
Example: an analytics script iterates the children of a group (e.g., GroupIG1), sums PowerCur, Voltage, computes averages, and publishes an analytics topic back to the broker. The broker becomes the central point for sharing those analytics results.
Data storage & resilience
- Sparkplug/MQTT clients and brokers can store-and-forward.
- If connectivity is lost, clients or the broker can persist messages locally and forward when connectivity is restored.
- Often it’s sensible to write history directly from the edge to a local historian to reduce broker load, while the broker remains the master of real-time unified namespace.
Q&A Highlights (selected questions & answers)
Q: Can HiveMQ be deployed at the edge?
A: Yes — HiveMQ can be deployed at the edge or in a data center. Many customers run a broker in each factory and bridge brokers to a central data center.
Q: Does the Edge Gateway convert Modbus payloads to SparkplugB / MQTT?
A: Yes — the edge gateway reads Modbus (or other OT protocols), normalizes the data model, and publishes the payload to MQTT/Sparkplug topics for the broker.
Q: Can this architecture be used for automotive sensor monitoring or other domains?
A: Absolutely — the architecture is protocol- and domain-agnostic. If sensors are accessible via an OT protocol, the Edge project reads them and publishes to the broker.
Q: APIs and integrations?
A: FrameworX offers APIs (including .NET/Open API) to automate provisioning, remote management, and monitoring of edge devices. HiveMQ offers broker-side SDKs and extensions to integrate with enterprise systems, including CFA/Canary connectors.
Q: How is device provisioning handled at scale?
A: You can use FrameworX templates and the open .NET APIs to automate provisioning for hundreds of gateways. The data provider model resolves brokers and devices dynamically in the project.
Q: Offline behavior — how do you handle intermittent connectivity?
A: Both the client and broker support store-and-forward. Clients persist messages locally and forward when network returns; the broker can buffer and deliver messages to subscribers when they reconnect.
Q: Trials / downloads?
A: HiveMQ provides a free trial limited to 25 clients. Tatsoft provides a demo download (FrameworX) via their website — the demo includes 500 I/O points and a 30-day development license (runtime is limited to short sessions which can be restarted).
Q: UI frameworks and JavaScript libraries?
A: FrameworX supports JavaScript in HMTL5 displays; you can embed frameworks (React, etc.) inside the HTML5 view files.
Q: TLS / certificate support?
A: HiveMQ supports client certificate authentication and enterprise security extensions to streamline certificate workflows and authorization by topics.