Remote Monitoring of Field Level Devices Using OPC-UA & AWS

As the race of industrial digitalization is gaining pace and a huge capital is invested in this area, there is a need for intelligent remote monitoring of industrial machines to make it successful by reducing the maintenance cost and downtime. In the era where 5G and Edge-Computing are upgrading the way devices are used to communicate, the question remains of integrating brownfield devices that use the legacy industrial protocol to various cloud platforms available in the market. This blog focuses on how data can be extracted from field devices utilizing Industry 4.0 standardized Ethernet-based protocol i.e., OPC-UA (Open Platform Communications United Architecture) is integrated with AWS (Amazon Web Services) for performing various operations like remote monitoring, predictive maintenance, or process improvement.

AWS platform does not have native support Industrial protocols like OPC-UA, Modus, or EtherCAT. All the traffic that needs to be transported to the AWS Platform is mapped to the MQTT (Message Queuing Telemetry Transport) protocol from where the data is then received by the AWS IoT (Internet of Things) Core.

To display how brownfield devices can be integrated into AWS platforms we have come up with remote monitoring solution, where modules are implemented and hosted on the edge devices, that would act as an interface for the data that needs to be transported between Industrial devices and the AWS platform.

Before Jumping deep into our solution, we shall look at what is remote monitoring and its core components?

“Remote monitoring is the ability to view machine status, performance, and behavior that is accomplished via a combination of IoT and cloud computing to track machine performance.” This allows an asset that is on-site in a factory to be visible to parties responsible for preventing downtime, or in the event of unplanned downtime, accelerating appropriate service.

Remote monitoring relies on three core components: connectivity to collect the data, processing and storing the data, and visualization of data. Remote monitoring begins with collecting the data i.e., for modern machines it is possible to stream the data directly to an endpoint, but the traditional machine still requires a piece of code and an edge machine to transfer to the cloud. However, the communication channel should be created to support a complex, heterogeneous environment and IIoT platform. The second step is processing and storing the data, the entire metric can be sent to the cloud or only important data can be sent after the processing at the edge. The last step is the visualization of data via dashboards, applications, or simple mobile notifications. The convergent element here is viewing or getting the notifications in real-time.

Solution architecture

With an overview of the remote monitoring let us dive directly into our PoC architecture considering we are monitoring the existing OPC-UA servers on the shop floor. The solution architecture mentioned above is explained with the help of three core components of remote monitoring.

1. Data collection: From the current set up the data collection part includes four OPC-UA servers running on separate docker containers at the edge machine. These OPC-UA servers generate the mock data of the control valve for demonstration purposes. As a pre-requisite, AWS Sitewise collector and publisher along with AWS Greengrass V2 core is installed on the edge device to push the data to AWS IoT Sitewise. On the cloud side in AWS Sitewise service, we must create a digital twin setup of the shop floor with the appropriate parameters to collect as shown below image.

Digital twin of factory setup in AWS Sitewise

Here we have the Chemical factory setup divided into Zone-A and Zone-B. Both the Zones consist of two valves to be monitored. Each Control Valve asset is being configured to one OPC-UA server endpoint. Once the data is available on Sitewise service it will be published on an IoT topic that can be used by other AWS services for storing or processing or visualization.

2. Processing and storing: Once the data is available on the MQTT topic in AWS IoT, we have a python script running at the edge to filter the necessary data and store it in Influx DB. Influx DB is an open-source time-series database that is optimized for fast, highly-available retrieval of time series data in the fields like monitoring, IoT sensor data, application metrics, and real-time data analytics.

3. Visualization: This is the main part for business folk to see something that is easily understandable. Again, with the virtue of low-budget and efficient monitoring, we used another open-source tool — Grafana for creating the dashboards. Grafana is open-source analytics and interactive visualization web application. It allows you to ingest data from a huge number of data sources, query this data and display it on beautiful customizable charts for easy analysis. We used influx DB as the primary data source and queried the DB in regular intervals of 5 seconds to have a near real-time update of the dashboard. The below image represents the dashboard containing the separate graphs for each control valve in ZONE-A.

Grafana dashboard of factory setup

Till now we discussed our approach to how the industrial devices are integrated with the Cloud platform using the wired-based approach. In the next iteration of our blog, I would be highlighting how 5G can be used instead of the wired infrastructure. Apart from the 5G stuff, the next iteration of the blogs would be based on the following topics.

1. Implementing the machine learning model at the edge makes it an intelligent edge use case. With data that we collect from the machine available on AWS IoT can be stored and used to train the machine learning model in AWS Sagemaker. Later, the trained model can be deployed on the edge for real-time decision-making to prevent machine breakdown.
2. The stored data can also be used to find out the meaningful insight using AWS managed analytics services like IoT Analytics, AWS Kinesis for streaming data, or AWS Redshift for huge data stored in a Data lake. These useful insights can be used to forecast the machine downtime or replacement requirement.
3. It can also be a base for a blockchain application as it deals with industrial machines there is a great chance of involvement of a multi-party system. Using blockchain, tracking and trace of the asset’s health and automating maintenance operations with high security is possible.
4. Implementing the wireless communication at the edge using the 5G campus network available in Innovation center Garching and incorporating the notification service from AWS i.e., AWS SNS to send an alert to the plant manager in case of data anomaly.

Soon after reading this blog, one can get the access to our Gitlab repository by contacting our team (Sagar<sagarpramodvs@gmail.com>, Aniket<aniket_yeole@yahoo.com>, Arun<arunteja.sriramula@gmail.com>)to build their own PoC for remote monitoring of the OPU-UA servers using the AWS platform. See you all soon in the upcoming blog of this series.