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
