Modeling at the Edge with Data Combinations

The ability to organize OT data into models at the edge unlocks a whole host of operational benefits by bringing intelligence closer to the data source. Organized and contextualized data empowers businesses to make rapid decisions, optimize processes, and increase efficiency and output. Data modelling can also enable the standardization of data in your organization for use in other applications such as the Unified Namespace (UNS) which my colleague Kudzai Manditereza discusses in detail in Data Modeling for The Unified Namespace: Best Practices.

What is a Data Model?

In terms of IoT Data Operations, we can define a Data Model as being a structured collection of data that’s been contextualized and organized using a schema to group together values from multiple data sources; i.e., industrial sensor tags and stored operational data.

In this guide we use an industrial boiler to demonstrate data modeling with HiveMQ Edge. Here is a diagram that shows the multiple data sources associated with a single asset (in this case a boiler). 

We have multiple boilers and need to model them all, using a pre-defined schema that designates the required attributes and data types of the data model.

Then we represent a single boiler asset (in this case boiler001) using an instance of the model which is populated with the relevant data sources.

The rest of this guide will show you how we took our pre-defined JSON boiler model and mapped it using HiveMQ Edge’s new front end Data Combination mapping tool.

Model Making

Before we map our instance, we need to define the base JSON model to generate a schema from. It’s good practice to version models and store them in a repository where changes can be tracked.

Continuing with our boiler example, we’ve created the following JSON schema file to map our instance from.

We’ve ensured that all fields are required to reduce the risk of human error and data loss in the mapping process. This will enforce the user to populate the entire instance and not leave any values out.

Creating and Mapping a Model Instance

Now that we have a model defined, we need to access the HiveMQ Edge interface via a browser to begin our mapping process. Remember you need to be running HiveMQ Edge 2025.4 and above with a commercial license to do this.

Checking Sources

Here, we have a HiveMQ Edge deployment running with three protocol adapters collecting data. An OPC-UA, File Protocol, and HTTP connection are live collecting data from our boiler OT sources as described in our diagram from earlier.

Our OPC-UA connection is currently collecting multiple sensor tag information from our boiler, not all of which we will need to map later.

Our HTTP and File sources have had their data modified by Data Hub to ensure they are clean and processed as desired ready for use in our model. In our example here, we’ve pre-mapped the topic filters from the Data Hub re-directed topics which can be viewed via clicking on the Edge Broker node in the Workspace view.

Here you can see we have two topic filters pre-mapped.

When we manage Topic Filters, we can infer or upload a schema to ensure HiveMQ Edge can read the data correctly. In this case we inferred, which scans the MQTT payload and  produced the above schema.

Once assigned, the UI will provide a sample of the data. We repeated the same process for our ‘../servicedate topic.

Creating a Data Combiner

Coming back to the Workspace, we can now start our model mapping using the Data Combiner feature. We select our OPC-UA adapter as shown and then select “Create a new data combiner from selection”. We don’t select the other sources because we’re using Topic Filters.

An “<unnamed combiner>” is created in the Workspace ready for further configuration. Click “Open the overview panel” to do this.

The overview panel comes out on the right side of the screen with some tabbed menu options. Let’s just focus on “Sources” for a moment. Here you can see that by default Topic Filters are included as source data for combinations. This is why we only needed to create the combiner from a single adapter node in the Workspace. 

Creating an Instance

Now let’s go to “Mappings”, select the “ + ” button to create a mapping, then select the pencil icon to begin mapping our model instance.

The interface opens up the mapping engine with “Sources” configuration on the left and “Destination” configuration on the right. Click your cursor into the sources field and our available Tags and Topic Filters appear for selection, to use in our mapping.

With all my data points that are required now selected, I can see the schema for each point. Where HiveMQ Edge is able to sample the schema, I have a representation of the data available. 

N.B. If your schema isn’t available, then you cannot map the data. This is because our UI needs to validate the data as being matched to the intended destination. We recommend in this case you publish the data point to MQTT first, and generate a Topic Filter using the method described previously in this blog.

I now must select a “Primary Key” that will be used to determine when a combined payload is published to MQTT. What you’re selecting is the trigger source for the data to be published.

We’re going to select our Topic Filter for “a12/l3/boiler001/servicedate” to use as our trigger.

Now we need to focus on the “Destination” side of the mapping engine, starting with our “Destination topic” which we’ve appropriately used a ‘site/area/line/asset’ combination for.

Now it’s time to create our instance and select “Upload a new schema” under "Destination schema”. In our case, we’re selecting the ‘boilerModel.json’ file we pre-defined earlier.

This will populate the right side with your model instance and generate destination fields from the pre-defined schema.

Now we start mapping our model instance by dragging the source properties that match our destination properties. The green icons next to property names tell you the data type which must also match the destination field. For example, you can’t drag a ‘string’ value into a field expecting a ‘number’.

Once all the model instance property fields have been matched with the correct data types, we can click “Save”.

Now we need to give our model instance a name, and as per our example at the beginning, we’re sticking with ‘boiler001’. We click “Submit” at the bottom right of the overview pane to save our data combination.

Once successfully committed to HiveMQ Edge, a green combiner update notification will appear.

Now let’s see the resulting payload. This HiveMQ Edge deployment is publishing to a HiveMQ Cloud cluster via a ‘MQTT Bridge’ connection.

When we log into our HiveMQ Cloud cluster, we can see the modeled and contextualized payload coming through, which can now be subscribed to by other resources that need this data in a standardized format.

Stay Tuned for Additional Functionality

Over the coming months, we will add more functionality to help users infer schemas for combinations as well other features that enable users to easily model and standardize data using HiveMQ Edge.