Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > T&M

Realigning test strategies for Internet of Things

Posted: 15 Dec 2014 ?? ?Print Version ?Bookmark and Share

Keywords:Internet of Things? safety integrity level? ASIL? SIL? IoT?

The Internet of Things (IoT) paves the way for more flexible and responsive control systems in which devices from many different vendors are brought together to deliver more functionality than is possible with traditional, stand-alone embedded systems.

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 stand-alone 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 sub-system 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 the system, causing a failure that leads to an accident?

Is it the vendor of the faulty device, is it the developer of the gateway for failing to filter the bad data or the controllers for being unable to cope with extraneous events? A large number of IoT systems will also need to be able to cope with user-written software. Those used in home automation, for example, may be controlled by a combination of downloadable apps and user-written or customised scripts. Errors in these may, if not guarded against, could cause IoT nodes to behave unpredictably.

Developers of IoT devices not only need to consider the stability of their design when used in a networked context but their vulnerability. When things become financially important, they will become enticing targets to hackers.

Even those without a direct financial benefit for successful attackers, some devices may provide an avenue for hackers to gain personal data that can be used for phishing attempts or simply be attractive targets for digital vandalism. In the wake of security disclosures about an internet-enabled thermostat, showing how it was possible to load a web page showing the password it required, some users reported their devices misbehaving. In one case, a home user woke up in the early morning to find theirs had been set to 35C.

In the world of personal computers and servers, the idea of regularly patching the software to counter types of attacks as they become known has become entrenched. But devices that do not have any form of high-bandwidth connection to the internet or which cannot suffer the downtime associated with a firmware update and reboot cannot realistically be treated the same way.

An IoT device may have no high-bandwidth connection to load new software other than a custom connector inside the package that was used during factory configuration, and after commissioning in the field may be installed out of easy reach.

1???2?Next Page?Last Page

Article Comments - Realigning test strategies for Inter...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top