internet of things taxonomy - home - iotuk · this report proposes a taxonomy that can ... 5...

INTERNET OF THINGS TAXONOMY

DECEMBER 2016

Produced by

INTERNET OF THINGS TAXONOMY2

ContentsSummary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Technical complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

TABLE 1 – Technical complexity (TCom) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

When is a door not (just) a door? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Figure 1 – Illustration of increasing technological complexity of IoT

deployment involving a simple item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Level of safety, privacy and security (sensitivity) of an IoT system . . . . . . . . . . . . . . 6

Table 2 – System security level (SSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Figure 2 – Illustration of increasing system sensitivity of an IoT deployment . . . . .7

Degree of data sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Table 2 – Data Sharing Level (DSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Figure 3 – Illustration of increasing data sharing in an IoT deployment . . . . . . . . . 8

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Your views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

INTERNET OF THINGS TAXONOMY

When talking about the Internet of Things (IoT), and specific IoT projects, it is important to have a clear sense of the nature of each project in terms of their offering so

that meaningful comparisons can be made between projects, and to clearly differentiate between different types of application. This report proposes a taxonomy that can be used in describing and comparing IoT projects and invites participants in the IoT ecosystem to offer their comments on it, and participate in its development.

The IoT will be made up of an enormous range of different solutions, and will be used in an equally vast array of applications. These solutions will range from very simple devices that sense a single phenomenon (such as the temperature or the status of a switch) to highly complex devices (such as real-time video analysis devices or sophisticated control systems) that monitor several phenomena and perform complex calculations on the data they gather.

This taxonomy can provide a framework that allows IoT projects to be effectively compared and classified. The taxonomy will be useful in establishing a coherent record of the types of project that are currently in-flight and to provide a clear view of the extent and scale of IoT development in the UK. The taxonomy has the potential to provide a strong basis of data that can be used in supporting government initiatives to develop a UK-wide IoT strategy to promote innovation and development in support of UK businesses, and by potential investors and partners in assessing individual IoT projects.

3

Summary

INTERNET OF THINGS TAXONOMY 4

Introduction

There is no common way to describe or classify the ‘things’ that make up the IoT or the projects or systems and services based on them . To complicate matters, the range of projects and applications that the term IoT covers is vast . IoT applications could be made up of a simple sensor that reports whether a door is open or not (in the case of a simple security system) or whether a button has been pressed (in the case of a remote doorbell) to very sophisticated solutions that monitor dozens of phenomena, make complex calculations based on those phenomena, and then prompt a response (in the case of autonomous drones, for example) .

A means of classifying different IoT projects will be useful to properly understand the current state of IoT adoption, compare different IoT initiatives, and to inform decision making when it comes to policy development, and the definition research and market development initiatives .

To this end, Digital Catapult has started to define a taxonomy that will provide an effective way of classifying IoT initiatives . The taxonomy currently looks at IoT projects in terms of three key dimensions:

●● Technical complexityA measure of the technical sophistication of the solution

●● Safety, security, privacyA measure of the sensitivity of data collected by the IoT system

●● Data sharingA measure of the extent to which data is shared within the system, and beyond it

Technical complexity

IoT projects vary tremendously in terms of their technical sophistication . Digital Catapult has developed a scale based on technology complexity (TCom) that enables us to understand the state of IoT in the UK, and to assess what is currently being researched, trialled or deployed in real-life implementations . This dimension begins with the most simple solution (TCom 0) and ends with the most complex (TCom 7) .

A MEANS OF CLASSIFYING DIFFERENT IOT PROJECTS WILL BE USEFUL TO PROPERLY UNDERSTAND THE CURRENT STATE OF

IoT ADOPTION, COMPARE DIFFERENT IoT INITIATIVES AND INFORM DECISION MAKING


TCom Level

Description Examples

0 Dumb/passive objects . Not connected, identified or monitored

Any unconnected, unidentified object

1 Identifiable dumb/passive objects with a virtual existence that can meaningfully be counted/tracked by online systems

RFID Tags, barcoded or QR-coded objects

2 Connected objects . Objects linked to an IP network, with some means of reading, programming or controlling them . These should be counted as elements within the IoT universe, but they are often underused assets .

Printers, doorbells, IP connected fire alarms or security systems

3 Connected broadly homogeneous objects in a simple integrated system, whether the benefit of that system accrues to the end user or the system provider

Networks of multiple temperature sensors within a single building or campus . Environmental monitoring networks, wearable devices (such as Fitbit or other wellness technologies)

4 Connected heterogeneous objects in a single, integrated system . This involves taking data from a variety of sensors of different types, all deployed for the same end user or organisation to help improve processes, make better decisions or change outcomes .

The deployment of a range of sensors in a care home or hospital or the combination of parking, traffic volume and traffic control data in an urban road management system

5 Different objects deployed across multiple interconnected systems for multiple organisations, in multiple locations, all within a similar domain . System supports analysis of aggregated data derived from all deployment locations .

Partnering university campuses’ security cameras, fire alarms, temperature sensors, access control systems and energy monitoring systems integrated into a single unified control and monitoring solution

6 As for TCom 5, but where multiple domains are connected . This involves gathering data from a variety of sensor types, across a variety of systems and ecosystems, and creating combined views of the data that offer new sources of value (economic or social) or where there is a high degree of automation across homogeneous systems

Smart cities where multiple organisations, or different city departments and their partners, have built applications that draw on diverse sets of data from multiple sources to develop or improve services . Such applications might include the adjustment of street lighting in response to incoming data on night-time police activity levels, or the adjustment of traffic lights in response to real-time data sources about local environment data, or current people movement data based on mobile phone location data .

Or, in the second case, the automated adjustment of environmental controls across a service provider’s care estate based on real-time data feeds from sensors deployed in those settings .

7 As for TCom 6, but involving both multiple ecosystems and a high degree of automation

A smart city solution drawing data from multiple providers and sources, which is then used for automated traffic control and routing of emergency services, or the automated adjustment of traffic lights based on real-time mobile phone location data

TABLE 1 – Technical complexity (TCom)

WHEN IS A DOOR NOT (JUST) A DOOR? WHEN YOU CAN TELL IF IT’S AJAR (AND SHUT IT)

Figure 1 shows how a single object might fit into deployments at these different grades of technological sophistication; and how those varying levels of sophistication might enable users to gain better insights or make better decisions .

TCOM 0 Door

TCOM 1 Identifiable doorThe door is being made at factory X in Sweden, by company Y, using wood from source Z, and was at this stage in the supply chain

TCOM 2 Single door with networked alarm A door has been opened

TCOM 3One of many interconnected remotely controllable alarmed doors in building-wide alarm solution

Several doors have been opened - close and lock them all

TCOM 4

One of many devices (connected doors, fire alarms, cameras, temperature sensors, personnel tags) comprising a complete integrated building access and alarm solution

Cameras and temperature sensors confirm a fire in stock room . Open all fire doors and sound alarm

TCOM 5

Many doors and other devices within multiple interconnected building access and alarm solutions across multiple properties

Security door has been opened in campus building, and expensive equipment moved . Doors used and location tracking show the equipment has been hidden in building nearby . Route security to . . .

TCOM 6

Sophisticated emergency services solution taking building data (temperature, access control, people location) and external environment data (location of emergency services teams, skill sets of available people, people flows, traffic flows, weather, visibility data) to enable sophisticated emergency coordination decision-making

Fire in stock room near identified chemicals . Open all external fire doors . Seal stock room door . Use traffic system to route traffic away . Provide camera feed to emergency services . Request services of nearest qualified emergency personnel .

TCOM 7As TCom 6 but response actions all undertaken automatically (ie without human intervention or approval)

Fire in stock room near identified chemicals . All external fire doors automatically opened . Stock room door auto-sealed . Traffic control system automatically routes traffic away . Appropriate emergency personnel automatically contacted .

Figure 1 – Illustration of increasing technological complexity of IoT deployment involving a simple item


In addition to data security concerns, the security of the network itself must be considered . Where a device connects to a network, it is important to ensure that the device cannot be used either as a staging post for malicious software or to gain access to the network using another device . By targeting a poorly secured Wi-Fi connected home device such as a kettle, an attacker can access the network and hence most other devices on the system . The same is also true in enterprise or publicly operated IoT systems . Organisations deploying sensitive, highly automated, interconnected IoT systems need to consider security from the outset .

Many of the applications with the greatest potential to

improve lives and the way societies operate will come

near the top end of the scale because they will involve

automated personalisation and adaptation of things,

services and environments to meet individual needs;

or they will use data about individuals’ behaviour to

improve the way public or commercial services are

delivered .

Figure 2 (on the following page) illustrates how the

sensitivity of an IoT system could vary according to the

types of data generated and the degree of system

automation .

Level of safety, privacy and security (sensitivity) of an IoT system

A second characteristic of an IoT system concerns the inherent level of safety, privacy and security of that system . At

one end of the spectrum, an IoT system may not gather data that is sensitive either in terms of safety or privacy, while

at the other it may collect data about identifiable individuals or groups of individuals, involve financial transactions,

or access to system data or have the ability to control objects that could compromise health, safety or security .

Table 2 – System security level (SSL)

SSL Description Examples

0 No data involved, no control of the system

1 No sensitive data involved, no control of the objects in the system

Wireless doorbell

2 System provides anonymous, aggregated statistics, no control of the system

Remote temperature sensors

3 System generates sensitive data or supports some degree of remote control of the system objects

Biometric data, door actuation mechanisms

4 System generates sensitive data, supports some degree of remote control of the system objects and connects with external systems

Integrated facilities management systems, tele-health monitoring, security and safety systems


SSL 0 Car

SSL 1 Car with seat sensor Is anyone in the car?

SSL 2Car with camera; or car with sensor and control

Who is in the car? Or, if someone is in the car, turn on air conditioning

SSL 3 Car with camera and controlMonitor who is in the driving seat . Prevent engine from starting if the driver is too young or has no valid licence

SSL 4Car with camera, multiple sensors, controls, links to wider systems

Monitor the health of the car’s driver . Assume automatic control of the vehicle if the driver becomes ill or distracted; alter traffic lights and bring car to a safe stop .

Figure 2 – Illustration of increasing system sensitivity of an IoT deployment


Degree of data sharing

A third characteristic of IoT systems concerns the degree of sharing of sensitive data between the object and the system, and subsequently between the system and the system operator(s) or participants, and third parties .

Systems do not always need to share data, so IoT product, platform, service and system designers must be clear about when data is shared, what is shared and why .

Table 3 (on the following page) shows a five-point scale for classifying IoT solutions based on the degree of data sharing, the data sharing level (DSL) .

DSL Description Examples

0 No data is shared Simple point-to-point monitoring systems such as consumer weather stations and wireless doorbells

1 Basic sharing between two parties: agreed sharing of sensitive data between the customer/buyer/user and the seller or provider (whether that seller or provider operates in the commercial or public sector)

Cloud-based security systems, remote cameras, home monitoring systems

2 Third person sharing: sharing of sensitive data between the seller or provider and unrelated third parties in a commercial context .

Person tracking information to support targeted marketing offers

3 Multi-domain and third-party sharing: sharing of sensitive data between the customer/buyer/user and multiple sellers or providers involved in delivering services, where those providers come from different ecosystems (including the commercial and public sectors)

The aggregation of parking, traffic and environmental data in an urban traffic management application

4 Open access to sensitive data, including data generated through use of public finance or infrastructure

Integration of multiple security systems in a public safety context

Table 3 – Data Sharing Level (DSL)

Figure 3 – How the degree of data sharing can influence the complexity of deploying an IoT solution

DSL 0Pressure sensor (no sensitive data collected or shared

How many people pass this point daily?

DSL 1Sharing of sensitive data between passenger and rail operator

Is this passenger on the correct platform to catch their train? Had a particular passenger left the train before the incident occurred?

DSL 2Sharing sensitive data between rail operator and a third party vendor such as a franchised coffee shop

Which individual travellers are passing that the third party could target with tailored offers?

DSL 3

Sharing sensitive data with an organisation in a totally different ecosystem – e .g . emergency services or unrelated retailer (e .g . car company)

Who is using this station, and where are they?

DSL 4Openly sharing sensitive data about station use

For creation of new public services


The degree of data sharing is important because it has

implications for privacy and trust (who owns the data,

who can access it and who can use it), and implications

for operational complexity . For instance, where data is

to be shared between corporate entities, the challenge

is to come up with commercial terms all parties can

agree to . However, where public sector organisations are involved, there will likely be complex and inflexible rules and processes that will determine what can or cannot be shared, and how it can be shared .

The involvement of participants from multiple ecosystems has the potential to dramatically


increase the operational complexity associated with accessing, using or further sharing of the data gained from IoT deployments . Projects requiring the sharing of data between large corporate organisations, multiple public administrations, defence or health organisations will often mean a requirement to navigate, comply with or negotiate, complex financing, procurement, legal, IP-related, data protection, privacy and security rules . These can become potentially insurmountable barriers to IoT solution development and deployment – especially by small innovator organisations .

Conclusion

The ability to classify and categorise different IoT deployments makes it easier to compare different applications, benchmark the overall maturity of the IoT ecosystem in the UK to compare it with other regions, and track the effectiveness of government supported initiatives aimed at promoting British innovation . The classification model also provides guidance to the developers of IoT systems, ensuring that they consider key factors such as data security and privacy and the way in which the data they gather might be put to good use by a broader set of organisations across different domains .

A key success factor for the UK’s IoT industry is the ability to enable many more British businesses and organisations to realise the benefits of the IoT and to establish it as a globally competitive force in the wider market . Organisations like IoT UK have an important role to play in promoting and supporting the development of the UK’s IoT capability, by helping to create models such as the one proposed in this document, and by supporting and advising UK based innovators as they develop solutions and bring them to market .

Your views

The goal of this taxonomy is to provide those who are developing IoT solutions, and those who may be investing in or adopting them, with a useful framework for the comparison, evaluation, and benchmarking of IoT projects and services . This should enable more focused discussions about what needs to be done to facilitate the development of the UK’s IoT ecosystem, and about how to remove the many practical barriers that currently inhibit development .

If you have any feedback on the ideas in this paper, please contact us on info@iotuk .org .uk .

Digital Catapult, 101 Euston Road, London, NW1 2RA

IoTUK .org .uk • info@IoTUK .org .uk

Produced by

INTERNET OF THINGS

internet of things taxonomy - home - iotuk · this report proposes a taxonomy that can ... 5...

Documents