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?

Because many of the devices will often be practically inaccessible, the "patch and pray" strategy used for many desktop software packages is unlikely to be an effective strategy for many forms of IoT device. They will need to be shown to be secure against a wide range of attacks. Patching can only be used for extreme situations where certain types of hack were unforeseeable at the time of design.

Because of the factors outlined above, there is a strong requirement for the firmware inside IoT devices to demonstrate trustworthiness. This has led, in the UK, to the release of a standard designed to improve the ability of software to avoid failures and resist attacks. The Trustworthy Software Initiative has backed the British Standards Institute's PAS 754:2014 standard, which identifies five aspects of software trustworthiness: safety, reliability, availability, resilience and security.

The BSI document describes a widely applicable approach to achieving software trustworthiness rather than mandating any specific practices or procedures. The standard calls for an appropriate set of governance and management measures to be set up before producing or using any software which has a trustworthiness requirement.

Under the regime, design teams need to perform risk assessments that consider the set of assets to be protected, the nature of the adversities that may be faced and the way in which the software may be susceptible to such adversities. To manage that risk, appropriate personnel, physical, procedural and technical controls need to be deployed. Finally, PAS 754 demands a regime be set up to ensure that creators and users of software ensure that governance, risk and control decisions have been implemented.

Where devices are likely to be incorporated into systems that have a safety aspect, certification to one of the relevant standards will be needed. This may be a generic standard such as IEC61508 or a domain-specific standard derived from it such as ISO 26262 that has been embraced by many of the automotive OEMs.

A key element of the safety standards is the appropriate selection of a safety integrity level (SIL) to act as a guide for the degree to which functionality needs to be tested during design, during production and in the field, as built-in self-test mechanisms may be needed to ensure the device is fit for purpose. For example, a sensor node may include software to check its inputs are within bounds and not indicating a failure caused by too much dirt or a lost connection.

SILs differ slightly according to the relevant standard but follow a similar structure. In ISO 26262, for example, the automotive SIL (ASIL) ratings cover the four letters A to D, as well as QM for no safety impact. ASIL A is for systems that have little safety impact up to D for the most critical functions, such as brakes and steering. In IEC 61508, the SILs are numbered but cover similar grading of criticality.

The SIL determines the level to which each system needs to be tested. But to ensure that external problems cannot upset the more safety-critical systems, the engineering team has to go through a process of determining what could possibly affect the system they are designing, including events from external equipment.

This calls for functions that check inputs as well as outputs for problems so that errant data does not cause the system to react unpredictably. An overarching test strategy needs to support those higher-level tests as well as the unit tests that will usually be performed during function creation and integration.

Although the additional level of testing required for IoT may seem to be a burden that is difficult to support, research into software costs has shown that this attention to detail can pay off commercially. In a seminal paper published in IEEE Computer in 2001, Barry Boehm and Victor Basili of the University of Southern California and the University of Maryland, respectively, found that it costs 50 per cent more per source instruction to develop high-dependability software products than to develop low-dependability software products.

But, using the Cocomo II maintenance model, they found low-dependability software costs about 50 per cent per instruction more to maintain than to develop. High-dependability software on the other hand costs 15 per cent less to maintain than to develop. Making IoT systems more resistant to problematic external code and events C and thus avoiding inconvenient reflashing of the device C is likely lead to much lower maintenance costs than for systems where those precautions have not been taken.

The IoT will do much to increase the level of automated intelligence around us. It will also, because of this, change the way embedded systems developers handle validation and verification.

About the authors
Mike Bartley is Founder and CEO of Test and Verification Solutions Ltd.

Declan O'Riordan is Head of Security Testing at Test and Verification Solutions Ltd..

?First Page?Previous Page 1???2

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