How Microsoft Is Leveraging OPC UA to Get an Irreplaceable Position in Your Factory

How Microsoft Is Leveraging OPC UA to Get an Irreplaceable Position in Your Factory

By John Rinaldi, Business Development Manager, Real Time Automation

If you’re like most control engineers, you’ve been a bit behind the eight ball on the whole IoT business. It’s not exactly our bread and butter – we build control systems that make things. As control engineers we’d rather be architecting a new packaging system, improving the performance of a tool or fixing PLC control code, than thinking about processing data. The fun of what we do is seeing pieces drop out of a mold, packages fly down a conveyor line, or bottles and cans get precisely filled.

Those things will always be important but, increasingly, moving information out of processes and into the cloud is of interest to our managers and our customers. They want to record alarms conditions, document temperatures, pressures and speeds and, most importantly, unlock insights into data to dramatically improve business operations.


How to Move Data to the IoT Hub

Microsoft Azure is one of the destinations growing more popular for all this data. If you’ve been busy, you might have missed that Microsoft is generating massive hordes of cash on their cloud operations and their cloud product, Microsoft Azure. Azure is the collection of tools that they’ve built to process all the data from your manufacturing process and every Internet of Things (IoT) device known to man. The functionality available in Azure grows larger every day and includes stream analytic tools, database tools, predictive indicator tools and more.

But before you can use those amazing Microsoft services to process data, you have to get that data from your sensor, drive, chiller or controller to the Microsoft cloud (Azure). If you can’t get it into the Azure IoT hub, you can’t process it with all those great tools. You can think of it as Azure’s holding database. Data is held there until it’s called for by an application.

In their latest series of announcements, it’s clear that OPC UA is key to Microsoft’s strategy of entering and dominating the factory floor through its Azure cloud services, but it’s only one of several ways of moving data there. Let’s look at those mechanisms before diving into their OPC UA strategy for Azure.


Mechanism #1 – Connect a Device Directly to the Microsoft IoT Hub

If you have a device that is Ethernet enabled, you can send data directly to the IoT hub. There are several transport mechanisms that are supported including HTTPS, AMQP and MQTT. HTTPS is probably the easiest for us control guys to use as it requires the least technology. Unfortunately, Microsoft limits an HTTPS “ingestion” (as they call it) to once every 25 minutes. If you have very slowly changing data, that might work but it’s not feasible for a lot of applications. AMQP, without the intervention of a broker, is the preferred mechanism and you can do that as often as you like. MQTT is also available but doesn’t appear to be the preferred option by Microsoft.

That’s the physical layer and the transport layer, but what’s the payload in those AMQP, MQTT or HTTPS packets? The recommended application layer is JSON (JavaScript Object Notation). JSON is nothing more than a name:value pair similar to XML. If your data is two Modbus registers the payload might be 40202:15 and 40203:125617. If its PLC tags, it might be Pump52speed:25 and Pubm52vibration:231. Once ingested, this data is stored in the IoT hub as an SQL table with the table headers of the named entries; 40202 and 40203 or Pump52Speed and Pump52Vibration in my example.

All that’s required in this scenario is that your device support standard TLS (Transport Layer Security) security, the successor to SSL (Secure Sockets Layer).


Mechanism #2 – Connecting Devices to A Cloud Gateway

There are devices that may be IT-enabled but don’t have the ability to support AMQP with JSON payloads. Those devices can be used with a cloud gateway. Cloud gateways of this type will be available from a variety of vendors to support a mixture of devices. These cloud gateways will take whatever Ethernet traffic you have and convert it – usually to AMQP and JSON – such that it can flow into the Microsoft IoT hub.


Mechanism #3 – Connecting Devices Indirectly to the Microsoft IoT Hub

There are other types of devices for which supporting Ethernet or AMQP or MQTT is not practical. Some of these devices, Modbus RTU devices, for example, have no Ethernet physical connection. Others lack the bandwidth or resources needed to support another Ethernet connection or host a TLS security stack. And others have critical timing requirements.

In these applications, a device Microsoft calls a “field gateway” provides the connection to the IoT Hub. Field gateways are specialized devices that enable communications between local devices and the IoT hub. Often a field gateway performs local processing and control functions, filters the device data and reduces the amount of data being transferred to the cloud back end. Field gateways provide the link between EtherNet/IP, ProfiNet IO, DeviceNet, Profibus DP, Modbus RTU and other kinds of industrial networks that don’t connect to the cloud or Internet.

While the interaction with field devices is specific to the industrial network, these devices operate on the IoT Hub side exactly as described in Mechanism #1.

