Azure has all sorts of Publisher/Subscriber resources available to allow sending and receiving messages (events) within Azure. Think of the Service Bus, EventHub, Storage Queue, Stream Analytics, Azure Functions, etc.
At some point, Microsoft realized that a more formal way of the eventing abilities of these resources was needed.
This let to the introduction of the EventGrid, one overall solution to send and receive messages. Azure Event Grid relatively new.
The Azure Event Grid allows you to easily build applications with event-based architectures
The Azure resources are divided into two groups:
Event sources. Resources which produce events (or pass-through events)
Event handlers. Resources which are able to pick up events and do something with them
These resources all come together in the Event Grid.
The Azure IoT Hub can act like an Event Source too. The events exposed are:
In the past, I have written multiple blogs about implementing OPC-UA on IoT Edge.
Until now I have written about collecting OPC-UA values and sending them to the cloud using the OPC Publisher.
But this OPC Publisher is actually just a small part of what Microsoft is actually offering regarding OPC-UA.
Microsoft has a team in both Redmond (USA) and Munich (Germany) working on Industrial IoT. Everything they produce is open source. You can find thier work on github.
With the OPC Twin, they also make it possible to discover, register and manage your Industrial Assets with Azure IoT and most of it can be done zero-touch.
Look at this diagram covering OPC-AU on Azure:
To the left, we see a OPC-UA server and an IoT Edge gateway. This is ‘living’ on the factory network. In the middle we see the Azure IoT Hub acting as cloud gateway and to the right, we see the OPC-UA backend which is provided by the IIoT team.
Of course, all of this is open source. And out of the box, a lot is already working.
OPC-UA, the full round trip
In this blog, I want to show how we can discover OPC-UA servers, update the OPC Publisher to read new nodes (exposed by the discovered servers) and I want to send commands back to the OPC-UA servers.
The current IoT Edge is based on .Net Core 2.1, the current LTS version. That’s why sourcecode, specifically written in .Net Core 2.2, was not able to be used in the Module templates.
So it’s safe to assume, that in the near future IoT Edge will have an upgrade towards .Net Core 3.1.
The release blog came with this little note with a rather big impact:
Note: Please ensure that .NET Core 3.1 ARM64 deployments use Linux kernel 4.14 version or later. For example, Ubuntu 18.04 satisfies this requirement, but 16.04 does not.
So the current VM will not last very long anymore. You will need a new VM template, based on eg. Ubuntu 18.04.
Note: current IoT Edge Gateways rolled out with the Ubuntu 16.04 OS in test, acceptance or even production situations have te be upgraded soon to before the IoT Edge Runtime can be upgraded. So check the operating systems that come with the Industrial PCs you buy from your hardware vendor.
Let’s see how to start with Ubuntu 18.04 LTS on a VM.
A few years ago I blogged about my open source project which makes it possible to connect The Things Network LoraWan cloud to Azure. It runs as a Webjob and provides a stateful bi-directional communication channel so devices from the third party (TTN) cloud are automatically registered in your IoTHub, can communicate their messages to the Azure cloud and they can receive commands back.
Recently Microsoft announced their generic bridge between third party IoT clouds for IoT Central. It is called: IoT Central Device Bridge.
Basically, it supports all cloud services which are able to send device telemetry to a REST endpoint.
If you visit my blog on a regular basis, you see me blogging a lot about Azure IoT Edge. This means that logic is deployed from the cloud onto Industrial PCs (or a more moderate, non-industrial, Raspberry Pi).
But this is just the ‘third’ generation of automatically controlling machines.
The first generation are magnetic contactors or relay like this one:
The logic is ‘hardcoded’. If some inputs are set, some outputs are set; or not. With each kind of relay comes some internal schematics:
It’s easy to see the limitations of these kind of relays. Wouldn’t it be great to program a similar relay a bit more dynamicaly using a little bit of software?
Enters the second generation: PLCs or Programmable Logic Controllers:
I got my hands on a Siemens LOGO! 230R. Although this model is not sold anymore, its programming model is still valid. Newer models have more capabilities but still rely on the same basic functionality.