A recent topic of conversation discussed whether there was a need for IoT devices to have sensors or not. Points were raised that many features were important. For example the ‘smart objects’ view is a less sensor-centric view, where the smart object can have sensors attached. What then are the features of IoT in general? After studying dozens of IoT labelled solutions, there were many common features that appeared again and again. It was decided to try to document them, in order to use them for useful purposes such as selecting the right features for proposed solutions, or to identify new or unusual features.
There are IoT solutions for consumer use, as well as those targeted for specific verticals such as retail or healthcare. The initial aim was to try to come up with a verticals-agnostic list of features. As a first step, what does an IoT solution look like?
Evolution of IoE
At a high level, an old (2005) example from an ITU exec summary (PDF) shows this diagram, which can be summarised as an "any time, anywhere, any thing" type of definition for IoT:
Shortly afterwards, Amazon Web Services (AWS) was launched, and IaaS (infrastructure-as-a-service) provided a convenient way to massively scale projects. With maturing XaaS (X as-a-service) options it became clear that IoT can make use of cloud services for more realisable solutions. IoE (Internet of Everything) treats IoT as one building block, and combines it with additional data sources (such as mapping, public databases, search engines) and uses this to provide higher quality information for decision making (i.e. a transformation from raw sensor data to more intelligence). It also connects people more closely to the IoT; using smartphones/tablets/wearables as an example. This allows for P2P (people-to-people) and P2M (people-to-machine) communication that too can scale massively. Analytics, ways to manage and monitor events or responses, databases and other middleware flesh out the architecture to make it work together.
Diagram source (PDF): http://www.cisco.com/web/about/ac79/docs/ps/motm/IoE-Smart-City_PoV.pdf
Example Implementations, Architectures and Features
The diagram below shows a real implementation example that was deployed in Nice, France (PDF source) It becomes easy to map the above diagram into the different features in this architecture.
There are many other typical solution block diagrams. A few more are shown here.
IoT:Smart Objects" by Giancarlo Fortino:
IoT building blocks – from a Freescale white paper (PDF):
This diagram from IBM shows how IoT is maturing into useful solutions, and the components that are needed to do this:
Bosch have a nice diagram where they flesh out people and processes:
Texas Instruments (TI) has an ‘IoT Readiness’ diagram, which lists some essentials:
From the above examples, the huge breadth of IoT and IoE features can clearly be seen.
Testing IoT Solutions
It is also interesting to know how to test at product and solution level and at scale. Testing individual devices can be complex enough, but how is a complete solution tested and how can it be guaranteed to work at scale? Some of the scale effort can be achieved through simulation, but real-life equipment tests in a large lab or real environment are also needed. The photo below (from "Adding value to WSN simulation using the IoT-LAB experimental platform" by Papadopoulos, Beaudaux, Gallais, Noel and Schreiner) shows a 240-node part of a 1024-node lab in France, owned by the University of Strasbourg. The nodes are based on TI MSP430 devices. Some nodes are also on the train track shown in the photo (this also helps explain the interest in quadcopters for IoT experimentation). Such a large-scale testbed can be repurposed for a variety of tests such as packet reception rate (PRR) and power consumption.
Such large-scale tests become practical because hardware costs are low, and it is far cheaper to test first than to suffer issues in a real-life deployment through lack of testing. Even for small firms and for individuals, scale tests are now practical; less than ten thousand dollars could allow real-world testing of perhaps a hundred test nodes, depending on the cost of each node and the test equipment used.
Even a 1024-node deployment could be considered small of course, compared to the eventual sizes of real-life deployments. Solutions with multiple millions of devices have already been deployed for real, for example smart meter projects.
Example Wireless Nodes
The information above concerns whole IoT/IoE solutions; the next question was, what do so-called smart objects, and devices like wireless sensor nodes look like, and what features are typically used? To see photos and to follow detailed designs, there are many recent Element14 Design Challenges projects, such as eLDERmon which uses nodes communication using the ISM band and IoT-Healthy based around TI MSP430 and CC2500 devices.
The photo below shows the eLDERmon solution by mcb1 :
Here is a node from the IoT-Healthy project by ravi_butani :
Here are some architectures; this is from" Design of a WSN Platform for Long-Term Environmental Monitoring for IoT Applications" by M. T. Lazarescu . It is based on an Atmel ATtiny device:
The diagram below from "Towards a Wireless Sensor Network Platform for the Internet of Things" by Kouche shows the logical topology inside a university project wireless node. It is based around an ARM Cortex-M3 processor. The expansion bus provides low-level interfaces such I2C and SPI for interfacing sensors and other hardware.
A General Features List for Wireless Nodes
The information from looking at multiple examples such as the ones above were translated into the diagram below, in an attempt to capture the typical features that may be encountered.
An IoT solution will use some of these. Some features may be missing, and all need to be fleshed out. The diagram may be representable in better ways. These points will be addressed in future posts.
Hopefully the diagram can evolve. Any comments or contributions would be appreciated.
This post examined the features that help make up IoT and IoE architectures; it looked at features in common with many proposed architectures and those deployed for real and university projects. It is hoped that the features list can be improved upon over time.