Appropriate Tests for Software Classes
Parts of the standards apply to electronic controls and controls using software, and therefore—as is typically the case in modern appliances—the use of microcontrollers (MCUs). At the outset of development, designers must then consider which hardware and software features the MCU will require in order to comply with the requirements of IEC 60730 and UL 1998.
Software-related controls are classified as follows:
- Class A—Control functions not intended to be relied upon for the safety of the equipment.
- Class B—Control functions intended to prevent unsafe operation of the controlled equipment (e.g., thermal cut-outs and door locks for laundry equipment).
- Class C—Control functions intended to prevent special hazards, such as explosion of the controlled equipment.
Class B applies to the majority of home appliances, including clothes washers and dryers, dishwashers, refrigerators, and cookers. Class C applies to products such as gas-fired boilers.
The specifications require that controls with functions related to software class B or C should use measures to avoid and control software-related faults or errors in safety-related data and safety-related segments of the software. This requirement essentially means that the software and/or hardware must employ diagnostic methods to detect faults internally and externally to the MCU.
UL 1998 defines only two classes of software, but the implications are similar to those of the other specification:
- Software Class 1—Sections of software intended to control function to reduce the likelihood of a risk associated with equipment (such as thermal cut-outs and door locks for laundry).
- Software Class 2—Sections of software intended to control functions to reduce the likelihood of special risks (e.g., explosion) associated with equipment such as automatic burner controls and thermal cut-outs for closed water heater systems (unvented).
The UL specification also requires controls with functions related to software class B or C to use certain measures to avoid and control software-related faults or errors in safety-related data and safety-related segments of the software. As with the IEC specification, the software and/or hardware must employ diagnostic methods to detect faults internally and externally to the MCU.
Annex H table H.11.12.7 of the IEC 60730 specification defines the elements of the MCU that must be monitored and tested, the type of faults to be detected and recommends tests to be performed. For class B controllers, the elements of the controller that must be monitored and tested are defined in the same table.
Self-Test Library
Figure 1. Self-Test Library
|
|
By consulting with a variety of appliance manufacturers and standards authorities, NEC Electronics has developed a self-test library (STL) for its MCUs to be used to meet parts of the requirements of a class B control function as defined by the IEC 60730 standard. For example, the STL provides application program interface (API) calls that can be used at system start-up and/or periodically as the application requires (see Figure 1).
Annex H table H.11.12.7
|
|
The STL consists of a number of C function types with underlying assembler routines optimized for speed and minimal memory usage. Each function performs specific system tests and returns the result or an error status. For the best possible test coverage, users must call each function in defined time intervals, verify its return value and take appropriate action if an error is detected.
For example, one such STL function is:
unsigned char comp_bread(COMPBYTE *addr)
This function reads the data value from the specified address and verifies it with its complement. If a mismatch is detected, a dedicated error function is called. The error handler may decide to move the system into a fail-safe mode, or it may return without further action. This function can then be used to test internal memory.
There are also more-complex functions that can be used to correct bit errors in stored data. One such example is using error correction techniques:
ECCWORD *ecc_wwrite(ECCWORD *addr, unsigned int data)
The ECC-read functions read the data value from the specified address and detect or correct any possible errors. If an error is corrected, then the corrected data are written back to the memory unless the user disables the write-back function.
Timing
The IEC 60730 standard requires that a means be provided for monitoring any timing-related software or tasks. To this end, the system hardware must provide at least two independent clock sources (e.g., crystal/ceramic oscillator and line frequency) to provide the means for frequency monitoring or independent time-slot monitoring as defined in the standard.
The specification requires that a clock test be performed, meaning that the system clock is compared with some known frequency or interval. Candidates for such comparison are the line supply frequency or a real-time clock (RTC). The requirement for crystal oscillators is that only harmonics and subharmonics have to be tested. This relaxes the precision requirement to a factor of two. Such precision may be achieved with a simple ring oscillator or even with an RC oscillator.
Charging and discharging a capacitor through a port pin with a serial resistor may be precise enough to notice a deviation by a factor of two, especially if an A/D input can be employed to measure the voltage across the capacitor. High-quality capacitors with small tolerance and without significant aging should be used. Electrolytic capacitors are generally not recommended for such purposes. The STL provides examples for implementing frequency and time-slot monitoring.
Interrupts
The STL also provides a function, stl_inttest, for verifying that CPU interrupts are handled in time. This task is highly system dependent; therefore, the STL can only contribute the wrap-up handler, which checks that a number of specific interrupts occurred at least (and at most) a predefined number of times. Two independent clock sources are needed for this type of test.
Figure 2. CPU interrupt verification: frequency measurement for frequent interrupts
|
|
The principal function of stl_inttest is a frequency measurement achieved by counting the number of interrupts between calls to the stl_inttest function (see Figure 2). Each specific interrupt handler to be supervised must decrement a dedicated global variable. The function stl_inttest compares this variable with predefined upper and lower bounds, sets it to its preset value and returns an error if the limits are exceeded. The variable is unsigned and, therefore, must not be decremented below zero.
The principal function of stl_inttest is a frequency measurement achieved by counting the number of interrupts between calls to the stl_inttest function (see Figure 2). Each specific interrupt handler to be supervised must decrement a dedicated global variable. The function stl_inttest compares this variable with predefined upper and lower bounds, sets it to its preset value and returns an error if the limits are exceeded. The variable is unsigned and, therefore, must not be decremented below zero.
For such interrupts, which do not occur often enough, stl_inttest will decrement a tick counter if no interrupt occurred during the last interval. Otherwise, the tick counter will be reset to its initial value. stl_inttest will return an error condition if the tick counter is zero and its initial value is nonzero, or if it is decremented to zero.
Figure 3. CPU interrupt verification: frequency measurement with prescaler for rare interrupts
|
|
In Figure 3, the ticks counter is decremented by stl_inttest if the associated interrupt did not occur during the previous interval. Otherwise, it is reset to its initial value, which in this case is 5. stl_inttest will return an error condition if the ticks counter is zero and if its initial value is not zero. This is effectively a prescaler for the reference interval, which is set up by calls to stl_inttest.
In Figure 3, the ticks counter is decremented by stl_inttest if the associated interrupt did not occur during the previous interval. Otherwise, it is reset to its initial value, which in this case is 5. stl_inttest will return an error condition if the ticks counter is zero and if its initial value is not zero. This is effectively a prescaler for the reference interval, which is set up by calls to stl_inttest.
Watchdog Timer
One frequently asked question is whether an MCU’s built-in watchdog timer is sufficient or if an external one must be used. There is no clear definition in the IEC 60730 standard. One view is that if the internal watchdog is run from an independent time base, if it cannot be deactivated by software, and if the criticality is low (in other words, no high danger in case of malfunction, no fire), then an internal watchdog is accepted. However, different certification organizations may have different rules or perceptions of this requirement.
Figure 4. Microcontroller watchdog operation
|
|
For applications in which an internal watchdog is deemed acceptable, general-purpose MCUs can offer secure watchdog timers, independent of the CPU. As shown in Figure 4, the “windowed” watchdog is capable of detecting overrun or underrun timing errors.
The watchdog operates from an independent clock source from the CPU. The watchdog timer will trigger a hard reset if one of the following occurs:
- The watchdog timer runs into overflow.
- The “magic word” is written into the watchdog register when the window is closed.
- A wrong value is written into the watchdog register.
- Any access to illegal memory is detected.
Conclusion
On the whole, with additional hardware and software, today’s MCUs are capable of meeting the requirements of IEC 60730 and UL 1998. In the future, MCUs could be designed to provide dedicated features or macros for meeting such safety standards; for example, dedicated CRC generators or provision for dedicated independent time-slot and frequency measurements.
To help facilitate product development for home appliance manufacturers, major semiconductor companies should be proactively taking steps—such as incorporating a self-test library and multiple independent clock sources and integrating on-chip watchdog timers in their current MCU portfolios—to address these issues.
