MCUs for ADAS – what’s the difference?

The emergence of advanced driver assistance systems (ADAS) is changing how designers use and specify microcontrollers (MCUs), but it’s only one dimension of the changes occurring in the design of automotive systems (Figure 1). This FAQ will begin with the basics of AEC-Q100 requirements for automotive integrated circuits – those requirements are not going away any time in the foreseeable future. It then dives into ADAS by looking at functional safety requirements (including the emergence of ISO SAE 21434 cybersecurity requirements), lock step MCUs and automotive safety integrity level (ASIL) concerns; reviews how MCUs fit into ADAS sensor fusion applications; and closes by considering the implications of over-the-air (OTA) software updates on the specification of automotive MCUs.

Figure 1: ADAS levels are based on increasingly complex implementations of automotive automation. (Image: Renesas)

AEC-Q100 applies to semiconductor devices, including MCUs. It’s a failure mechanism based stress test qualification that includes several grades based on operating temperature ranges:

Grade 0, -40° to 150°C, devices that can be used in any automotive application
Grade 1, -40° to 125°C, primarily used to identify under-the-hood devices
Grade 2, -40° to 105°C, for hot spots in passenger compartments
Grade 3, -40° to 85°C, general passenger compartment applications

AEC-Q104 is the corresponding standard for multichip modules (MCMs) in automotive applications. An MCM contains multiple electronic components, often including passive devices and discrete semiconductor devices, in addition to an MCU, enclosed in a single package. Typical ambient operating temperature ranges for sub-components are defined in AEC-Q100, AEC-Q101 (for discrete semiconductor devices), and AEC-Q200 (for passive components). MCM suppliers have the latitude to specify the operating temperature range for specific MCUs, based on a given set of operating environment assumptions.

Functional safety, lock step MCUs and ASIL

Functional safety standards such as ISO 26262 are required for ADAS implementations. ISO 26262 defines Automotive Safety Integrity Levels (ASILs). Higher ADAS levels demand higher ASIL classifications (Figure 2). Higher ASIL levels require the increasingly strict mitigation of hardware faults. Redundant hardware is often used to provide more robust system operations. In the case of MCUs, this is often implemented through a MCU with dual-core lock-step implementation. Since this approach consumes a considerable amount of area and power, it is usually reserved for higher ADIL levels. For systems that require lower safety integrity levels, such as ASIL B, a simpler and lower-cost combination of safety mechanisms, such as Error Correcting Codes (ECC), and Built in Self Tests (BIST) can be used.

Figure 2: Automotive ASIL ratings for representative systems. 1. Airbag (ASIL-D); 2. Instrument cluster (ASIL-B); 3. Engine management (ASIL-C to D); 4. Headlights (ASIL-B); 5. Radar cruise control (ASIL-C); 6. Electric power steering (ASIL-D); 7. Vision ADAS (ASIL-B); 8. Active suspension (ASIL-B to C); 9. Antilock braking (ASIL-D); 10. Brake lights (ASIL-B); 11. Rearview camera (ASIL-B). Image: Micron Technology)

Lock-step is a hardware implementation to provide redundancy. Both cores are expected to execute the same code. When in operation, the code from each core is fed into a comparator. If there the code streams are identical, the system operates normally. If a discrepancy is found between the two code streams, a fault condition is indicated. The system functionality defines the action taken. Since lock stepping is implemented through hardware, there is no flexibility, and the two cores effectively deliver the performance of a single core. Lock stepping is effective, but more flexible software- and firmware-based alternatives also exist.

A recently released standard, ISO/SAE 21434, builds on ISO 26262 to provide a methodology for integrating cybersecurity into automotive systems. Among the factors included in ISO/SAE 21434 are cyber security management, continuous cyber security activities, associated risk assessment methods, and other factors. It includes two major sections:

The Threat Analysis and Risk Assessment section reviews methods to determine the extent to which a threat scenario can impact a vehicle.
The Product Development section reviews the specification of the cybersecurity requirements and architectural design in product development and integrates it into the “Systems Engineering V Model” commonly used for automotive design.

And there’s United Nations Regulation No. 155 that sets requirements for cybersecurity and cyber security management systems in vehicles. It includes 69 attack vectors affecting vehicle cybersecurity. Threat modeling on the defined attack vectors is generally required for risk assessment. MCUs need to support both UN 155 and ISO/SAE 21434. Beginning July 2022, many automotive MCUs will be required to support a cybersecurity management system (CSMS) to ensure stringent cybersecurity processes have been implemented to gain vehicle type approval.

