Integrating OPC UA machine events into the Amazon Virtual Andon solution

Introduction

In modern IT, everybody speaks about microservices and integration between different systems. But when we look at the shop floor, the reality is that there are a lot of different protocols depending on the machine vendor. Even when the protocol is well understood, there is still a need to implement protocol-specific adapters to convert the data into a unified format.

With this blog post, we will discuss how data extraction can be simplified with standards that current machines vendors are implementing today. A community of the machine building industry has released a standard called umati (universal machine technology interface) that facilitates the connectivity and data exchange with any machine that implements this interface. We will show how this can be integrated into a cloud environment to monitor a machine status, which is one of the most common ask from our customers.

Observing the machine status and integrating this into modern communication environments—like virtual andons, mobile push notifications, and data lakes for historic data—are the first steps toward a data-driven manufacturing environment. On the other hand, the requirements for reacting to the data depend on the use case. All those technologies exist already on the Amazon Web Services (AWS) cloud environment. For example, if you send data to AWS IoT Core—which lets you connect billions of Internet of Things (IoT) devices and route trillions of messages to AWS services without managing infrastructure—it is straightforward to send a push notification to a mobile device if a certain condition is met. To perform advanced analytics on this data, you can then forward it to Amazon Simple Storage Service (Amazon S3), an object storage service, by using Amazon Kinesis Data Firehose, which lets you reliably load near-real-time streams into data lakes, warehouses, and analytics services.

But the initial monitoring for the machines is usually done with an andon solution, which is an AWS solution to alert operators of a quality or process problem. The AWS Solutions Implementation Amazon Virtual Andon—which provides a scalable andon system to help optimize processes, support the transition to predictive maintenance, and help prevent future equipment issues—offers a front end for engineers and operators with monitoring dashboards and workflows. It can be fully customized and can be integrated with other systems, such as ticketing and enterprise resource planning (ERP) systems.

So let’s see how we can automatically discover machines on the shop floor that follow the umati specification based on Open Platform Communications United Architecture (OPC UA), then integrate the alarms and event interface into Amazon Virtual Andon and facilitate a seamless data exchange.

Introducing OPC UA events

The OPC UA standard helps equipment publish events and conditions to communicate state changes. This is defined in part 9 of the OPC UA specification and is optimal for events that are not based on sensor readings. These conditions, such as a jammed motor, can then be visualized on a local human machine interface or processed further to initiate alerts or maintenance tickets, as we will show here.

Introducing umati

Although OPC UA events contain metainformation, such as the severity or the type of the events, they usually require additional information about the context they are issued in.

Often, you will need additional information about the sending machine or system to decide how to deal with an event. The umati companion specification standardizes how machine information can be discovered using OPC UA. It also defines a standard event model that is common to all machines implementing this standard so that any machine can communicate with other systems without manual integration.

Connecting machine events to Amazon Virtual Andon

So how can those capabilities, facilitated by standardization efforts such as the umati companion specification, now be used to seamlessly integrate a shop floor machine with a cloud-based solution like Amazon Virtual Andon?

The above architecture diagram provides a high-level overview of this kind of integration. On the left side, there’s an umati-compatible OPC UA server that exposes alarms and conditions of one or multiple machine tools. The right side shows the plant operations teams and the company’s IT systems, such as ticketing or ERP systems.

Overall, the process of extracting alarm and condition data from the umati server and delivering it to a cloud-based solution that responds to events in near real time can be divided into three major components:

• Discovery of a machine tool inventory from the shop floor using umati
• Subscription to the relevant machine events (alarms and conditions) through OPC UA
• Processing and delivering the events to Amazon Virtual Andon

The architecture relies primarily on two AWS services apart from Amazon Virtual Andon:

• AWS IoT Core: a managed cloud environment that lets connected devices easily and securely interact with cloud applications and other devices
• AWS IoT Greengrass: an open-source edge runtime and cloud service for building, deploying, and managing device software

For this post, we will start on the left side with the umati server, then follow our data pipeline through its individual stages to the plant operations teams and IT systems. For interacting with physical machines on a shop floor, you will need a local gateway device, typically an industrial PC, to access the local network.

The architecture diagram depicts this industrial PC on the left side as an AWS IoT Greengrass core device. Although the AWS IoT Greengrass Core software is not required for you to register a device with AWS IoT and perform information exchange (or even over-the-air updates), it simplifies the process—for example, by bundling functionalities of AWS IoT in a simple command line interface.

A piece of software on a connected device that is managed by AWS IoT Greengrass is called an a Greengrass component. Our sample implementation depicted in the diagram consists of three such components. The discovery process is handled by UMATIInventory and UMATIDiscover.

UMATIInventory is responsible for correctly displaying a full inventory of a local factory network’s umati-compatible machines. This inventory is displayed in an AWS IoT Device Shadow. Having this information available in the cloud facilitates both working with the machine tool metadata and associating incoming events with a specific machine or station on the shop floor. This helps operators put each event into context to associate it with detailed resolution instructions or understand the downstream process impact.

