It’s been a rough six weeks since my last newsletter. First, I had a well-respected industry analyst disparage my OPC UA book. I don’t claim to be a professional writer, but I’d argue despite his comments (hopefully not lodged with Amazon), it’s still the best OPC UA book available. Secondly, many, many of you wrote and called about my Industrial Internet of Things Myths article. More than one guy cornered me at trade shows and one especially offended individual spray painted my garage with “MQTT Lives.”

If I had to characterize all the comments, I’d say these people suggested my ten myths of IoT were “less than accurate.” [Editor’s note: You can find the original article in Issue 40: Jan. 2018 at https://www.rtautomation.com/company/newsletter]

I’d like to say what I wrote about IoT and specifically MQTT in the last newsletter was a test of the audience to see how closely you are all paying attention. It looks like a lot of you do pay attention – close attention. But I won’t say I purposely misstated those things because it wouldn’t be true.

I’d like to think that I have an open mind – some would characterize it as an inability to focus. In my defense, I try my best to call them as I see them, and offer information that is the best I know at the time. I have no reason to engage in hype or carry water for any technology or vendor. My job is to offer the best advice I can on issues and technologies pertinent to networking in the manufacturing industry.

I’ll admit to this hasn’t always worked out well for me. I am on what some might term a blacklist at one of the biggest companies in manufacturing. Profinet International and the Open Device Vendor Association (ODVA) have both written me nastygrams at one time or another - most recently when I made fun of them for proclaiming EtherNet/IP and PROFINET IO were IoT technologies. Even the OPC Foundation sent one of those missives to me in 2016 concerning my complaints about the PubSub development. About 15 years ago, some DeviceNet vendors wanted to throw me out of one of the ODVA. “Loose Cannon” was the term they used.

I haven’t purposely tried to tweak anybody (except occasionally the ODVA and PI). I do my best to try to have an open mind on the issues. Given all the people that contacted me on last month’s issue – I engaged some really smart people in conversation about the topics I covered. And, I’ll admit I should have thought about it a little harder. I’ve now come to some new conclusions that are slightly different (170 degrees or so) from my earlier thinking.

My opinions as of February 2018 are:

1. Inside the factory floor, the best technologies to move networked I/O data from field devices to programmable controllers are EtherNet/IP and PROFINET IO. Nothing else makes sense.

2. At the sensor level, the best technology to collect I/O data from sensors and actuators is IO Link.

3. The best technology within the plant floor environment to move non-control data and general information is OPC UA. You should get my blue book on it and see if you agree with that industry analyst or not (you can get the OPC UA book on Amazon). When a noted industry analyst, who shall remain nameless, pans a book – it’s probably one you should get.

4. OPC UA is not the best technology to move data to the Cloud. It is probably second or third best (I’m sure a nastygram from OPC UA Foundation will follow shortly).

5. MQTT is the easiest way to move factory floor data over the internet and into a Cloud application. I retract my statement that MQTT is not a viable IoT technology, though I still have reservations on how to secure that data.

6. JSON and XML are standard, open and effective mechanisms for encoding MQTT data.

I’m glad to get all this off my chest. It’s been a rough few weeks. Took me half a Saturday to repaint my garage door (I’m joking about that – no one graffitied my garage door).

BANDWIDTH VS SPEED – A Quick Overview
I hear a lot of customers and even some distributors discussing speed and bandwidth as if they are the same thing. They are related, but far from the same thing. It gets even more complicated (and confusing) whether we’re discussing WANs or LANs. With WANs we often talk bandwidth. With LANs we often talk speed. A good question to ask to see if you understand speed and bandwidth is to see if you can answer the question “What would you rather have, more speed or more bandwidth?”

Speed is the easiest to understand. Speed is simply the amount of time it takes to move a bit from here to there. A 10mb (10 million bits/sec) network speed means that 10,000,000 bits flow across the media every second. That seems like a lot, but it’s only 1.2 megabytes per second which is about the size of those floppy disks we used in days gone by. If you sent 1.2 megabytes over a 1 gigabit network (100 times faster); that would be like moving the data in 100 of those floppy disks every second.

Bandwidth is a tad more complicated. Bandwidth is the amount of usable data you can move over the network. You can think of it this way. I love German beer. Suppose the beer tap at my favorite Nuremberg bar dispenses a 1 liter mug every 10 seconds. That’s six mugs (6 liters) every minute with an overall rate (speed) of 360 mugs (360 liters) an hour.

If I’m drinking I could conceivably drink it all; one mug every 10 seconds. But now, if my friend Joe comes with me, I’m obligated to share my beer with Joe. He gets one, I get one. Now, I only get a mug every 20 seconds. My bandwidth, the amount of beer I am receiving, was just cut in half. That’s a 50% reduction in consumption even though the tap speed didn’t change.

But I need at least four beers a minute so this situation is unacceptable. To get my bandwidth back, I could ask the bar to double the tap speed. If they pour a liter every five seconds, my bandwidth is restored and both Joe and I are drinking a liter every 10 seconds again (12 total per minute). Another way to get that same result would be to double the opening on the tapper – doubling what can be consumed (bandwidth).

But the problem is they usually can’t increase the tap speed or the tap size and I really need to get a minimum of four beers a minute. My only other option is to limit Joe to one beer a minute. Once I do that, my bandwidth meets my requirements. I’m drinking five liters a minute – one over my minimum – not quite what it was before, but adequate since I’d feel bad if Joe didn’t get any at all. Limiting Joe like this is called QoS (Quality of Service) and I’ll discuss that in a future article.

In summary, speed is a delivery rate; beer through the tap or bit through some media. Bandwidth is what’s available to be consumed.

In most cases you should choose more bandwidth over more speed.

Cheers!