ADAS sensor fusion

Sensor fusion is an increasingly important aspect of ADAS implementations. Sensor fusion describes the use of MCUs to combine inputs from various sensors such as radar, camera, ultrasonic, and LIDAR to improve overall awareness of dynamic machine/infrastructure status and/or the ambient environment around the vehicle (Figure 3). Combining the input from various sensors supports a more complete understanding of the necessary environment to support advanced ADAS features and automated driving functions.

Figure 3: Sensor fusion in ADAS systems use MCUs to combine data from multiple sensors to improve context awareness of the driver’s condition, the machine/infrastructure status, and/or the ambient environment around the vehicle. (Image: Counterpoint Research)

Advanced ADAS functions such as cross-traffic assist or autonomous obstacle avoidance cannot be implemented without the redundancy supported by sensor fusion (Figure 4). In addition to high-performance processing, the associated MCUs must include safety and security functionality. Some of these advanced MCUs support sensor pre-processing in addition to on-chip analytics. These systems can be required to simultaneously support multiple high-resolution cameras and fuse that image information with other sensors such as radar, LIDAR, or ultrasonic sensors all in one MCU. This level of sensor fusion is required long before full autonomous driving is realized; it’s needed for ADAS functions such as automated parking and surround-view and image processing for displays, providing drivers with enhanced 360 degrees of awareness of the vehicle surroundings. The need for high-performance MCUs to support sensor fusion will continue to grow as cars move toward higher levels of automated driving.

Figure 4: ADAS sensor fusion will provide the redundancy expected for autonomous functions. (Image: STMicroelectronics)

OTA-enabled MCUs

The software used in automotive systems continues to grow in complexity, making the need for updates to add new features or fix security concerns an increasingly common requirement. Bringing cars back to the dealer for updates is not a cost-effective solution. As a result, the ability to implement over-the-air (OTA) updates is growing in importance. OTA updates started with infotainment systems and are beginning to be implemented across a range of ADAS systems.

OTA updates can be used to provide updates and/or corrections demanded by software recalls. OTA updates can be used for firmware (FOTAs) or software (SOTAs). In either case, the update needs to be secure and implemented in the background without disrupting normal vehicle operation. Timing of an OTA is also important; sufficient network bandwidth must be available for an adequate period to allow the download. In some cases, the driver is alerted to the update and asked to accept it when the vehicle is started. To implement OTA, MCUs need to include specific functionality such as:

Confirmation of the MCU’s identify
Support encryption for secure connections and for authentication of the updated code is often performed in a separate crypto core (Figure 5).
Include secure storage pending the actual update
Transparently update and implement the new code
Maintain the ability to roll back to the previous code as needed.

Figure 5: MCUs for ADAS and OTA often include a separate core to perform cryptographic functions (upper right-hand corner). (Image: Infineon)

The design of OTA functionality requires flexibility since different automakers can implement it in varying manners. For example, for maximum applicability, the MCU should support both symmetric and asymmetric encryptions. The MCU is also expected to support secure boot to ensure that the correct code is loaded at startup. Without secure boot, there is little or no ability to ensure that the correct (updated) code is being used.

Summary

An MCU is an MCU unless it’s intended for use in automotive ADAS applications. ADAS MCUs have a myriad of performance requirements and international standards to meet. The list includes the basics like AEC-Q100 and more complex standards such as ISO 26262 and emerging standards like UN 155 and ISO/SAE 21434. Sensor fusion support and OTA functionality are also increasingly important. As vehicles continue the march toward Level 6 ADAS and fully automated driving, the performance expectations and standards requirements for automotive MCUs are expected to snowball and become ever more daunting.

References

Automotive ADAS Systems, STMicroelectronics
Functional Safety for Automotive, Micron Technology
ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering, ISO
Over-the-Air (OTA) Updates in Embedded Microcontroller Applications: Design TradeOffs and Lessons Learned, Analog Devices
Over-the-air (OTA) Updates for Microcontroller-based Automotive Systems, Infineon Technologies
Sensor fusion for autonomous driving, Infineon Technologies
The Flexible Approach to Adding Functional Safety to a CPU, ARM