IoT (Internet of Things) is all the rage. Everybody is talking about it. My morning Wall Street Journal seems to have an IoT story of some sort every day. Today was how the accelerometer data from cell phones in California is going to be used to track earthquake activity. Instead of putting expensive metering devices all over the terrain, use the data from these cheap accelerometers to get more quantitative data. They may not be as sensitive but they will cover a much broader area and there appears to be more value in having less sensitive readings over a broad geographical coverage than in very sensitive readings in a few places.
Moving all that data is, of course, the issue. And that’s a very important discussion and one that I will address in a later article; but today I’d like to put this matter to rest:
EtherNet/IP, Modbus TCP, and ProfitNet IO are not IoT transport protocols.
I don’t know where the idea of Ethernet I/O protocols as IoT protocols started, but I am pretty sure it started with the trade groups for these technologies. The problem with a lot of these organizations is they don’t know when to quit. EtherNet/IP, ProfiNet IO and to a lesser extent, Modbus TCP are really perfect as they are. They do the job of moving I/O data from end devices into a controller quite well.
These trade associations, and the vendors in them, have done a great job of defining the right combination of transports, encodings, messaging, and data connections that solve the I/O communications problem in manufacturing facilities all over the world. Good job, kudos to them.
But the problem now is that they don’t want to quit. Let’s extend it to cover this application domain over here. And that one over there. And this other one, too. They start burdening it with layers and layers of more complexity and make it do so many things that it’s sometimes difficult to know what the problem was in the first place! (OPC UA has this problem now.)
My biggest complaint is with the people who want to use EtherNet/IP, ProfiNet IO and Modbus TCP to move IoT data. Now that’s just plain nuts. Those technologies move I/O data that’s very strictly defined between an end device and a controller. Outputs move from the controller to the end device. Inputs move from the end device to the controller. And they move continuously, over and over, usually every 1ms or 10ms.
Why You Don’t Want to Move IoT Data via Ethernet I/O
1.The data can’t be that strictly defined. There’s lots of different kinds of data to move in the IoT world, and it changes from moment to moment.
2.There’s no security associated with these technologies. They’re working on that but when it will get to market is an unknown.
3.The data is intermittent. I don’t want my garage door system eating up bandwidth telling me it’s closed every 10msec. I’d like to know when it opens but that’s all.
4.These technologies are not designed to work over the Internet. They could, but they’d eat up all the bandwidth.
5.The data representation doesn’t work for IoT devices. In ProfiNet IO, every end device has to look like an I/O rack. It’s bad enough that I have to make a barcode scanner look like an I/O rack on ProfiNet IO, but do I really want to make my water softener look like an I/O rack?
There are more reasons, but I think I’ve made the point. Use EtherNet/IP, ProfiNet IO and Modbus TCP in the applications where they are best suited – and that’s not in IoT applications.