²ÝÁñÉçÇø

By: Michael Thompson, Sr. Product Marketing Manager

We are not far from the point where our cars will be better drivers than we are. Automotive capabilities for advanced driver assist systems (ADAS) are evolving rapidly because of the potential that they offer to enhance safety and simplify the driving process. These capabilities are being enabled by the growing volume and complexity of the electronics in cars, and advances in high-performance microprocessors. As we refine processor architectures and move down the process curve, performance capabilities are increasing rapidly, enabling the creation of sophisticated systems that can analyze conditions in and around the vehicle and make accurate decisions based on those conditions. Ensuring the proper operation of ADAS systems is crucial to the safety of the occupants in the car, and to anyone else in the vicinity, which is why the ISO 26262 functional safety standard for electrical and/or electronic systems in automobiles was developed. The ISO 26262 standard, when applied to the microprocessors and systems in cars, can control or avoid systemic failures and control or mitigate random hardware failures and their effects.

ADAS: A Requirement for the Changing Automotive Market

While ADAS is being developed to enhance and automate vehicle systems for safety and driver convenience, it will undoubtedly lead to autonomous vehicles. Today, ADAS systems alert drivers to potential problems (for example blind spot warning) and taking over control of the vehicle in some situations (collision avoidance). As these systems automate tasks, they are indirectly reducing the stress that drivers face, which is being favorably received by drivers. Adaptive cruise control and lane keeping assist are available in cars today to reduce driver stress. As these capabilities advance, they will take over more and more of the operation of cars until the driver is no longer needed. The availability of fully autonomous vehicles is not far away, and this will mean the deployment of thousands of processors in each car within just a few years.

Automotive ADAS Design Challenges

Electronics in cars today account for 35% of the cost to build the vehicle. By 2030 this will rise to 50%, and an average car will have more than 300 million lines of code running in its various processors. The increase in electronics will also enable the vehicle to have more, or even autonomous, control over the driving function, making the safety of the occupants in the vehicle dependent on the proper functioning of the electronic systems. The increasing levels of electronics for functional safety need to be balanced against cost. 

To this end, the ISO 26262 functional safety standard for electronic systems in cars was established in 2011. The standard defines four Automotive Safety Integrity Levels (ASILs) based on the hazard analysis and risk assessment that a system in a vehicle exposes the occupants to in the event it malfunctions. An electronic steering system would carry an ASIL D classification (the highest level) while a rear-view camera might carry an ASIL A classification (the lowest level). If the steering system fails, the results for the occupants or anyone near the vehicle could be catastrophic, while the failure of a rear-view camera would be annoying but not life threatening. The goal of ASIL classification is to minimize susceptibility to random hardware failures by defining functional requirements and then taking the necessary design measures, including fault injection and systemic analysis and metrics reporting during the design process, to prevent them or minimize their impact if they occur. Implementing systems that meet the required ASIL is not without cost and, as more electronic systems in cars take over more critical operations, the costs due to functional safety will increase.

Support Required for ASIL Classifications

The goal of implementing ISO 26262 is to analyze the risk early in development, determine the appropriate safety level, establish how this level of safety will be met, and determine how it will be tested throughout the process. Devices developed under the ISO standard must meet specific goals for testing the hardware and the safety mechanisms implemented in that hardware, as well as in the software that run on it. The goals and ASIL certification level established early in the development process lead to the appropriate safety requirements and levels of testing. The level of ASIL support required can add significant cost to implement the product in terms of design time, silicon area and testing. Fault injection testing is recommended for ASIL A and B, and is highly recommended for ASIL C and D. For ASIL B, single point fault detection coverage of 90% is required and multi-point latent fault coverage of 60%. For ASIL-D single point coverage of 99% and multi-point coverage of 90% is required. Achieving the higher coverages needed for ASIL D support requires more hardware and test circuitry. For example, using a parity bit per word will support 90% coverage for the memories while full error detection and correction is needed to achieve 99%. Timeout monitoring, a watchdog, or information redundancy can be used to reach 90% coverage, but all three will be needed to reach 99%. 

ASIL D Implementation for Critical Systems

As systems in automobiles become more important for functional safety, they require higher levels of ASIL certification. Semiconductor and system developers can ease their certification efforts by using processor IP (and other IP in their design) that is either ASIL certified or ASIL ready for the level of ASIL certification that they need to meet for their product. An ASIL D implementation using ARC? HS processors that was used in a vision application is shown in Figure 1. An HS38x4 quad-core processor configuration was used to meet the application¡¯s very high-performance requirement. To meet the ASIL D coverage requirements, the HS38x4 was lock-stepped with an HS38x4 shadow core. This pair was connected via a safety monitor to a safety manager that is outside the HS38x4 core. The safety manager monitors the core and other processors on the device and reports any problems to the host processor. The HS38x4 also included error injection hardware for safety testing. 

Adapting IP Processor Designs for ISO 26262

ASIL capabilities were added to the HS processor during the initial development of the processor, as shown in Figure 2. An ISO 26262 safety plan was developed at the time that the core specification was written. The design team established the hardware safety requirements and safety goals, and designed the required hardware safety features into the HS processor RTL. The safety features are fully documented and included in the safety documentation for the core. Full ISO 26262 support for the processor requires module design verification and validation with fault injection/coverage analysis resulting in an FMEDA report that is also included with the safety documentation.