Mechanism #4 – Protocol Translation in the Cloud

Another option for some devices that are unable to directly connect to the Microsoft IoT hub is to connect to a cloud gateway. Cloud gateways perform the kinds of functions that field gateways do in Mechanism #2 but they are located in the cloud.

If you have a device that is Ethernet enabled with support for some particular Ethernet protocol, like Modbus TCP, you can use a cloud-based gateway to connect the payload of that protocol with the IoT hub. The advantage of this architecture is that no physical hardware is required. The cloud gateway is a piece of software.

Cloud gateways interface to the Microsoft IoT hub with AMQP, MQTT or HTTPS, just like every other device discussed previously. The only difference being that no hardware is required.

Microsoft provides an SDK for developing cloud gateways of this nature.


OPC UA and the Microsoft Connected Factory

Microsoft is making an enormous effort to become a major player in factory automation. Nowhere is this clearer than their support of OPC UA. The Microsoft Connected Factory is all about making it easy to connect devices, especially OPC UA devices, to Microsoft Azure and control factory processes from the cloud.

In the “Microsoft Connected Factory,” Microsoft is proposing an architecture where factory operation can be made more efficient and productive using OPC UA with Microsoft Azure tools like Time Series Insights (TSI). This architecture consists of a series of modular components which can include any or all of the following:

  • An OPC UA Publisher Module to subscribe to OPC UA servers in your factory. As data is published, the Publisher module translates those OPC UA Attribute values to JSON and delivers them to the IoT hub.
  • The IoT hub retains the data from the OPC UA servers and make it available to the collection of data management, analytics and web services in Azure.
  • Time Series Insights – In one application of the Connected Factory, IoT hub is an event source for the Time Series Insights service (TSI). Time Series Insights is an Azure service that provides, analytics, visualization and data storage.
  • In other applications of the connected factory, an OPC UA Client in the Cloud delivers commands to the OPC UA servers in the factory just as a local one would.
  • An OPC UA Proxy Module to tunnel those OPC UA command and control messages from the cloud OPC UA Client back to the OPC UA servers using UA authorization and encryption.

Microsoft created quite a stir at the OPC UA Day Europe conference at the end of May. In fact, their series of announcements overshadowed everything else at the conference. They announced:

  • .NET Standard cross -platform OPC UA reference stack (started this a few years ago)
  • OPC UA on their HoloLens product
  • OPC UA Clients and Servers running on Azure
  • OPC Publisher Module for Azure IoT Edge
  • OPC UA Proxy Module for Azure Iot Edge
  • OPC UA Aggregation Server for Azure
  • OS Certificate Store for OPC UA

On top of all that they announced a multicast Local Discover Server (LDS). This is the software that registers local devices and provides clients with endpoints and functional capabilities of Server on the local network. And even more impressive, they announced a Global Discovery Server (GDS) operating as multi-tenant, single URL with the capability to do certificate management hosted on Azure.


Global Discovery Server will make all the difference in adoption

LDS and GDS implementations have been lacking for OPC UA and it is has been one of the weak points of the architecture. Microsoft products vastly improves the OPC UA technology and solidifies Microsoft’s position on the factory floor. Most, if not all, factory floor implementations will need the GDS to handle the certificate management and that means that nearly all OPC UA installations will have a Microsoft presence.

Let’s not gloss over that. It means that Microsoft will most likely have its tentacles into every single factory automation system using OPC UA. The only way to avoid that Microsoft presence is to not use the cloud, not use security or find an equivalent tool to manage the certificates required to implement secure OPC UA solutions.

If you’re new to Microsoft Azure, Microsoft has provided very good introductions to the technology and the key components I’ve described in brief in this article.

If you’re new to OPC UA it’s time to get familiar with this technology. A good place to begin is “OPC UA – Unified Architecture: The Everyman’s Guide to the Most Important Information Technology in Industrial Automation.” This book provides a deep dive into a lot of the technology behind OPC UA.

If you’re one of those engineers who’ve been ignoring the whole IoT, Cloud, Microsoft Azure business, it’s time to get serious about it. Yes, it hasn’t been our bread and butter in the past but times – “they are a changing”. Seeing pieces drop out of a mold, packages flying down a conveyor line or bottles and cans being precisely filled is now only part of our job.


About the Author

John Rinaldi is Chief Strategist, Business Development Manager and CEO of Real Time Automation (RTA) in Brookfield WI. John is a recognized expert in industrial networks and an automation strategist, a speaker, blogger, and author of hundreds of articles and four books on industrial networking. He can be reached here: