Data models: The key to scaling your unified namespace

Data models: The key to scaling your unified namespace

The unified namespace (UNS) architecture makes data available for a wide range of use cases and personas within a company. However, like any approach, it has its limitations. Unaltered source system data payloads typically don’t contain the data that consuming applications need, so determining which data must be grouped together requires source equipment and systems domain expertise.

For example, let’s say you need to monitor the power consumption of similar mixer motors in a plant for predictive maintenance. First, you’ll need to collect the following telemetry data: motor state, speed, power consumption, and vibration. You will also require data from systems around the motor, like valve state and mixer tank fill percentage. Next, you’ll need data from the MES to understand the material being mixed and the recipe, as well as the BatchID from the PLC to query the MaterialID from the MES. Finally, you’ll need to connect to the CMM system, which can provide the motor assetID and link it with manufacturer, age, and serial number. Finally, you’ll need to run aggregations and calculations to get the actual required data set. In this case, the analytic does not need every datapoint change all the time; it only requires a moving average and max value calculation on the speed, vibration, and current every 10 minutes.

Rather than overloading the consuming analytic application with large volumes of extraneous data, data modeling provides a way to satisfy specific use case requirements. Industrial DataOps tools can provide the modeling capabilities needed to assemble the required data, contextualize it as needed, and publish updates at the required frequency.

Pause for definitions

Before we proceed, here are a few definitions of key terms that you may find helpful.

• Model: A model is simply a standardized definition of a data set containing related information. By standardizing the data set definition with a model, the same definition can be applied to similar objects.
• Instance: Instances are models that are applied to different objects. An instance may include the mapping of the source system data to the model attribute name. For example, a Motor model might have an instance of Motor001 for a single specific motor in which all data mappings are managed.
• Payload: A payload is each publish of an instance. A payload typically contains a set of name value pairs that are published at the same time, though depending on the definition, a payload may contain one or multiple values.

As a practice, assembling data payloads designed around use cases is vital for getting the most out of your unified namespace. Industrial DataOps tools are ideal for generating these payloads because they allow for the creation and application of use case-specific standard models in the UNS. Meaning, that once the model is defined for one mixer, the same model can be used for all mixer motors on all the lines and all the plants.

Using the same data for different purposes

You’ll often find that a single source may provide data for multiple use cases. For example, a mixer might provide data on current, speed, and vibration to a predictive maintenance application, an Andon light and monitoring dashboard for the work cell, and an R&D team trying to track product cost. The Andon light is monitoring the cell state, tank fill percentage, and mixer operation, while the cell can generate alarms if the vibration or speed to current balance are not as expected. The cell dashboard includes the Andon status, quantity produced per shift, current work order, recipe, and customer. Meanwhile, the R&D team is monitoring the mixer’s power consumption to gain a more accurate understanding of product costs.

In this example, we have three different use cases: maintenance, production monitoring, and product costing and sustainability. Each requires unique payloads and contextualization, and each data set must be published to different topic locations in the UNS at different frequencies. The data for these three use cases must be sourced from many systems, including but not limited to an OPC server, MES, ERP, and CMMS. Despite these three use cases’ significant differences, they all have one thing in common: They require the mixer’s current, speed, and vibration data. The contextualization and frequency may differ significantly for each use case, but all three need the same data.

By using data models to package data into custom payloads, data consumers can more easily find and use the right data and provide the right data for analysis. An Industrial DataOps tool can be used to create models unique to each use case, delivering complex payloads that contain the mixer data with the right context and frequency to meet the needs of the predictive maintenance application, work cell, and R&D team.

Wrap up

Use-case-based models aren’t just an added benefit for a UNS architecture; they are the key to accelerating UNS deployment and making the UNS useful for all consuming people and applications. Industrial DataOps tools can deliver the modeling capabilities needed to configure standardized payloads, and then replicate these payloads across all your similar assets, cells, lines, and sites.

About the author

This article was written by John Harrington, the Chief Product Officer at HighByte, focused on product management, customer and partner success, and company strategy. His areas of responsibility include market research, customer use cases, product priorities, go-to-market, and financial planning.