• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Electrical Engineering News and Products

Electronics Engineering Resources, Articles, Forums, Tear Down Videos and Technical Electronics How-To's

  • Products / Components
    • Analog ICs
    • Connectors
    • Microcontrollers
    • Power Electronics
    • Sensors
    • Test and Measurement
    • Wire / Cable
  • Applications
    • Automotive/Transportation
    • Industrial
    • IoT
    • Medical
    • Telecommunications
    • Wearables
    • Wireless
  • Resources
    • DesignFast
    • Digital Issues
    • Engineering Week
    • Oscilloscope Product Finder
    • Podcasts
    • Webinars / Digital Events
    • White Papers
    • Women in Engineering
  • Videos
    • Teschler’s Teardown Videos
    • EE Videos and Interviews
  • Learning Center
    • EE Classrooms
    • Design Guides
      • WiFi & the IOT Design Guide
      • Microcontrollers Design Guide
      • State of the Art Inductors Design Guide
    • FAQs
    • Ebooks / Tech Tips
  • EE Forums
    • EDABoard.com
    • Electro-Tech-Online.com
  • 5G

MCUs for ADAS – what’s the difference?

November 3, 2021 By Jeff Shepard

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

You may also like:

  • automotive qualification
    What does automotive qualification mean?
  • autonomous vehicles
    Memory and functional safety in autonomous vehicles

  • Technical challenges of automated vehicles
  • ADAS sensors
    The role of ADAS sensors in automotive design

  • What are ASILs and how do they work?
DesignFast Banner version: 641873d7

Filed Under: Applications, Automotive/Transportation, FAQ, Featured, Microcontroller Tips, Microcontrollers Tagged With: FAQ

Primary Sidebar

EE Training Center Classrooms

“ee

“ee

“ee

“ee

“ee

“ee

Featured Resources

  • EE World Online Learning Center
  • CUI Devices – CUI Insights Blog
  • EE Classroom: Power Delivery
  • EE Classroom: Building Automation
  • EE Classroom: Aerospace & Defense
  • EE Classroom: Grid Infrastructure
Search Millions of Parts from Thousands of Suppliers.

Search Now!
design fast globle

R&D World Podcasts

R&D 100 Episode 7
See More >

Current Digital Issue

February 2022 Special Edition: Power Electronics Handbook

Up in the sky! It’s a bird! It’s a plane! It’s a flying battery! According to a company called Joby Aviation, in a few years you’ll be able to summon up an air taxi on your Uber phone app for trips of 25 miles or so. And you won’t have to feel guilty about the…

Digital Edition Back Issues

Sponsored Content

Positioning in 5G NR – A look at the technology and related test aspects

Radar, NFC, UV Sensors, and Weather Kits are Some of the New RAKwireless Products for IoT

5G Connectors: Enabling the global 5G vision

Control EMI with I-PEX ZenShield™ Connectors

Speed-up time-to-tapeout with the Aprisa digital place-and-route system and Solido Characterization Suite

Siemens Analogue IC Design Simulation Flow

More Sponsored Content >>

RSS Current EDABoard.com discussions

  • I am Alec, a new member!
  • electrode-skin impedance mismatch
  • how to estimate Senseamp offset voltage to use montecarlo ?
  • Weird transformer result in ads
  • could calibre lvs do not check mosfet B term

RSS Current Electro-Tech-Online.com Discussions

  • Relaxation oscillator with neon or...
  • High component count for long delay circuit (inrush resistor switch out)
  • DIY Mini 12v Router UPS malfunction
  • MOSFET gets hot and burns
  • Positive and negative sides of voltage source

Oscilloscopes Product Finder

Footer

EE World Online

EE WORLD ONLINE NETWORK

  • 5G Technology World
  • Analog IC Tips
  • Battery Power Tips
  • Connector Tips
  • DesignFast
  • EDABoard Forums
  • Electro-Tech-Online Forums
  • Engineer's Garage
  • Microcontroller Tips
  • Power Electronic Tips
  • Sensor Tips
  • Test and Measurement Tips
  • Wire & Cable Tips

EE WORLD ONLINE

  • Subscribe to our newsletter
  • Lee's teardown videos
  • Advertise with us
  • Contact us
  • About Us
Follow us on TwitterAdd us on FacebookConnect with us on LinkedIn Follow us on YouTube Add us on Instagram

Copyright © 2022 · WTWH Media LLC and its licensors. All rights reserved.
The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of WTWH Media.

Privacy Policy