Modbus to Azure

I am a big fan of Modbus. Always have been and always will be (after all, I wrote the Modbus book “Modbus: The Everyman’s Guide to Modbus”). I really admire the simplicity and elegance of Modbus. It’s just like an old sweater you’ve had since college. You remember the girls you dated wearing it, how it kept you warm in the college library, and how much you enjoy wearing it while playing with your kids on a cool fall morning.

Now, in 2017, it’s not a technology that I urge new product vendors to adopt even though it has incredible market penetration. There are literally hundreds of thousands if not millions of Modbus devices in the world. And they aren’t going away very fast. It’s hard to replace devices that are still doing their job and doing it well. These devices are easy to understand, embedded in working applications, and very maintainable.

These devices sometimes have important data and no Ethernet connection. How do we get data from a device like that, especially one that has a whole host of Modbus register and coil data, into something like Microsoft Azure where it can be processed with all the features and functionality provided by the Azure IoT suite?

Many of us Industrial Automation guys understand the Modbus side of this problem. We understand Modbus registers and coils and the functions that have to be used to grab that data and move it. For example, if the device has three temperature loops and we want to send those three temperature values to Azure, we can be pretty confident that we could setup a gateway to grab those temperatures over Modbus TCP or even Modbus RTU. We can grab the data relatively fast if it’s Modbus TCP and somewhat slower on RTU by using Modbus Read Holding Registers Function code 3.

But once we have that, how do we get it into Azure?

Azure, unlike a Modbus RTU device, is on Ethernet (actually in the Cloud). The first problem we have is to bridge from the RS485 of Modbus RTU to Ethernet. That’s a hardware device – we need a Modbus RTU to Azure gateway. We can’t do that in software as you need an RS485 driver.

Next, we have to provide the right transport layer. Microsoft Azure by default supports HTTPS, MQTT, and AMQP transport layers. Any of these transport layers will work for us; our data can get there on any of them. If this is a single device, we can just use an HTTPS connection right to the MS IoT hub. If there are multiple devices, we might use a set of Modbus to Azure gateways with MQTT or AMQP and a broker device to aggregate the data. In our example, we just have a single Modbus RTU controller and have only three registers to send so we’ll just use HTTPS as our transport. The data doesn’t change very fast which is good for us as Azure doesn’t ingest data very fast on the HTTPS channel.

So now, we’ve converted the physical layers, we’ve selected HTTPS, and now we’re ready to send our temperatures into Azure. Well, not quite yet. We now have the infrastructure to send packets from our gateway to Azure, but what’s in those packets? How will Azure decode them?

For our simple application we can use JSON (JavaScript Object Notation), a very minimal, readable format for structuring data. JSON is much like XML: just a series of name/value pairs that make it easy to send data from one device to another using ASCII text processing – something every computer can do.

In our temperature application, the Modbus registers can load into JSON text something like (“L1Temp”:29.2). That JSON is timestamped and easily ingested into Azure, and becomes part of the database for the device ID it is assigned to in Azure.

In a different case, if we had an Ethernet capable device that could support HTTPS, MQTT, or AMQP directly, we could eliminate the hardware gateway and move this data to Azure directly.

But since we have a Modbus RTU device, we use a gateway and get data to Azure quickly and easily. It’s not hard and it keeps those old Modbus devices viable for a little while longer, just like that old sweater.