Around the world, in factories large and small, worlds are colliding. The Modbus world, massive and pervasive, is colliding with the even larger, more pervasive Internet of Things (IoT) world. Modbus devices and the data they contain are often not easily included in today’s HMIs, analytic systems, historians and critical applications, even though they contain a lot of important manufacturing data.
This paper voices some important truths about the collision of these two worlds on your factory floor and what you should do about it – before it’s too late.
If Modbus were human, it would be in assisted-living and using a walker. Historians can disagree about its actual birth, but it’s certainly a product born of the 1970s. If technology years were referenced the same as dog years, Modbus would be about 287 years old. The word “success” is an understatement for how well it’s done.
Modbus has found its way into hundreds of thousands—if not millions—of devices. You can find it in every industry and geography. You can find it in every kind of device, literally from A-Z: from absolute encoders to zero-point thermometers. I bet there isn’t a country on earth that doesn’t have some Modbus device tirelessly delivering registers and coils.
Before Modbus, all we had was electrical signaling (Figure 1). For digital input and output devices like push buttons, lights, motors and the like, we wired a single wire and a return from the controller to the device. For analog input devices like a temperature sensor, or output devices like drive speed, we used 0-10 Volts, 4-20ma current loop or RTD. Wired was the norm, everything was either a voltage level, current level, or simply a binary input or output. With thousands of inputs and outputs in a big manufacturing machine, the labor to install all those wires, checking that every single one of them terminated to the right position, and testing each one took weeks and sometimes months of effort.
In those days, the concept of data, let alone information, didn’t exist. We had inputs. We had outputs. Even things that cried out for digital control required analog wiring. Drive speed couldn’t be specified as 100 RPM. Instead, it was specified as a 0 to 10 Volt output with the precision of how you converted that signal defining how precisely you could control a speed. Luckily, everything else was crude too so we didn’t need very precise control a lot of the time.
Modbus changed all that. Modbus changed everything. Modbus introduced the concept of data on the factory floor. Modbus made it possible to connect an entire group of devices using only two wires on the controller. That alone saved a massive investment in wire, labor and installation time. Instead of miles of wire connecting hundreds of devices, a simple two-wire pair could be daisy-chained from one device to the next, and to the next. It was revolutionary for its time.
It wasn’t just that Modbus was the first serial protocol; Modbus was the right technology at the right time. You must remember that the first microprocessor (Figure 2) was invented shortly after the birth of Modbus. Do you remember those microprocessors? Simple, 8-bit processors with severely limited code space and memory.
Now we live in the IoT age. There are more seminars, webinars, and words written about the Internet of Things than any other topic of the last 40 years. What some people forget is that IoT is not new to us in the automation world. We’ve always been pulling data out of factory floor systems and moving it into business systems and databases in the enterprise.
It started with operators writing data on sheets, then keypunching and loading it onto magnetic tape. Once a week the tapes were loaded, reports were run on that data and dropped on people’s desk around the factory for review. Some were “mailed” to corporate for their analysis.
Eventually, many factories had people walk around the factory floor collecting memory sticks out of devices, carrying them back to their desks, uploading the data, converting it and then finally, loading it into a database. It was rudimentary, but it was effective because they collected only the critical data.
It wasn’t always that crude. A lot of the larger manufacturing companies spent massive sums to build proprietary systems that could move production, quality, and other operational data from their manufacturing systems to an MES or ERP system automatically. Those systems were complicated, slow, and a nightmare to maintain, but they worked.
IoT in manufacturing is just the latest evolution of what we’ve always been trying to do. What’s new is that we now have technologies that make it easier than ever to accomplish. But that is our biggest problem. It is now so very easy to move data to the cloud that we have all sorts of manufacturers putting data there with no idea why they’re doing it. In many cases, there is no business model, no plan to monetize the data, no thought about ROI – no plan at all for how to use the data. Many engineers have these hammers in their toolbox (MQTT, AMQP, OPC UA) so they start swinging away. There are statistics from Cisco and others that indicate that about one in four IoT projects achieves an ROI.
In fairness, C-suite people are pushing engineering staffs to implement IoT because of consultants promising huge paydays and hordes of vendors offering painless, all-inclusive solutions. These vendors portray that they can pull data from anything, as fast as you could want, in any industry with no deployment cost or effort on your part.
While many of these vendors oversell their IoT solutions, there is some truth in that in a highly competitive, global environment, factories must become faster, more efficient and automated. The applications offered in the Cloud by Amazon (AWS), Microsoft (Azure) and others are the tools many larger, multinational manufacturers use to compete. There is an amazing array of tools offered in these services: computation tools, storage tools, database tools, presentation tools, and network management tools. The list grows by the day. To take advantage of them, data, all of it – even the data stored in Modbus registers and coils – must be made available to these Cloud-based applications.
And that brings us to the collision of the Modbus World and the IoT world.
One option is, of course, to plan a big retirement party for Modbus, give it the gold watch and kick it to the curb. That’s probably not the best option as you likely have one or more Modbus devices that wouldn’t be difficult but would be inconvenient and annoying to replace.
Another option is to use a gateway to move the Modbus data back to some local or remote database where you can connect it to some IoT application. That’s not hard if it’s Modbus TCP, but since Modbus RTU is single master, you’ll need to grab that data from the current Modbus master device. Our company, Real Time Automation, and others have devices to move Modbus data to the Enterprise and the cloud.
One interesting way to gateway Modbus data is to use OPC UA to transport it. OPC UA is the more secure, open, reliable and flexible successor to the Windows OPC we’ve used for all these years. You have a lot of options with OPC UA. You can securely pass Modbus messages through it (Figure 3). You can remap Modbus devices as an OPC UA node. Your Modbus device can be a data provider, or you can represent your Modbus data as OPC UA objects. OPC UA provides you with connectivity to the Cloud (MS Azure, AWS), the Enterprise or some programmable controllers.
As a gift for reading this whitepaper, you’re entitled to a free copy of one of my books Modbus: The Everyman’s Guide to Modbus or OPC UA Unified Architecture: The Everyman’s Guide to OPC UA to learn more about these options. Contact an RTA application engineer here or call 800-249-1612.
Modbus has stood the test of time, but our manufacturing systems are evolving in a way that is completely integrated. Modbus is no longer a good long-term technology for most applications. As a vendor of Modbus devices or as a user, the migration to the Cloud is just beginning and unfortunately at some point, we’re going to have to say goodbye to that old friend, Modbus.
John S. Rinaldi
ABOUT THE AUTHOR
John S. Rinaldi is Chief Strategist, Business Development Manager and CEO of Real Time Automation (RTA) in Pewaukee, WI. John is an Electrical Engineer with a Master’s Degree in computer science (MS CS). John and his team of expert automation specialists at Real Time Automation, Inc., supply industrial and building network connectivity software and products all over the world. With a focus on simplicity, support, expert consulting and tailoring for specific customer applications, RTA is meeting customer needs in applications worldwide. John is not only a recognized expert in industrial networks and an automation strategist but a speaker, blogger, the author of countless articles on industrial networking and the author of five books. To contact John, visit www.rtautomation.com/contact-us/ or connect on LinkedIn at /in/johnsrinaldi.