Building IoT at scale pt 2: A model for IoT

Building IoT at scale pt 2: A model for IoT

Key takeaways

1  Things that matter are intelligent enough to interact with the network – RFID tags for example don’t really count as ‘things’ any more than a printed bar code does

2  Real IoT solutions are delivered by a network of gateways that connect and interact as needed; Internet protocols already exist to make that simple

3  M2M does not equal IoT – they’re often conflated, but it’s only one part of the solution

4  There are multiple suppliers emerging round single layers of the model, but many have limited value and it’s clear that creating scalable end-to-end solutions requires fairly deep integration skills

5  All the competing standards that are emerging are something of a distraction; most will have little impact on the larger players who already have (or are establishing) their own standards in place

6  Data standards are vital for open integration but that won’t matter much in most IoT solutions because they will only share data in pre-planned ways

7  Security could be a problem with so many different standards, but again, most IoT solutions will be built for specific requirements with clear parameters, implementing whatever level of security they need

8  The current thinking about Smart Cities requires multiple players to be able to integrate data and security on several levels, and for those players to cooperate smoothly, which often runs counter to their interests.  It may lead to quite different models for Smart Cities than are currently envisaged.

PS I’m not going to go into a lot of technical detail because a) that’s not the audience for this blog, and b) it could take up a whole book.

 

A model for IoT which helps explain a lot

This is the IoT model which Gary Barnett and I defined in early 2012.  It can be used to map IoT products and service provider positioning, and to understand markets; few suppliers offer end-to-end solutions, which is why we had to build the solution for AirSensa ourselves. It also provides a framework for understanding why IoT is not developing as envisioned – primarily because of the different interests of major players.

Why is a model important?  It’s a useful way to hammer out what something really means, and provides a framework for testing those assumptions.  When that’s done, it can help everyone understand and communicate about technologies and marketplaces, particularly in a ‘new’ field in which there is confusion over standards, definitions, and vendor claims, and a conflation of many different things under a single banner.

The model is pretty self-explanatory and is open to you to make of it what you will, but here are a few points that are worth making:

I know I mentioned this in my last post, but it’s important: ’Things’ should be intelligent actors in an IoT system.  Unless something is intelligent enough to do something interesting – such as modify it’s behaviour depending on circumstances (or be instructed to) – then it’s not interesting.  An RFID tag is not a thing.  The reader most probably is though as it has to do things like decide actions based on context, and communicate data, and listen to new instructions.  That’s one way of saying that the higher estimations of ‘numbers of things connected to the Internet by 2020’ are mostly just quoting huge figures to get the media excited.

The Internet is a well understood transmission model with clear de facto standards (TCP/IP, http, etc.).  Use those (and other related de facto standards) and many things become simpler.

The gateway/data/API part of the model will often be iterated multiple times in a solution, particularly where multiple different outcomes are needed from a single event.  So real-time performance data from a car will be communicated to its manufacturer, and perhaps to major component suppliers, and to your local garage, insurers, even breakdown services.  Data will be required in different formats for different users (because they usually have their own standards); that will be accomplished through whatever gateways and APIs are defined by whoever controls the model (the manufacturer probably).

Security shouldn’t be a problem in this regard, as solution are built for specific requirements and with specific parameters that must be followed.  The reason that security can become a problem (and has been in the ‘hacked car’ examples) is that one or more players have decided to trade off simplicity for security and ignored accepted methods.  Security is not hard if a proper end-to-end view is taken from the outset.

While we’re on it, the ‘six steps from hacking a wifi-enabled kettle to emptying a bank account’ example can only happen because the kettle manufacturer doesn’t want users to have to do anything onerous like having to enter wifi passwords before it works, because the cost of first-line support for everyone screwing it up would probably exceed profits.  Hence they use a zero-security link to your home wifi router, leaving you open to hacking.  The Internet of Things is not insecure by nature – it’s easy to build secure solutions.  It’s just that people sometimes won’t because it’s not in their interest to do so.

IoT isn’t a centralised or a decentralised thing; processing and data storage should be located where it’s needed.  Use the term ‘fog computing’ if you will (where the cloud meets the physical world), but it just means being sensible about where you put functionality.  For example, in the AirSensa model, the sensor units do quite a lot of simple processing locally (like linear regression calculations) mainly to minimise communication traffic.  But it doesn’t do anything more processor-intensive (such as continuous calibration) because that’s much better and simpler to locate on the platform.

And finally, almost any supplier of IoT solutions (or part of a solution) will tend to see IoT as a problem of ‘x’, where ‘x’ is what they do.  Mobile network companies see it largely as a comms issue; equipment manufacturers as about the ‘things’, and a growing number of companies and initiatives as about aggregation on a ‘data platform’, or more likely an ‘open data platform’.  More about open data in another post, but the point is that they each only do a part of the solution.  Integrating them into a scalable and sustainable IoT solution requires understanding of all the technologies, the data and its likely uses, customers demands, physical world challenges, the competitive environment, and so on.  If you’re working in a Smart City context, (or even just environmental sensing) you can add political interests, funding bias, data provenance, and quality issues, etc. which is why I said that systems integrators would do well for the foreseeable future.

Not to sound negative, because there’s some great work going on.  But there are also many, many initiatives which will never get out of their sandbox.  Not because of security concerns or the technical challenges of their own solution, but because they are attempting something with too many moving parts, or which will fall foul of non-technical bear-traps – entrenched approaches, politics, marketplace features, and the competing and non-aligned interests of existing players.

The next post will probably be about why we started this project and why we set our project objectives the way we did.  I said that last time, but too many people asked questions about the model.  We’ll see whether more feedback arrives…