There’s a cycle in technology where people figure out that you can make money out of something and so everyone jumps on the bandwagon. You know .com, e-commerce (in fact e-everything), SaaS (and its forerunner ASP), the Cloud, Big Data… Though the bandwagons come and go, some practical technologies usually emerge as successful and viable and remain long after the bandwagon has disappeared out of sight. Currently one of those bandwagons is IoT (the Internet of Things).
The IoT is a strange umbrella term (not a standard of any form) which I’ll boil down to the general idea of taking various devices and making them “accessible” (readable, controllable) over the Internet. What sort of devices? Well in most cases they’re things we know and “love”, but I suspect some of the most interesting may be things that we’ll see wouldn’t even make sense without Internet connectivity. Here are some we’re seeing appear on the market right now:
- Utility (Electricity, Gas, Oil, Water) Smart Meters
- Smart Heating and Lighting controls
- Home appliances: Kettles, Washing Machines, Fridges…
- Crop monitoring
And on the brand new side:
- Product ordering buttons (e.g. Amazon Dash Buttons)
What links all of these things though is:
- An on board controller with networking
- A short distance network
- An optional local “hub” device, either intelligent or just to bridge networks
- A long(er) distance network
- Control software
- User Interface software
You can’t control the network so you need to make your IoT system network-tolerant
The Networks themselves are the Big Risk
Now, a wise man once said to me: “You know, compared even to Mobile apps the IoT has an even bigger problem: It just has to work; It can’t be popping up error messages for users to respond to: there’s no one there to respond”. And yet the quality of the network poses a major risk, as once again the networks (private, wifi, 3G/4G, Internet) in use will pose big challenges: at times being slow, overloaded, affected by the weather, affected by landscape, building structures and more.
Take a quick look at the diagram above and you can see that the developers can control the software and hardware aspects by choosing/developing appropriate technology, but they have no control of the network. So, basically they have to build and design hardware and software which is network-tolerant, rather than assume that the network will be good.
In the non-IoT world some vendors have got the hang of this, for example:
- Skype will pop up the message: “There is a problem with the network, we’ll try to get the call back for you”
The secret is they’re not asking you to press any buttons, they’re going to retry the operation, reset themselves, whatever they have to do.
Contrast that with the norm:
- The spinning wheel of nervousness
- Nasty popups with meaningless error messages, which when you click OK, exit the app!
The IoT needs to take that Skype-like (we’ll fix it automatically if we can) approach because there’s no one there to click OK. Errors need to be logged in the background and uploaded when the network returns, like motor vehicle diagnostics, only much better!
The issues of Perfect Development Networks
The problem is that when the developers and testers build the solution in their nice “lab” environment they don’t experience these “real” network problems and tend to concentrate on the functionality.
The devices might get an outing in the real world when they produce prototypes for people to try, but there will be a limited number of these and so if for example the probability of a network error is 1/10,000 you’ll almost certainly not encounter it during this kind of testing.
So it’ll then be up to us, the consumer, to perform the “real testing” and that’s going to inevitably lead to failures and one star reviews, which will really affect the product’s reputation:
- OK in the Office but Rubbish Outside!
- Keeps Freezing Up!
- So Slow! Don’t waste your time with this app!
- Doesn’t Even Deserve 1 Star!
Think it can’t happen, or doesn’t matter, just take a look at what happened when the Google Nest heating controls “bricked” during an automated software update https://www.nytimes.com/2016/01/14/fashion/nest-thermostat-glitch-battery-dies-software-freeze.html?_r=0. Users were concerned that they’d have burst pipes as the heating shut down. Google pulled the plug (pardon the pun!) in April 2016. While you can’t legislate for a network cutting out at the wrong moment, you need to make your software “Do the right thing” if you are going to make a business out of it.
The need for Bad Networks in Development and Test
We need to change the probability of the network failures from 1/10,000 to 1/10 or less on demand, and make that available to the developers and testers so they can build and test their automated recovery strategies. How?
Well, we’ve being doing this for years with our NE-ONE and INE Network emulators. Developers have used our Network Emulators to improve both their mobile apps and other network dependant software to the point where they could recover most conditions without user intervention, or in the case of apps like Skype recognise the condition and retry on the user’s behalf.
The IoT bandwagon is new, but it’s reliance on the network is absolute, even more than Mobile (hand-held) technology. It is, after all, “The Internet of Things”. So developing & testing in realistically bad networks is mandatory and the good news is that virtual test network technology that enables you to create “bad networks” on demand is readily available.