Safety Matters In Home Appliance Design

Humanity’s access to more electronics at cheaper prices keeps growing, and these electronics have become virtual necessities. More intelligence is being integrated into appliances like refrigerators, washing machines, and coffee makers in the form of discrete ICs to improve the user experience, including electronic control, touch-based user interfaces, and sophisticated displays. But while these features are all useful, safety is also a priority.

Appliances that use a microcontroller, which is true for most appliances today, have the potential to malfunction if the microcontroller does not behave correctly. If the microcontroller’s clock does not function correctly or its pins are shorted to supply or to some other pin, a hazardous situation can develop.

For instance, in a gas sensing system, the wrong clock frequency may lead to communication errors. If the system is a digital toxic gas sensor, failure to read correctly could result in an explosion. In a washing machine, if the input button’s pin is shorted to the supply voltage, the motor could potentially start unexpectedly and injure the user.

Related Articles
• Triac Delivers Motor Drive For Household Appliances
• White Goods Become Smart Goods
• With Proper Isolation, You Won’t Need To Do The Safety Dance Around High Voltages

To ensure that home appliance manufacturers include all the required safety features and detect all required fault conditions, the International Electrotechnical Commission (IEC) has created a safety specification documented in IEC spec IEC60730 under section Class B safety requirements. In some countries, appliances must adhere to these safety specifications before they can be sold.

For appliance manufacturers, these safety features can add more complexity, cost, and development time to the system design. To get appliances certified, they must be designed in a way that reliably detects various fault conditions and takes required action as specified in the safety requirement guidelines.

A Closer Look At IEC60730-1

This specification defines three classes of software for control functions: Class A, Class B, and Class C. Class A control functions do not include any safety measures. Home appliances fall under Class B, which aims to prevent the unsafe operation of home appliances. For example, if there is some fault in the control section of an induction cooker, it should not activate the heating element. Class C control functions prevent hazards like explosions.

To meet class B software requirements, the implementation must possess one of the following:

• Single channel with functional test: As per this implementation, the device is tested for intended functionality before shipment. Implementation is based on one control unit/MCU.

• Single channel with periodic self-test: As per this implementation, the device performs periodic tests during runtime. A single MCU is used in this implementation as well.

• Dual channel without comparison: In this implementation, two MCUs are used to perform various critical tasks. Both MCUs communicate to ensure that everything is up and working.

Single channel with functional test prevents implementation complexities. However, the reliability achieved by this method is minimal as the device is not tested at runtime and any failure that leads to unsafe operation won’t be detected. Also, as a device must be tested for functionality before shipment, production costs increase drastically.

Single channel with periodic self-test is being adapted to ensure maximum safety while reducing production costs. To achieve this, safety features must be implemented in hardware and firmware during the requirement phase.

Some microcontroller manufacturers provide a self-test library for their products, and those libraries can be added to the end application. Some microcontroller manufacturers also have these libraries certified for the correct operation and integration of these functions in end applications. This helps get the end application certified with reduced overhead and reduced cost. It also eliminates one of the bottlenecks in meeting the product’s timeline for the manufacturer. Therefore, while selecting a MCU or a mixed signal-device, it’s important to check if self-test libraries are provided.

Dual channel without comparison is an expensive way to implement these control functions, especially for small appliances. It also brings in additional firmware overhead like inter-processor communication. This method is the least preferred for Class B control functions. However, it is a requirement for Class C control functions.

Software Requirements

Several components pertaining to electronic control must be tested to meet the specifications: the CPU, interrupt handling and execution, clock, invariable memory, variable memory, addressing, internal data path data, internal data path addressing, external communication, digital I/O, analog-to-digital and digital-to-analog converters, and analog multiplexer. Addressing, internal data path data, and internal data path addressing also need to be tested when the MCU uses external memory.

The CPU test determines if the CPU and its associated registers are working correctly. For instance, the accumulator, status register, and other components need to be tested to ensure they are not stuck at a particular value. This test can be performed in a straightforward way: a known value is written to a register and is read back followed by a comparison to check if the written and read values are the same.

Specific instructions can be executed to bring status registers that don’t support direct write to a known state. For example, a carry flag can be set by performing the addition on two numbers that will make the accumulator overflow. Corruption of the program counter will change the flow of program execution, and it is very important to stop the device. Unlike the other registers, testing this register is not that straightforward. The watchdog timer can be used to reset the device if the program counter is stuck at a particular value. 

The interrupt handling and execution test checks if no interrupt is being generated or if an interrupt is being generated too frequently. There is no fixed minimum or maximum number for interrupts, and this very much depends on the system implementation.

