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.
| Reference: | Problems in the internet of things from our JCG partner Mike Mainguy at the mike.mainguy blog. |
