issue: May 2007 APPLIANCE European Edition
The Impact of Safety Regulations on MCUs in Home Appliances
Email this Article
by Steve Redpath, assistant manager, Industrial Business Group, NEC Electronics (Europe) GmbH
U.S. and European Safety Regulations
Governing bodies in the U.S. and Europe have introduced regulations defining safety requirements in the design of home appliances. In Europe, these requirements are defined by IEC60730, and some aspects are covered in the U.S. by UL 1998. The latter is an American National Standard and focuses strictly on software issues, in contrast to the broader range of home appliance issues covered by IEC60730.
By October 2007, all home appliances intended for sale on the European market will be required to comply with the IEC60730 standard. This will necessitate the inclusion of features that will avoid failure or at least ensure that any failure in the appliance does not present a safety hazard to the user. Semiconductor suppliers must consider the impact of these standards on home appliance manufacturers when developing micro-electronics for these devices.
What is IEC60730?
In general, IEC60730 applies to automatic electrical controls for use in equipment for household appliances and similar use, including controls for heating and air-conditioning. The equipment may use electricity, gas, oil, solid fuel, solar, thermal energy, or a combination of these power sources.
More specifically, the standard applies to automatic electrical controls, mechanically or electrically operated, responsive to or controlling such characteristics as temperature, pressure, passage of time, humidity, light, electrostatic effects, flow, liquid level, current, voltage, acceleration, or a combination of these characteristics. UL 1998 applies to any product that uses software.
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 microcontroller will require in order to comply with the requirements of IEC60730 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, dryers, dishwashers, refrigerators and cookers. Class C applies to products such as gas-fired boilers.
The specifications require that controls that have 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 microcontroller.
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 equipment)
- 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 microcontroller.
Annex H table H.11.12.7 of the IEC60730 specification defines the elements of the microcontroller 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.
Annex H table H.11.12.7
• Functional test or periodic test using:
Test of static memory or word protection with one-bit redundancy
1.3 Program counter
• Functional test
• Periodic test
• Independent time-slot monitoring
• Monitoring of program sequence
2. Interrupt Handling and Execution
• Functional test, or
• Periodic test
3. System Clock
• Frequency monitoring, or
• Independent time-slot monitoring
4.1 Nonvolatile Memory:
• Periodic modified checksum, or
• Multiple checksum, or
• Word protection with one-bit redundancy
4.2 Volatile Memory:
• Periodic test of static memory
• Word protection with single-bit parity, including the address
5. Internal Data Path (Data and Addressing)
• Word protection with one-bit redundancy or
• Data redundancy
• Word protection with single-bit redundancy, including the address
6. External Communication
• Word protection with multi-bit redundancy, or
• Cyclic redundancy code CRC, or
• Transferred redundancy, or
• Protocol test
• Time-slot monitoring
7. I/O Port
7.1 Digital I/O
• Plausibility check
7.2.1 Analog I/O
• Plausibility check
• Plausibility check
8. Other Components
• Periodic auto-test
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 microcontrollers to be used to meet parts of the requirements of a class B control function, as defined by the IEC60730 standard. For example, the STL provides application program interface (API) calls that can be used at system startup and/or periodically as the application requires.
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 is written back to the memory unless the user disables the write-back function.
The IEC60730 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 to 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 sub-harmonics 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.
Figure 2. CPU Interrupt verification: frequency measurement for frequent 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.
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 variable to 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 non-zero, 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.
One frequently asked question is whether a microcontroller’s built-in watchdog timer is sufficient or if an external one must be used. There is no clear definition in the IEC60730 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.
For applications in which an internal watchdog is deemed acceptable, general-purpose microcontrollers can offer secure watchdog timers, independent of the CPU.
Figure 4. Microcontroller watchdog operation
As shown in Figure 4, the "windowed" watchdog is capable of detecting overrun or under-run 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
On the whole, with additional hardware and software, today’s microcontrollers are capable of meeting the requirements of IEC60730 and UL 1998. In the future, microcontrollers 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 microcontroller portfolios—to address these issues.
About the Author
Steve Redpath is an assistant manager within the Industrial Business Group of NEC Electronics Europe. He has more than 25 years of experience in the electronics industry, including six with NEC Electronics Europe, where he has worked as a senior applications engineer and applications team manager. Redpath holds a Bachelor of Science in electrical and electronic engineering. If you’d like to contact him, e-mail firstname.lastname@example.org.