A unified namespace is termed as single source of truth or golden record for Industrial IoT data. It is based on ISA 95 model standards combined with the way the data is contextualized and stored in database with modern data platforms set up. It is a centralized repository with hierarchical data about the IIOT system.
In a typical IoT manufacturing system, the devices are named differently in each of the systems like MES, SCADA, ERP and Historian. Providing a unified namespace across all systems replacing ISA-95 hierarchy improves the system performance by cutting out the middlemen.
The inspiration of Unified Namespace is from distributed architecture paradigm where instead of having data existing in silos across all layers of technology, access it a unified way so that it remains the same everywhere. The naming convention should also reflect the business from top level down to a device in shop floor. Also, the name should reflect all events that had happened in the business to a particular device. To consider an example, the hierarchy should reflect the organization, division, Production line, device name and events such as drop in production line efficiency in a device. All of it together is considered as Unified Namespace.
Ideally the communication protocol is MQTT and traditionally this MQTT points to a central repository of information that has the hierarchical enterprise structure, and it used to publish the events for that data. So, the most common pattern is to implement UNS in an MQTT broker. MQTT broker receives messages published by clients, filters the messages and publishes to subscribers. Though it is easy to implement MQTT since the events are handled, it does not hold the history of information which mandates us to choose a database or data warehouse. A database can hold historical data, but mainly it should contextualize the data to act as Unified Namespace.
Let’s see the logical architecture for typical UNS implementation:
Now that we are familiarized with the concept of Unified Namespace, it is also essential that we need to build a comprehensive real-time modern data platform as depicted in the logical architecture to bring single source of truth for the industrial data and store it in a database to consider it as UNS database.
The AWS Native Architecture supporting UNS implementation is as below:
In the above architecture, we have devices, MES/ERP, PLC, SCADA and Historian constantly streaming data from devices to AWS IoT Core where AWS IoT Greengrass acts as an edge gateway. The edge gateway is built with the capability of sending real-time data directly to AWS IoT Core.
An IoT Core rule is configured to stream the data to AWS Kinesis streams and performs in-stream processing and transformation using Kinesis Data Analytics and streamed to Kinesis Data Firehose. The data is standardized, contextualized, analyzed, and transformed using Amazon Kinesis services which serves as backbone for UNS.
Then the real-time transformed data is stored in Amazon TimeStream for Influx DB through Kinesis Data Firehose, and this is considered as Unified Namespace Database.
Real time dashboards are created in AWS Managed services for Grafana.
Raw telemetry data is stored in Datalake(S3). The historical data is transferred from the On-premises historian and data stores to AWS S3 through AWS DataSync where DataSync agents are installed On-premises to do the job. Data in S3 is cleaned, processed, and transformed using AWS Glue. This transformed data is then used to create reports and dashboards in Grafana. The data is utilized for predictive analytics where ML models are deployed in AWS SageMaker.
AWS CloudWatch is configured with the required metrics for consistent monitoring. CloudWatch dashboards are created, and the infra engineers can monitor the complete AWS native services.
Top comments (0)