For an appliance to comply with the Class B requirements, the control software must detect and handle the faults specified for the system components in Table 1. In addition to these tests and Fault detections, the software must be properly documented to pass a certification. This includes the program sequence, control and data flow, timing, Fault tree, and general design philosophy.
| Component | Component to Test | Typical Error Detected by Tests |
|---|---|---|
| 1 | CPU | - |
| 1.1 | Registers | Stuck at |
| 1.3 | Program counter | Stuck at |
| 2 | Interrupt handling and execution | No/too frequent interrupts |
| 3 | Clock | Wrong frequency |
| 4 | Memory(1) | - |
| 4.1 | Invariable memory | All single bit faults |
| 4.2 | Variable memory | DC Fault |
| 4.3 | Addressing | Stuck at |
| 5 | Internal data path(1) | - |
| 5.1 | Data | Stuck at |
| 5.2 | Addressing | Wrong address |
| 6 | External communication | - |
| 6.1 | Data | Too long Hamming distance |
| 6.3 | Timing | Wrong point in time |
| 7 | I/O peripherals | - |
| 7.1 | Digital I/O | Fault conditions specified in H.27.1(2) |
| 7.2.1 | A/D- and D/A-converter | Fault conditions specified in H.27.1(2) |
| 7.2.2 | Analog multiplexer | Wrong addressing |
| 9 | Custom chips (ASIC, GAL, Gate array, etc.) | Any output outside static and dynamic functional specifications |
Several of these tests are inevitably application dependent. As an example, for I/O peripherals it is required to do plausibility checking of the input/output signals. This, in turn, depends on both the application and its implementation. The firmware library supplied with this application note, therefore, cannot cover all of the requirements in Table 1.