The Industrial Internet of Things. Everywhere you look, there are projection of 50 zillion devices going online in the next few years coinciding with a data explosion not seen since BitTorrent came out of beta. New and old companies and rushing products to market in order to take advantage of this “brave new world” where a nearly infinite number of devices is streaming data to the cloud at maximum speed and so it can be sliced and diced in massive data warehouses to discover epiphanies such as – allowing your preventative maintenance standards to degrade didn’t actually save you money, your production line really only has 46% uptime when you were reporting 92%, and working your production associates on overtime is actually costing the company more than it is profiting.
Those results are obviously in jest, but my tone about the hype of the IIoT is genuine. I see so many social media posts from industrial automation companies hyping up IIoT solutions that it makes me want to believe it is something truly new and game-changing, but the more I dig, the less substance I find. The things I see typically center around two capabilities: message queuing and data warehousing.
MQTT is supposed to be some wholly new, groundbreaking concept that allows slow, unreliable, or rarely-connected devices to get their data into an IT system. Message queuing technologies have been around for decades. From Microsoft Message Queuing (MSMQ), to IBM WebSphere MQ, to Microsoft SQL Server’s Service Broker feature, asynchronous communication protocols have been used since networks existed. I’ve had developers write interfaces to MSMQ in Java. Service Broker is available from the native SQL OLEDB provider on Microsoft platforms or the JDBC driver for any platform. As long as you can negotiate with these services, you have message queuing.
As for “connecting device data to the cloud,” as long as you can get the data to a database, it can get to the cloud. From the Stretch Database to Azure feature in SQL Server 2016, to using a MySQL client to connect to Amazon RDS instance, to numerous others, any app that can make calls to your message queuing service of choice and your database of choice can take the data contained in those messages and drop them in a table. From there, cook up whatever data warehouse recipe you want with whatever ETL chef’s tools are at your disposal.
Yes, you can certainly roll your own solution from scratch, but there is certainly a market for more integrated solutions. But there are already solutions for logging device data to databases – they are called SCADA and SPC applications. These applications use OPC servers for device connectivity, provide connectivity to all the major relational database engines, and provide business intelligence tools to slice and dice this device-gathered data into meaningful measures and dimensions to be used in whatever reports, dashboards, or forecasts you want. These solutions have been in use for over 30 years and are very mature.
When I attended the SQL PASS Summit 2015 and saw the general session covering how Azure and IoT were becoming bedfellows, my interest was piqued. Does this mean Azure was going to have an OPC UA client service, or even an OPC UA server service? I could see this for data collection, but not real time control. Still, seeing Microsoft seemingly making a big investment into manufacturing IT, my world, made me want to know more. No one in any of the Microsoft booths on the floor seemed to know much of anything of how the “new” market of IoT superseded the SCADA market. I have been searching for an explanation ever since to provide me the secret so that I finally go what the hype was all about. I have yet to find it.