Part 3 covered the design of tests, resulting in one or more Module Test Plans.  To execute a test plan, one would start with the test plan and a test results template (which could be a copy of the test plan as indicated previously), document the general test information specific to the test execution (version numbers, dates, name of the tester, etc.), set the test up according to plan, run the test according to plan, and record the test results (generally the actual outputs and a pass/fail indication).

The design of the software can have a significant effect on the complexity of module testing.  Code that is highly modularized with low coupling to other modules yields much simpler module tests.  Global data accessed by multiple modules can increase complexity (through increased coupling).  Directly accessing hardware registers from code, rather than encapsulating register access in dedicated functions, can significantly increase module test complexity.  The design of functions to the “one function/one responsibility” rule can simplify module testing.  Bundling multiple responsibilities into a single function complicates both the module test and the function itself.  Simplifying a function also causes the function’s code to be more readable and easier to maintain.  The cost is more functions, and more module tests, however, by creating several simple functions from one complex function, overall effort can be significantly reduced, while increasing quality.

The IEC 61508 module test requirements can be relaxed for specific modules through the use of Software Criticality Analysis.  Software Criticality Analysis defines three classes of safety criticality:  safety critical (directly affects the safety function), safety related (and non-interfering: cannot affect the safety function of the device).  By proving that a module is not safety critical, but is instead safety related, the module tests for that module need only comply with SIL N- 1 requirements, where N is the target SIL capability of the device.  If a module can be shown to be non-interfering, then the requirements can be relaxed completely (no module test is required by the IEC 61508).  Relaxing these requirements can save time, but keep in mind that the quality improvements that module testing ensure are important, even in non-safety devices.

There are commercial tools that can simplify module testing, depending on your environment and requirements.  They may provide debugging capabilities, code coverage reporting, assertion functionality, and other useful features to help you test.

I hope that you have learned just a little bit more about IEC 61508 requirements for Compliant Module Testing in this 4-part series.