Give away medical masks when you place an order. learn more
Design teams working on a broad array of consumer appliances are faced with the challenge of meeting pertinent safety standards including the European IEC 60730 specification. Most companies want to design products for a global market, so the design team is typically tasked with meeting the most rigid global standards for all appliance designs. You can certainly develop compliant products using any microcontroller (MCU) along with the appropriate support ICs. However, a growing range of MCUs include specific functions in hardware that enable compliance without the need for external components. Let's examine the need for safety compliance, and some of the MCUs that pave the path to compliant designs.
Specifically, the IEC 60730-1 standard addresses the use of MCU-based control systems in Annex H of the specification. Most consumer appliances such as washing machines, refrigerators, and similar products fall under a Class B category. The intent of the standard is to ensure that a system fault does not result in unsafe operation of the equipment. For example, a failure in the system should not result in unsafe temperatures that might injure an operator or cause a fire.
Note also that the concepts behind IEC 60730 and the techniques we will discuss here can be applied beyond the consumer-appliance application. Indeed many types of embedded systems, not necessarily governed by a regulatory standard, require safeguards against system failure.
Generally in an MCU-based system, IEC-60730 compliance depends on firmware that you add to your application code. However, safety-centric MCU hardware features can simplify the firmware development, improve performance, and lower cost by eliminating external components.
Approaches to compliance
There are three primary approaches to designing MCU-based systems for IEC 60730 compliance. The most complex use what is called dual-channel architecture, with dual MCUs and control circuits operating in parallel and a comparison function which ensures both channels produce the same results. This approach, however, is generally considered too expensive for the consumer market.
Cost, then, limits our options to the two single-channel approaches. You can achieve compliance by testing a system against faults at the time the product is manufactured. In the past, the manufacturing test was often the chosen approach, being the simplest and lowest-cost alternative. Today, more product manufacturers choose to add periodic self-test functions to ensure a product against failures in the field and that is the approach we will focus on here.
The actual safety certification is performed on the end equipment, but the potential faults in Annex H apply to the MCU. Indeed, the Annex includes a detailed list of elements within an MCU and associated faults that must be tested for in the periodic self-test, and mitigated in some manner.
For example, the self-test must detect registers or a program counter (PC) that are stuck at a faulty value, detect single-bit errors in memory, and detect improper interrupt operation – including instances when no interrupts occur, along with instances where interrupts occur too frequently. Additional elements address proper clock operation, timing in terms of sequence of operations, and communication faults.
Washing machine example
Now let's look at some examples of how MCUs, specifically DSP-enabled MCUs that are often called digital signal controllers (DSCs), simplify compliance. Figure 1 depicts a block diagram of a washing machine design based on a Texas Instruments (TI) DSC. The block diagram is applicable to the TMS320C24x fixed-point DSC family, the TMS320F282x fixed-point DSC family, and the TMS320F2802x/2806x Piccolo family of fixed- and floating point DSCs. All of the DSCs rely on a 32-bit TI C2000 core that handles both the DSP (primarily motor control) and system-control tasks in a single-processor design. The C2000-based DSC can also be combined with a separate system controller MCU, but in either case the IEC-60730 elements are captured within the DSC.
Figure 1: Texas Instruments C2000-family DSCs implement functions such as independent clocks to simplify systems designs that target IEC-60730 compliance.
The TI DSCs offer several elements that enable compliance. For example, the ICs include dual on-chip oscillators. One drives the primary operation of the MCU and system. The second can be used as an independent time base that controls execution of the periodic self-test implementation. The ICs also include supervisory circuits that monitor supply voltage which can cause the faults described in the standard. Additionally, the DSCs include write-protection features for registers.
Of course many appliance applications do not require the processing power afforded by a 32-bit DSC. Fortunately MCU vendors also are offering IEC-60730-compliance features on traditional 8- and 16-bit MCU families.
Freescale Real Time Interrupt
Freescale, for example, supports such features on its MC9S08AWx MCUs that are part of the broad MC9S08 8-bit family. The 9S08AW MCUs include a Real-Time-Interrupt (RTI) feature that can enable a number of self-test functions. Figure 2 depicts the RTI functionality. Along the top of the diagram, the System Real-Time Interrupt Status and Control Register (SRTISC) include 3 bits – the Real-Time Interrupt Delay Selects (RTIS) – that set an interval for periodic CPU interrupts. The interval can vary from 8 msec to 1.04 s. The interrupts are derived from an integrated 1-KHz RC oscillator that is independent of the CPU clock.
Figure 2: Freescale uses a feature called the Real-Time Interrupt (RTI) as an enabler of interrupt service routines to check a system for IEC-60730-defined faults.
The self-test functions are implemented in the Interrupt Service Routine (ISR) generated by the RTI. For example, the ISR can check the value of the PC during each iteration. If the PC remains unchanged in three consecutive iterations, the ISR can assume that the MCU is stuck in a software loop and take preventative action.
The RTI can also allow the ISR to monitor the clock frequency. The ISR simply utilizes an integrated time to take a time stamp each time the interrupt is serviced and verify that each successive reading is valid. Separately, an internal clock generator implemented on the chip has a built-in function that tests for a slow or fast CPU clock or loss of the clock. The RTI-initiated ISR can monitor the register of the Lock and Loss of Clock Detector function.
Freescale supports a number of different safety-oriented features including methods for checking the accuracy of memory. Moreover, the company also supports the IEC-60730-centric features on the MC56Fx family of 16-bit DSCs.
IEC 60730 across MCU architectures
Renesas, meanwhile, has perhaps the broadest set of different architectures in the MCU space, due mainly to the fact that the company sells MCUs with a heritage in the former Hitachi, Mitsubishi, and NEC microelectronics operations. However, the company has pretty consistent safety-compliance features across the portfolio.
A watchdog timer (WDT) is a key component used in most every case when meeting safety standards. Renesas implements WDTs that are clocked by sources independent of the CPU clock across the mature 8- and 16-bit R8C, M16C, 8- and 16-bit H8, and 32-bit SuperH MCU families.
Renesas has continued the robust WDT support in the newer 16-bit RL78 MCU family and the 32-bit RX family. Moreover, the company has added additional features in hardware over time. For example, the M16C introduced a CRC (cyclical redundancy check) calculation block that works independently of the CPU. A CRC can be used to detect memory and communication errors.
The RL78 and RX families also support CRC capabilities and add other features. For example, the RL78 includes RAM parity detection, a memory-access-control feature set, and a clock-frequency-monitoring function. The RX family includes similar features and self-diagnostic functions for data converters.
Design for safety
If your next design dictates an approach that guarantees a safe exit from faulty situations, make sure you consider how the MCU vendors approach IEC-60730 compliance. Virtually all MCU vendors have an IEC-60730 strategy, and choosing an MCU with hardware features intended for safety compliance can reduce your system bill of materials yielding cost, power-consumption, and performance benefits. Moreover, the MCU vendors generally offer sample code for meeting IEC-60730 requirements and that code will greatly accelerate your design of an end product that can safely survive a fault in your code or the system hardware.