Taking the Speed Bumps Out of the ISO 26262 Functional Safety Certification Process

Stringent International Organization for Standardization (ISO) 26262 functional safety specifications ensure that the increasingly complex and sophisticated automotive applications operate safely. However, developing compliant designs and achieving certification can be a time-consuming and expensive process. These challenges are being alleviated as the semiconductor industry provides automotive Original Equipment Manufacturers (OEMs) and suppliers with complete functional safety ecosystems that minimize the cost, risk, and development time for completing this certification process.

Understanding ISO 26262

The ISO 26262 standard encompasses specifications for functional safety of electrical and/or electronic systems that are installed in serial production road vehicles (excluding mopeds). Published in 2011 and revised in 2018 to include a section on semiconductors, this ISO standard mandates a development process from specification through production release. Automotive OEMs and suppliers must follow and document this process when qualifying devices to operate inside road vehicles that require functional safety

Certification of systems is achieved through an independent assessor’s confirmation that it complies with the ISO 26262 standard’s requirements. Applications within the car are "classified" to various Automotive Safety Integrity Levels (ASILs) depending on their level of safety criticality. Some applications have a higher inherent safety risk if an electrical or electronic system malfunctions. The levels, from A through D, are based on the severity and probability of potential injuries and the extent to which they can be controlled, and there are associated safety requirements for underlying components. ASIL D represents the highest degree of automotive hazard for applications like airbags, anti-lock brakes and power steering. Components like rear lights are classified as ASIL-A. Head and brake lights generally are classified as ASIL-B. A system like cruise control is classified as ASIL-C. Typically, the higher the ASIL level, the more requirements there are for hardware redundancy.

There are multiple ways that component suppliers help accelerate the design of a safety application and its ISO 26262 certification. These functional safety resources are shown in Figure 1. First, devices must be carefully selected to encompass the necessary functional safety resources. These resources include Failure Mode Effect and Diagnostics Analysis (FMEDA) reports and safety manuals. Devices also must be supported by a development ecosystem qualified for creating safety-critical applications.

Functional Safety Readiness

A variety of ICs are used in today’s automobile. Microcontrollers (MCUs) are especially prevalent in a variety of forms. They are required for all electronic control units (ECUs) and used throughout the car to add convenience features such as self-driving and a variety of other sophisticated capabilities. They range from 8-bit MCUs that are optimized for performance, power efficiency, and real-time control while adding hardware-based touch interfaces, to 32-bit MCUs that can run multi-threaded applications and have graphics, connectivity, and security functionality. In addition, there are Digital Signal Controllers (DSCs) that combine an MCU with a DSP engine to provide robust and fast deterministic performance for sensors, motors, or power conversion.

Each of these ICs must first meet automotive qualification standards for manufacturing and performance that have been established by the Automotive Electronics Council (AEC). The AEC-Q100 standards define a failure mechanism-based stress test qualification process across temperature grades. Depending on the applications, an MCU will need to be AEC Q100 Grade 2, Grade 1 or Grade 0 qualified. Grade 0 = 150C, Grade 1 = 125C, and Grade 2 = 105C.

Beyond AEC qualification, the additional requirements for dedicated functional-safety-ready features depend on the device and application. As an example, 8-bit MCUs often include CAN FD for automotive interface and smart sensor networks and are typically used as User Interface (UI) controllers for mechanical and capacitive buttons in the cabin, steering wheel, center console or as part of a keyless entry system. Theintegrated hardware safety features these MCUs need typically apply to memory, system reset, safe code execution, safe communication, and General-Purpose Input/Output (GPIO) protection. These are added by integrating dedicated Core Independent Peripherals (CIPs) and other functions, including Power-On Reset (POR), Brown-Out Reset (BOR), Windowed Watchdog Timer (WWDT) and Cyclic Redundancy Check (CRC) to improve operational safety and reliability (see Figure 2).

Click image to enlarge

Figure 2: 8-bit MCU with functional safety hardware features

Moving up the ladder to functional-safety-ready 16-bit DSCs, required hardware safety features generally include memory with error detection and correction, memory built-in self-test (MBIST), clock monitoring and redundant oscillator, and more, for fault detection, self-diagnostic and system diagnostic capabilities and fault mitigation. These functional-safety-ready devices enable designing safety-critical high-performance embedded, sensor interfacing, digital power, and motor control applications. Typical applications include DC/DC systems, On-Board Chargers (OBCs), actuators and sensors (position, pressure), touch and other control units targeting up to ASIL B or ASIL C compliance.  Figure 3 shows an example of the features of a functional-safety-ready DSC.

Click image to enlarge

Figure 3: Example of a functional-safety-ready 16-bit DSC