UMATIDiscover is responsible for providing this inventory information to UMATIInventory. On intervals, the component scans the local factory network (or specific internet protocol addresses that can be provided as a configuration parameter) for OPC UA servers. Every server that UMATIDiscover finds is then scanned for umati-compatible machines. As these machines’ representation in the OPC UA server is standardized, the component can uniformly represent all machines in a specific data structure, such as in JSON.

Generally, all communication between components occurs using the local interprocess communication capabilities of AWS IoT Greengrass.

Subscription

After the machine inventory in AWS IoT Core is successfully populated, event data can be extracted from the identified machines. This is done by initiating a data subscription process, which is handled by the UMATISubscribe component.

UMATISubscribe is supplied with a list of values that it should subscribe to on each umati-compatible machine. Incoming event data is filtered and transformed locally, and the result is then sent to AWS IoT Core as a JSON document.

The above image shows such an exemplary JSON document as it is received in the cloud by AWS IoT Core.

Generally, this data exchange is sent over an encrypted Transport Layer Security connection using the MQTT protocol. You can configure individual industrial PCs that might be running this component stack at different locations in a factory to publish event data to an MQTT topic.

At this stage, you will have both a populated inventory of machine tool metadata accessible in the cloud through an AWS IoT Device Shadow as well as corresponding, transformed event data that is continually being published to an MQTT topic in AWS IoT Core.

The final step is to connect those two streams of information to the Amazon Virtual Andon solution. You can do this using two AWS Lambda (which is a serverless, event-driven compute service): an inventory adapter and an events adapter. Amazon Virtual Andon is provided, maintained, and continually updated as a vetted AWS Solutions Implementation, and this approach is designed to minimize customization by providing the data in the format that Amazon Virtual Andon is expecting.

The inventory adapter function takes care of translating the current machine inventory into a set of areas, stations, processes, and devices in Amazon Virtual Andon. After each discovery, if the content of the machine inventory changes, this function takes care of synchronizing those changes with the data structure in Amazon Virtual Andon.

The events adapter function takes care of translating the generic OPC UA JSON structure to the events or issues structure that Amazon Virtual Andon is expecting. It uses the machine inventory shadow to associate incoming events with a specific machine tool and populate them with additional metadata.

Achieving simplicity through building blocks

The architecture outlined above uses AWS managed services as the core building blocks for several capabilities:

• Managing the edge runtime components that are communicating with machines on the shop floor (such as rolling out software components or monitoring log files and metrics) through AWS IoT Greengrass
• Bringing cloud processing and logic locally to edge devices running on the shop floor
• Establishing reliable communication even when there is only intermittent connection to AWS
• Establishing secure two-way communication between the edge and the cloud through AWS IoT Core

In this way, AWS manages the undifferentiating tasks, such as patching, scaling, and operating the underlying infrastructure.

For the parts that require a higher degree of customization, such as the dashboard to communicate the machine state to the end users, you can rely on AWS Solutions. AWS Solutions are vetted technical solutions that are well architected. These solutions in turn rely on AWS managed services as their building blocks and are available as customizable source code. That way, they provide the flexibility for you to customize them without having to reinvent the wheel.

Moving toward new capabilities

We have shown how simple data integration from a factory machine to the cloud can be if you are relying on industry standards and how you can use the data in an andon solution. But this is just the starting point. So let’s scratch just the surface of the virtually unlimited possibilities that AWS offers you to drive your manufacturing environment with data.

First, as mentioned in the beginning, it’s simple to extend the shown solution through a mobile integration. For a starter, here’s step-by-step documentation explaining how to send SMS text messages based on the alarms created by the machine or how to fully integrate mobile push notifications by using Amazon Simple Notification Service (Amazon SNS), a fully managed messaging service.

More importantly, when the data is stored on an industrial data lake, you can merge it with static and moving data from other systems like ERP, customer relationship management, or manufacturing operations management systems. Some of the machine data that is discovered using the umati standard can be complemented with data from an ERP system. This helps accelerate analytics and processing capabilities, which can help you solve a very challenging task: the tagging of incident-related event data. When you have data from the ERP system alongside information like the time of an incident and the machine’s sensor data (which could be gathered through AWS IoT SiteWise, a managed service that simplifies collecting, organizing, and analyzing industrial equipment data), you have the optimal base to facilitate predictive and preventive maintenance.

Machine learning services like Amazon Lookout for Equipment—which lets you detect abnormal equipment behavior by analyzing sensor data—can gather all this information directly from your industrial data lake, and there’s no need to manually add labels for abnormal equipment behavior.

So the next task for you is to examine your machines and find out which of them would support the umati standard. Then, test their integration with the Amazon Virtual Andon solution, and see how simple it is to get started.