Data and Functional Modeling for Unified Namespace
In our previous article, Designing Your UNS Semantic Information Hierarchy, we discussed UNS semantic data hierarchy design using MQTT. In this article, we will discuss data and functional modeling for Unified Namespace (UNS).
In a Unified Namespace (UNS) architecture, different applications and subsystems must understand the data they exchange. This understanding is achieved through a data model, which defines the data's context and meaning, enabling semantic interoperability. Data modeling is, therefore, essential at the start of any data integration process within the UNS. Its primary goal is to outline the structure, relationships, and properties of the data to be used.
Data modeling requires identifying and organizing different types of data attributes. These range from simple operational data to more detailed explanations that define the data's characteristics. For example, these descriptions can include measurement units and other details that together represent something in the real world, like a piece of industrial equipment or a process. A well-structured data model is crucial for organizing data in a clear, understandable manner, preparing it for further processing and analysis. Such structuring is vital for enabling data-driven applications and use cases.
In this article, we will discuss the process of designing your data models for effective integration into the UNS ecosystem. We will also cover the methods for functional modeling that enable interactions within UNS and explain why DataOps is essential for your UNS architecture.
Designing a Data Model for the Unified Namespace
When designing a data model for the UNS, it's crucial to balance robustness, adaptability, and seamless integration with diverse systems and applications. Key properties must be prioritized to enhance the model’s functionality, usability, and relevance amidst evolving industrial demands and technological progress.
In UNS, data models are typically established at the edge and fall into two categories: those tailored for local analytical purposes and those standardized for wider enterprise analysis. This distinction should be considered in your data model design.
Another significant aspect to consider is the balance between complexity and data richness. While enriching your model with extensive data semantics is beneficial, it's essential to maintain simplicity in your data payload. This approach aligns with the UNS principle of lightweight data models.
Below is a list of important attributes to consider when designing your data model for UNS. While not exhaustive, this list serves as a foundational guide for planning your data model in the UNS context.
Model Versioning: Your data model must include a version property, similar to the versioning in your topic namespace definition. This allows for tracking changes and ensuring compatibility with different versions of applications.
Unique Identifier: Every object in your UNS system should have a unique identifier, like a serial number or UUID, for precise identification and tracking across various systems.
Source System Identification: In addition to reflecting the source system in the UNS topic namespace, it's often necessary to embed the MQTT topic path within the data model. This ensures clarity without relying on external topic path context.
Sensor Data: This is the core element of UNS objects and varies based on the application, including metrics such as temperature, pressure, humidity, and vibration. It's vital for analytics and decision-making.
Descriptive Metadata: This encompasses basic information about an asset (like a machine), including its type, manufacturer, model, and specifications. It provides essential context for understanding the data generated by the machine.
Status Information: Real-time data about the operational state of an asset, including error codes and maintenance alerts. This is key for monitoring the asset's health and performance.
Operational Parameters: These are critical settings that determine how a machine operates, such as temperature ranges, pressure levels, or rotational speeds. They can also include work order, product type, and operator ID, varying with the use case.
Data Quality Indicators: Details regarding the reliability and accuracy of the reported data. This information is crucial for analytics applications to assess the data's trustworthiness.
Location Information: Integrating direct location data, like GPS coordinates or site names, into the object model, avoiding dependence on external relational structures.
Timestamps: Implementing a consistent timestamp format for all data points is essential for time-series analysis and critical for applications in analytics and machine learning.
Below is a JSON structure that provides a comprehensive view of a typical UNS object, including all the key aspects required for effective data management and analysis.
{
"modelVersion": "1.0",
"deviceId": "UUID-1234-5678",
"sourceSystemId": "Site1/Area1/Line1/Cell1",
"sensorData": {
"temperature": 22.5,
"pressure": 101.3,
"humidity": 45,
"vibration": 0.02
},
"metadata": {
"type": "HVAC System",
"manufacturer": "CoolAir Inc.",
"model": "CA9000",
"specifications": {
"maxTemp": 30,
"minTemp": 15,
"maxPressure": 150
}
},
"status": {
"operationalState": "Running",
"errorCodes": ["E01", "E03"],
"maintenanceAlerts": ["Filter Replacement Due"]
},
"operationalParams": {
"setTemp": 21,
"setPressure": 100,
"workOrder": "WO-20231201",
"productType": "TypeA",
"operatorId": "OP-1001"
},
"dataQuality": {
"temperatureAccuracy": 0.5,
"pressureAccuracy": 1.0
},
"location": {
"gpsCoordinates": "35.6895° N, 139.6917° E",
"siteName": "Munich Facility"
},
"timestamp": "2023-12-01T12:30:00Z"
}Designing a Functional Model for the Unified Namespace
The Unified Namespace (UNS) does more than just represent data objects for physical machines on the shop floor. It also includes transient objects created from activities occurring at Level 3, which is the intermediate layer between the Top-Floor and Shop-Floor. These activities involve coordinating personnel, equipment, and materials to complete tasks. Additionally, they generate data objects that need a clear and consistent model for integration into the UNS system.
When developing data models for the UNS to enable information flow between Operations and Business domains, there are two main strategies: build from scratch or use the ISA 95 functional modeling standard as a guide or source of inspiration. The aim of ISA95 functional data modeling is to identify common patterns in various manufacturing activities highlighted previously, e.g. Production Tracking, Dispatching, and Execution. These common patterns are then modelled as data objects to facilitate information exchange in a standardized and uniform way.
Of significance to the UNS architecture is the fact that data objects defined by ISA95 are implementation-independent. In other words, the ISA95 is an abstract specification that doesn’t describe data types or information models that can be used to create these objects. Also, it doesn’t specify what transportation mechanism is to be used to move these objects around. It simply defines a standard terminology for these activities and uses UML representation for the data objects.
This flexibility means that the definitions of these objects can be effectively used in a Unified Namespace architecture that utilizes MQTT for data exchange. The choice of how to implement and adapt these standards rests with the system architect. The advantage of such standards is their adaptability; they can be selectively applied and tailored to fit the unique performance and business requirements of a particular architecture.
DataOps for the Unified Namespace
Data modeling is a crucial initial step in establishing the structure, relationships, and characteristics of data objects in your Unified Namespace. However, the challenge arises because not all data producers can shape their data to match the specific structure and semantics required by the UNS, and likewise, not all data consumers can efficiently process data formatted in this specific manner. Consequently, data often requires adjustments to suit the distinct needs of various systems. DataOps addresses this issue by developing an abstraction layer. This layer ensures data aligns with the naming and structural standards of the UNS, rather than conforming to the unique formats of its originating systems.
Let’s explore the capabilities that DataOps brings to the UNS.
Data Normalization: This process involves refining and standardizing data to reduce redundancy and improve data integrity. In environments like manufacturing plants with data from various sensors and devices, normalization ensures that data is uniform in terms of units and formats, facilitating accurate analysis and efficient storage.
Data Transformation: DataOps is responsible for converting raw data into more suitable formats for analysis. This could involve aggregating data, performing calculations, or transforming it into a more comprehensible form. For example, converting raw speed data from various machines into an average speed per shift allows for easier interpretation and comparison.
Data Contextualization: This aspect of DataOps adds layers of meaning to data by incorporating relevant contextual information. It enhances decision-making by including additional details like product information, maintenance records, and environmental factors. The use of metadata and data lineage in this process enriches the dataset, enabling real-time contextualization for prompt and informed decision-making.
Iterative Data modeling: DataOps promotes a flexible approach to data modeling, encouraging continuous refinement and adaptation based on evolving needs or new insights. This adaptability is crucial for keeping the data model relevant and effective over time.
Dynamic Version Control: Maintaining consistency in data models is a challenge in UNS environments, particularly those spanning multiple sites. DataOps introduces dynamic version control, where data models are continuously updated and integrated through CI/CD pipelines. This approach helps prevent conflicts between different versions of data models and ensures they are always up-to-date with the latest requirements.
Essentially, DataOps ensures that data is well-organized, understandable, and optimized for effective application in data-driven use cases.
Conclusion
In this article, we’ve explored the process of designing data and functional models in a Unified Namespace (UNS) architecture. Establishing a robust data model is critical for ensuring semantic interoperability among diverse systems, facilitating data-driven decision-making and operational efficiency. The article highlighted the importance of balancing complexity, data richness, and model adaptability to meet the evolving demands of industrial environments. Furthermore, we discussed the crucial role of DataOps in the UNS ecosystem. By integrating these practices, organizations can significantly enhance their ability to manage and utilize data effectively within a Unified Namespace, ultimately leading to improved operational insights and strategic decisions in the industrial domain.
In the next article of this series, we will discuss security challenges associated with UNS in IIoT environments and offer actionable strategies and best practices to address these challenges effectively. Do check it out.
Unlock the power of Unified Namespace (UNS) architecture. Download our comprehensive eBook titled 'Architecting a Unified Namespace for IIoT with MQTT' to discover strategies and best approaches to effective UNS implementation and take your industrial systems to the next level.
Kudzai Manditereza
Kudzai is a tech influencer and electronic engineer based in Germany. As a Sr. Industry Solutions Advocate at HiveMQ, he helps developers and architects adopt MQTT and HiveMQ for their IIoT projects. Kudzai runs a popular YouTube channel focused on IIoT and Smart Manufacturing technologies and he has been recognized as one of the Top 100 global influencers talking about Industry 4.0 online.