As with all functional-safety-ready MCUs, 32-bit MCUs need hardware features including memory with Error Correction Code (ECC) and Fault Injection, Memory Built-in Self Test (MBIST), clock systems including backup oscillators and clock failure detection, and GPIO with Electrostatic discharge (ESD) protection (see Figure 4). Also important are system monitors including POR, BOR, WDT and hardware CRC functionality, and a memory protection unit. 32-Bit MCUs are used in a range of applications, from in-cabin systems to Advanced Driver-Assistance Systems (ADAS) for functional safety.

Click image to enlarge

Figure 4: Example of a functional-safety-ready 32-Bit MCU

It is possible to reach even the ASIL C/D safety levels with standard MCUs and DSCs, by combining the primary MCU or DSC with a secondary one or safety co-processor. This is accomplished by using the ASIL decomposition principle: the combination of two ASIL B compliant subsystems can be used to reach a higher ASIL such as ASIL C/D:

ASIL C = ASIL B (C) + ASIL A (C)

ASIL D = ASIL B (D) + ASIL B (D) = ASIL C (D) + ASIL A (D)

Decomposition is achieved by partitioning the safety requirements versus the actual devices.

Development Tools and Certification Support

Design tool packages that are certified for functional safety as part of a complete development ecosystem can make it easier to satisfy the verification and validation requirements specified in the ISO 26262 standard. This is particularly true of MCU and DSC-based designs. Tool suppliers work with third-party independent assessing and certifying agencies to certify functional-safety compilers. This typically comes with additional documentation such as certificate, a functional safety manual, a safety plan and tools classification and qualification reports for the compilers, Integrated Development Environment (IDE), and debuggers and programmers. This functional safety documentation package simplifies the tools’ qualification and the certification of the end application.

Ideally a code coverage tool should also be used in the design process to measure how well code has been tested and to determine what parts of software that have or have not been executed.  The code coverage tool should also be included in the classification and qualification reports. Look for a tool that can test in a single pass without breaking code into blocks and requiring a large amount of hardware modification, expensive software, and significant effort searching through large data files for pertinent information. Certification of applications requires code testing data, so single-pass code coverage tools play a significant role in streamlining the process and speeding time to market.

In order to develop an automotive application that complies with ISO 26262, an engineer will need several additional resources from the semiconductor supplier beyond the device datasheet. The availability of Functional Safety packages gives automotive OEMs and suppliers what they need at various stages of the evaluation and design cycle. These packages should encompass certified safety manuals, FMEDA reports and, in some cases, diagnostic software such as certified self-test libraries for relevant ASILs.

The FMEDA report quantifies the device’s fault modes, its Failure-In-Time (FIT) rate distribution and corresponding detection methods to help create a coverage plan. Another important resource is the Safety Manual (SM). It provides details on the fault detection methods named in the FMEDA report and offers recommendations on how the device should be used for the safest operation. It includes a description of dependent failures and hardware features for detecting systematic failures, which can be used for developing diagnostic libraries. The functional safety diagnostic libraries can help evaluate the operational status of a system under a fault condition, detect random system failures and achieve functional safety goals. Selecting a device that offers a third-party-certified FMEDA report and Safety Manual plus diagnostic libraries simplifies certification efforts of a safety-critical application.

A safety-critical application development starts by defining the safety goals and the target safety level to be achieved. A functional safety basic package provides basic resources like FMEDA, safety manual and certification to get you started with the evaluation of target functional safety levels and design of a safety-critical automotive application.

A functional safety starter package for an MCU-based design would ideally include an ASIL B Ready certified FMEDA, safety manual and ASIL B/C compliant diagnostic libraries, in combination with a reference application which helps designers understand how these resources can be used to develop a safety-critical application while following the ISO 26262 process. A starter package helps accelerate the design cycle and develop an application as per ASIL B or C compliance.

A functional safety full package may extend the offerings to include certified diagnostic libraries containing source code and relevant safety analysis reports for designs up to ASIL B/C. Given many of the end customers request for a safety-critical application to be certified, the full package speeds up the certification process.

Automobiles are becoming more sophisticated, and their level of electronics is growing. It has become increasingly important that today’s functional safety-focused products for automobile applications support development ecosystems that offer certified functional safety resources for meeting ISO 26262 requirements. IC suppliers can also help automotive customers protect their long-term investment in this rigorous development and certification process. They can ensure that parts used in a certified system will continue to be supplied for as long as the customer wants to order them, removing the risk of a forced redesign due to a part unexpectedly entering end-of-life (EOL). This increases confidence that certification will not only be completed quickly and easily but will also only need to be done once.

Microchip Technology