Difference Between Namespace and Model

What is in this article

What a Model is
What a Namespace is
How to choose
Best Practices

What is a Model

A model describes and validates the payload you want to send. A namespace organizes where that payload lives in a larger hierarchy. So it is that model that describes what that data is. A namespace describes where the data belongs. In a Best-Practice sense, to keep your data clean and able to be scalable. The model should handle the payload structure and let the namespace handle the organization of it all.

When to use a Model:

A model defines the structure of a deliverable payload. Normally, the payload represents one asset or one logical object, such as a pump, motor, production line, or process unit. Then, the model defines the attributes that asset reports, along with any other context that the consuming data may need to understand the data.

Here are a few things to keep in mind

Define the model around a use case:

A model should answer a specific question or support a specific consumer. It should not just contain every value that happens to be available in your data set. It should match the format needed to satisfy your use case.

A model can combine data from multiple sources

It is normal for one model to pull data from OPC UA, SQL, REST, or any other connection and format it so it follows one standard. Combining connections is feasible, but combining unrelated purposes without a distinct reason into the same payload structure can become messy and hard to manage.

Include useful context, not just raw values

A model should include useful context information that is needed to better help understand the payload, not just the tag values. However, if you were to have a larger location hierarchy, such as Plant A, Plant B, Plant C, then that would fit better with a namespace, not directly inside a model unless the System reading the data needs it in the payload.

Think about how often the data is going to be published

Different types of data may update at different times. For example, analytical data, alarms, and order data may all describe the same asset, but they will not always publish at the same time. When a data point updates at a different rate, it usually belongs in separate models.

If a model starts describing several unrelated things at once, that is normally a sign that your model may be too broad. You might need multiple models placed in sub-topics. The model should stay focused on the use case that it is addressing.

What a Namespace is for

A namespace is used to organize sources of data into a logical hierarchy. It does not define is inside the payload. Instead, it arranges payloads so users and systems can find them.

A common pattern is to use an ISA-95 organizational hierarchy which includes site, area, line, and the asset. Line and asset can take on different names depending on the type of industry (discrete, batch, continuous, warehouse management). The hierarchy can then be populated with modeled data like motors, machines, or each pump.

Each node in the namespace can point to an input. instance, or a callable pipeline. A simple way to think about it is that the namespace is the folder structure, and the model instances are the files placed inside those folders.

This becomes extremely useful when reading data back because once the namespace is built, the Smart Queries can pull data from the hierarchy in logical groups or all at once. For example, you could query all your motors in one namespace and publish those values to MQTT using the hierarchy as the topic path. A clean Namespace makes those queries simple, but a messy hierarchy will make it even more difficult to build, maintain, and understand your topic structure.

Where to draw the line

A simple way to decide whether something belongs in a model or in the namespace is to ask whether you are defining the payload or organizing where the payload belongs. If you are defining the structure and contents of a single asset's message that would belong in a model, but if you are determining where the message sits in a hierarchy, or how it relates to other assets, then that belongs in the namespace.

Different assets are being combined into one payload because they are physically loaded

The namespace is responsible for organizing related assets together. In the model, it should focus on defining the payload structure for the asset itself. If the model is trying to do too many jobs at once, then the publishing pattern or use case may be too broad. In that case, it is usually better to split the data into separate models and organize them together in the namespace.

Best Practices:

Keep each model focused on one deliverable payload, as it usually has one asset or one object. Then, design the models around the consumer and the use case, not every raw tag or field available in the source system.

Try to be mindful that you are including enough context in the payload so downstream systems can understand and relate the data correctly. Separate data into different models when it is published at different times, whether that is alarms, analytics, production orders, or even telemetry.

Use the namespace for hierarchy, organization, and addressing. Do not use it to define the payload structure. Try reusing the same model across similar assets by creating instances, instead of creating a separate model for every asset.

The most important takeaway is to design the namespace hierarchy around how consumers naturally search for and navigate data, such as site, area, line, and asset. This will allow you to keep Smart Queries easier to manage and scale over time.