Problems in the “Internet of Things”

Having worked with connected vehicles for a number of years now, there are some things that it seems newcomers always “get wrong”. Having worked through the “plain ‘ol Internet” (POI) boom, I see parallels between the mistakes made during that period and similar mistakes in the current ongoing boom. I’ll outline the biggest few:<,/p>

Failing to recognize mobility

In the POI, people used a client/server paradigm to design applications for the web. Additionally, the protocol generally chosen was one designed for document management, not application connectivity and it too almost a decade before general purpose alternatives arose that were better suited for the types of interactions desired. Moreover the general interactive design tended to try and replicate a desktop experience instead of design for the new platform. The problem here is that the device “might not be where you think it is” or it may have even “fallen off the network”. Without good tracking of these events, diagnosing problems with devices is a nightmare (is my Chevy land in the levy, or is the battery just dead?).

Failing to design for a headless device

` In the POI, folks failed to account for the fact that the client and the server were connected with a somewhat unreliable network with varying latency. This was remedied (after years of pain) by giving a user feedback and perhaps give them advice (hit refresh, if that doesn’t work call 1888-hit-it-again)… With headless devices, there is no “refresh button”. Often clever engineers will put logic in for retrying, but in my observation they forget about the fact that without giving data to a user of management service (or building updatable AI into the device for managing connectivity), the rules are often too primitive or brute force to be effective. A great one I’ve seen a number of times is a progressive fallback retry strategy that ends up with the device wait so long (or going offline) that it’s nearly impossible to account for losses.

Failing to manage embedded problems

In the original “mainframe” days, resources were fairly well managed as they were scarce and/or expensive, as we transitioned to the POI days, the equation on the costs of these things changed dramatically (memory became cheap, client storage disappeared [for a while], power was ubiquitous and distributed. In the IOT, power can become scarce and must be carefully managed (new problem [yes I know embedded folks ‘get it’], memory is a decision that can be balanced, as can storage. There are, however a multitude of other “embedded system” problems that are now being introduced to a larger group of engineers. Historically there hasn’t been a large overlap between people who deal with network protocols, backend systems, and embedded devices in uncontrolled environments. There are many systems that have “parts” of those problems, but not very many where ALL of them now must be solved for. i.e. perhaps a warehouse management system works with embedded devices talking to backends, but it’s NOT mobile, and it’s generally a controlled environment.

Security

This is the big hairy and scary gorilla in the room. At the inception of the POI, security was a very secondary concern because historically it was handled in the server room and by tightly controlling the desktop. The POI opened this up such that the client was inherently insecure and observable. This led to many mistakes by folks who were used to being able to control both sides of the equation and not realizing that this mental model is dangerous in a highly distributed world. In the IOT world, the bigger problem is that our ways of thinking about security don’t account necessarily for the fact that when devices are moving about, they encounter many network situations that just don’t happen with a web browser or mobile phone. Depending on what sorts of sensors and capabilities the devices are designed for, the number of ways that things can go wrong is multiplied many times over (versus the relatively simple problems with the POI).

This is just a short list, but hopefully gives pause to folks designing connected devices to “think about the things they might be thinking about incorrectly” when designing IOT solutions.