But this shift raises a number of issues for effective validation and verification.
A key difference between devices designed for the IoT and classic embedded systems lies in the explosion of their possible use-cases. Traditionally, embedded systems were often designed to run in a standalone context or if they were networked would run in a small set of predefined contexts. Such designs could be supported by a relatively straightforward strategy of testing at the unit level, followed by testing the integration of those units and finally testing at the subsystem and system levels.
The IoT redefines the concept of 'system’. It brings with it the possibility of building much larger-scale, emergent systems in which interactions between independently designed devices on the network deliver the system functions. Incorrect functionality within one device can result in unpredictable behaviour at the system level, or may have little to no impact because other devices in the system can respond appropriately.
A number of IoT applications rely on the concept of sensor fusion in which readings from many different sources are combined to build what should be a more accurate picture of what is happening around them. Errant devices may inject noise or incorrect data into the network that causes other devices to respond inappropriately, resulting in the wrong outputs being generated.
Because IoT devices will be designed independently it is almost impossible for the device design team to test for specific problems caused by other systems. Even if some of those systems are available for test before product delivery, a fundamental tenet of the IoT is that new applications will be developed over time that may stress the device in unforeseen ways.
The problems of testing for the IoT raise issues of responsibility. Who is at fault if a single device starts emitting erroneous data that causes a gateway device to report non-existent events that destabilise the control loops used by other components of