This test can be implemented by using a count variable to monitor the number of times an interrupt is generated in a given amount of time. The timestamp can be generated using a timer. Also, the watchdog timer can be used to check if an interrupt is being generated too frequently and impacting system performance. If an interrupt is being triggered at a frequency that the watchdog cannot clear, a system reset will result.

The clock test checks if the system clock is accurate. For testing, a reference clock source is needed to generate a fixed time interval to frequency measurement. An external crystal oscillator (ECO) is the best implementation. Most MCUs and mixed-signal devices include an ECO where just an external crystal and load capacitors need to be connected to generate an accurate low-frequency clock. If the device does not support ECO functionality, an external clock generator will be required. Once an accurate reference clock is available, it can be used to generate time stamps, and a counter can be used to measure system frequency.

Invariable memory refers to the nonvolatile memory where the program is stored. For most MCUs, it is flash. Specific needs require a 1-bit error to be detected in the invariable memory. In some MCUs, it is inherent and they generate an interrupt if there is an error in the flash content. To implement it manually, there are various methods.

One method calculates the checksum of complete memory and stores it in flash. At runtime, flash checksum can be calculated and compared against the value stored in flash. Another method calculates checksum on a block-by-block basis and stores it in flash. If a flash block is unused and an error occurs in that block, it may not be considered as a valid fault condition as it does not impact program execution.

Variable memory refers to the data memory (i.e., RAM). This test checks if the memory bits are stuck at a 1 or a 0 or are being influenced by neighboring bits. The March C algorithm is the preferred method to perform this test. However, the March C algorithm test changes the memory content.

RAM is divided into segments, and each segment must be tested separately by backing up the content of the RAM segments under test. Otherwise, an EEPROM is used to store RAM data. Using EEPROM can impact the system’s lifecycle if the test is being performed too frequently, due to flash endurance. Moreover, most MCUs emulate EEPROM in flash that has an endurance of 10k to 100k write cycles. Using RAM itself to back up the content is the better way to implement this test.

Communication interfaces are integral in many systems. To ensure the reliability of the communication interface as per the Class B specification, the Hamming distance 3 must be met. The best way to implement this is to use cyclic redundancy code (CRC) error checking. Some MCUs have on-chip hardware resources to CRC check data. If hardware resources aren’t available, the CRC check can be implemented in firmware. Another aspect of the test is to ensure correctly timed communication. If the device is the host, it can monitor the amount of time that slaves take to respond. If a slave takes an unreasonable time, the host can trigger a fault condition.

The digital I/O test ensures that input/output pins are working as expected. Pins can be shorted to V_CC or GND or can be shorted to other I/Os that can lead to a system error. To test input functionality, an input pin must be forced to a known status. Some devices, like the PSoC 1 from Cypress Semiconductor, support internal pull-ups and pull-downs on most of the I/Os.

External shorts generally drive a pin to strong levels: strong high if shorted to V_CC or strong low if shorted to GND. If a pin is shorted to GND and an internal pull-up is activated, the pin will still read a 0, which is not the expected behavior of a functional pin. This will lead to a fault condition. If internal pull-ups are not available, external sources must be used to drive the pins. This will require additional hardware and will increase cost.

To test output pins, once the device drives a pin, its output status must be monitored. To do this, it must be connected to another pin by external means or it must have read capability (to read the status of the pin, not the value that was written by the CPU). The PSoC 1 supports a read on all pins. For example, if a pin is written high but due to external shorts it connects to GND, the pin can be read indicating a 0, which will indicate the fault.

A known value source is required to test analog-to-digital converters (ADCs) and digital-to-analog converters (DACs). Voltage references generally are available in systems-on-chip (SoCs) that can be connected to the ADC’s input. The output code of the ADC can be checked if the conversion result meets the known reference value. The DAC needs an ADC to check its output.

So if an integrated ADC is available in the device, it will help implement these tests at reduced cost. While performing the test on the DAC, the ADC first must be tested to ensure that it is working correctly. Using a SoC that allows a voltage reference and the DAC to be routed to the ADC using internal routing resources can significantly reduce I/O and printed-circuit board (PCB) routing complexity.

The analog multiplexer can be tested by forcing a known value on the pins and then using firmware to switch between the channels. An ADC must be connected at the output to measure the input voltage at the channel. If this pin supports both input and output functionality, a DAC can be used to source the required input.

Conclusion

Safe home appliances require self-test features. Developing these functions for an MCU can impact product cost and time, leading to undesirable delays in today’s competitive market. Selecting an MCU for which self-test libraries are provided by the vendor will speed implementation.

MCU-specific component tests, apart from a clock, do not need any external hardware. These tests do not add pressure when selecting a MCU. However, testing the I/Os, the ADC, and the DAC may lead to the use of external components that can increase system footprint size, cost, and development. SoCs can help reduce overhead while implementing the tests that are required to meet Class B specifications.