What is it? The words “Internet of Things”, far from designating some well-defined concept, are used to cover quite a lot of different areas, going from devices and ideas which can be implemented today (“Home Automation: The Next Generation” or “Improvements in logistics using machine-readable tags”) to elements that are still quite a bit in the future and that are in dire need of serious research and thought (“Swarms of communicating robots”).

The devices presented and discussed at the recent IoT World 2015    trade fair were still rather mundane, but you may expect advanced robots in various shapes, forms and sizes to become real-world capable and affordable during the next decade.

Let us collect the concepts into a medium-sized mindmap:

The above covers a gamut of ideas, going from the medical and personal to the industrial and governmental. Various instantiations of the “things” are listed: from “stuff” tagged with passive RFID markers to intelligent, mobile devices able to sense, compute and react, a new iteration of the robot associate. In effect, these are “mobile devices, robots, machines and automatons”. To be of any use, most of these devices need to communicate, but not necessarily all the time, not necessarily using a derivative of the Internet Protocol, and not necessarily via the Internet. Indeed, devices that communicate intermittently over mesh radio networks using protocols yet to be developed will most certainly be found in the “Internet of Things” concept cloud.

In “Building the Web of Things”[1] Dominique Guinard and Vlad Trifa give the following definition:

“The Internet of Things is a system of physical objects that can be discovered, monitored, controlled or interacted with by electronic devices which communicate over various networking interfaces, and eventually can be connected to the wider Internet”

This definition approaches the set of ideas given in the diagram.

Major Roadblocks

Problems of various kinds are found on the road to the higher reaches of the Internet of Things: Not least of which is that the sheer number of devices one expects to release into the environment demands that approaches to security, maintainability and safety, and thus today’s approaches to coding, testing and general development processes need a revision. In many cases, one would like to reach safety and quality assurance levels that can only be found in the most demanding projects of today – and this routinely. How the more complex ensembles of these devices will interact with each other (especially if they come from different manufacturers) and what as-yet-undreamt-of problems they will cause when interacting with the world around them, in particular the humans still needs to be fleshed out.

Long-term serviceability of these connected devices will be of extreme importance: Not updating the software of the hundreds of devices in your home or thousands of devices in your company may well mean crossing over into the territory of physical danger: these devices won’t be solely PCs with no way of reaching out (except by exposing your on-disk files to the wider Internet) – they are meant to effect actual physical operations. They could well be invisible – integrated in everyday objects – and they could fail in interesting ways. That is quite undesirable in devices that may lock you out of your home, spoil your refrigerator contents, manage the production of your favorite canned goods, or control medical devices (wearable or otherwise) that you need to depend on (“Never Mind Pearl Harbor – What about a Cyber Love Canal” Sean W. Smith, John S. Erickson, IEEE Security & Privacy, Mar.-Apr. 2015). The never-ending string of security (and non-security) problems in the current massive bases of off-the-shelf embedded software – in particular in the hard-to-update SOHO routers found in connected homes and offices which can become nests of mlware infestations – shows that there is still some way to go in delivering reliable, manageable software to the masses.

Regulatory pressure and litigation will more likely than not change the “black box” Intellectual Property approach to software components so prevalent in today’s industry: the order of the day will be “either keep maintaining your software or open-source it” (“Inviting More Heartbleed”, Daniel E. Geer, In-Q-Tel IEEE Security & Privacy, July-Aug. 2014). Abandoned, unmaintained software that is still in active use may become a toxic liability. When open-sourced, it can at least be inspected and possibly fixed. Indeed, companies ready to offer software that can be tested by third parties in a white-box manner (i.e. by looking at the program text) may well get the upper hand in the marketplace.

Opening up the Device Stack

If you are interested in the engineering aspects of the device you have in front of you, you realize the complexity of the hierarchy of functionality, from the stack of crystal material cunningly formed into a transistor at the lowest level to the possibly several tens of thousands of lines of high-level code of the application running at the farthest top of the computation-capable structure that forms the Smartphone, Robot or Home Automation device in front of you.

However, for the Internet of Things, looking at the device alone is insufficient: we need to also look at how the device will interact with other devices and with the Internet at large, how it will behave over its lifetime of being embedded in this sometimes hostile “communicative environment”. But even that is not enough: We need to go further and see how the device and its communication network interacts with the people and the physical environment around it: it must act meaningfully, safely, reliably, with not many surprises and shut down properly once its lifetime has exceeded. Only by adding the quality aspects / lifecycle aspects to the equation do we get to see an Internet of Things that is “fit for purpose”.

 

The above suggest that testing will be an all pervasive activity for the overall system of the IoT. It seems that the problems of system testing and integration testing are bound to jump by several orders of magnitude.

Formerly, one could perform system tests while having some assurance about the environment the system would be deployed in. This won’t be the case here.

Today, more than even, it’s necessary to be an active player in setting up the quality assurance programs that the Internet of Things, even in the primitive form of today, requires: a massive amount of testing, made effective by out-of-the-box thinking and exploration of border cases and limitations is needed. Test automation is a necessary prerequisite as only machine agents can generated and run the tests required, some of which basically are random explorations of the state space.

By David Tonhofer, Senior QA Engineer at q-leap.