What is IoT? That is not the question
Derek McAuley, IoTUK Privacy and Trust Principal Consultant, thinks it’s time to stop asking what is and is not The Internet of of Things, and that we should be focusing on its application instead.
I have many conversations with colleagues about what is and what is not ‘The Internet of Things’. These discussions along with many of the definitions that others have offered often focus on the technical capabilities of the system – does it have embedded computing; can it communicate; does it use the internet; does it have a screen; does it involve a “thing” that we previously had never thought to put online?
Some aim to partition even further by defining which things are not IoT:
- That’s not IoT, that’s a “connected product”
- That’s not IoT, that’s M2M
- That’s not IoT, that’s a smart phone
The list of things that some consider are not IoT could get very long and still provide us with no useful insight or handle for discussion.
As noted in a previous IoTUK post, people have been putting unexpected things online for years, and traditionally being considered weird for doing it – but that is the joy of research and innovation.
So for me, IoT is not about technical capabilities or novelty, rather it is a social phenomena that reflects a significant proportion of society, and importantly businesses, who have started to recognise that there is value in building a virtual presence for many of our everyday physical things. These connected ‘things’ are enabled by the continued reduction in cost of communications, computing, storage and sensing.
So shall we discard the consideration of technical capabilities when thinking about IoT? Absolutely not. In considering any system design, we need to understand how to trade off the technical complexity against the functional and commercial requirements.
We also need to consider the risks, such as privacy and safety, for example, alongside the requirements, or not, for data sharing. Those two latter topics will be the subjects of forthcoming blogs and finally a report from IoTUK, but for now we should consider the technical complexity alone.
At the most basic level we should continue to embrace even the simplest technologies that enable us to uniquely identify passive objects. RFID and NFC tags still have much value to add, while advancements in visual marker technologies such as d-touch allow designers to hide the equivalent of barcodes in decorative patterns. However, even such long established technologies present us with emergent issues due to the scale of deployment, such as the ‘clash of the plastic’. Who would have expected we’d be carrying multiple tags in such close proximity? Do a personal survey of your pockets and bags: contactless payment cards, building access tokens, loyalty cards, and smart phone etc.
One specific vision for the use of IoT is how it will help look after our ageing population and keep them living independently in their homes for longer. Technology will provide monitoring and assistance through devices that are both worn and carried, as well as embedded in homes.
Looking at the IoT landscape today, there has been a shift from simple vertical applications to a wider landscape of ecosystems built around various proprietary standards such as Apple’s HomeKit, Google’s “Works with Nest” and Samsung’s SmartThings. The downside to these proprietary architectures is that products and services are not compatible across vendors – not so much of a problem when the devices are all portable, but a challenge for IoT where elements of the systems will be embedded in the buildings around us. In the commercial deployment context this sort of technical complexity is a dream (= profit) for systems integrators, who will build and maintain bespoke software infrastructures to make it all interoperate.
However, returning to our care in the home application, the need is to reduce the technical complexity by ensuring systems are designed to interoperate. Hypercat has done a great job for enumerating things. Next, let’s standardise some of those APIs (Application Programme Interface) to “things”…I mean how many ways do we need to talk to a thermostat?