2 Class B Requirements
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 2-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 |
- These are essentially the same for AVRs since SRAM, Flash, and EEPROM are all internal.
- This table lists various external components and indicates whether a short and/or open Fault must be detected.
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 2-1.