Last week you learned about what exactly a module is, and examples of different types of modules. Now we will move on to interfaces, the need for module testing, and code coverage requirements.

An interface, such as the 3D printer’s communication interface, or the format of the 3D data it can render, serves several purposes. It provides the contract between two entities: a provider and a consumer. In software, these two entities are generally a calling function and a called function. As long as both entities comply with the interface specification, the cooperative effort between them works correctly. Modules have internal and external interfaces. An internal interface is an interface which is only used by the module itself. An external interface is “exposed” to other modules.

A module, like one in the 3D printer example, provides one or more external interfaces to allow a client to use the module to perform work on its behalf. Software modules do more than just provide interfaces. They contain the logic, sometimes complex logic, to actually get the job done. This logic may or may not contain systematic errors -- design and implementation errors: thus, the need for module testing. Module testing is based on the specification of the interface and the function of the module, and provides the means to show that the module does not contain systematic errors.

A module test has three goals:

1. Test the primary (“happy path”) function(s) of the module
2. Test that all secondary (“error paths”) logic works as expected
3. Test that no unintended side effects occur

The second goal has to do with code coverage requirements and includes testing of error detection and the associated actions (error annunciation, error remediation, retries, etc.). Depending on the target SIL capability of the software under test, IEC 61508 code coverage may mean:

• 100% entry point coverage (SIL 1)
• 100% statement coverage (SIL 2)
• 100% branch coverage(SIL 3)
• 100% condition coverage (MC/DC) (SIL 4)

The IEC 61508 requires that each module is verified according to the “module test specification.” The module test specification (or module test plan) describes the test cases to be successfully executed in order to show that the module performs its “intended functions” properly (and does not do anything unexpected). Check back next week for more on the test plan.