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

Microcontroller Tips

Microcontroller engineering resources, new microcontroller products and electronics engineering news

  • Products
    • 8-bit
    • 16-bit
    • 32-bit
    • 64-bit
  • Applications
    • 5G
    • Automotive
    • Connectivity
    • Consumer Electronics
    • EV Engineering
    • Industrial
    • IoT
    • Medical
    • Security
    • Telecommunications
    • Wearables
    • Wireless
  • Learn
    • eBooks / Tech Tips
    • EE Training Days
    • FAQs
    • Learning Center
    • Tech Toolboxes
    • Webinars/Digital Events
  • Resources
    • Design Guide Library
    • DesignFast
    • LEAP Awards
    • Podcasts
    • White Papers
  • Videos
    • EE Videos & Interviews
    • Teardown Videos
  • EE Forums
    • EDABoard.com
    • Electro-Tech-Online.com
  • Engineering Training Days
  • Advertise
  • Subscribe

Memory and functional safety in autonomous vehicles

July 30, 2021 By Robert Bielby Leave a Comment

As software and its associated memory footprint continue to expand in vehicles, automotive system designers need a deeper understanding of DRAM and its impact.

Robert Bielby • Micron Technology
carToday’s high-end vehicles are recognized as among the largest embedded software applications in the world, with a total memory footprint expected to grow from today’s staggering 100 million lines of code to over 300 million lines of code by 2030. Of course, the catalyst for this exponential growth is the move towards fully autonomous vehicles.

Whereas 10 years ago a more modest microcontroller might contain 50 million transistors, GPUs that can be found in today’s high-end cars can employ more than 25 billion transistors, an increase of 500X in a 10-year time frame. The increase in transistor count is also a good proxy for the overall increase in vehicular system-level complexity. And today, the automobile is widely considered to be one of the main drivers of many complex leading-edge products and technologies.

Automotive applications have pushed semiconductors into the functional safety arena. It is important to note that the first edition of the functional safety standard ISO 26262 published in 2011 was primarily limited to electrical and/or electronic systems with almost no consideration for semiconductors. However, since then, the focus has broadened to include the semiconductor industry — IC manufacturers, IP providers, and EDA companies. Eventually, with the second edition of the 26262:2018 specification came the addition of part 11 which is dedicated to semiconductors.

The ISO 26262 standard defines functional safety as the “absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems.”

Malfunctions are classified into two types of failures:

Systematic failures: These are failures that happen in a deterministic manner — typically introduced during product design or development. These failures are generally addressed by adopting well-documented processes and methodologies, including safety planning, safety concept documentation, requirements traceability, proactive safety analysis tools, robust verification, operational procedures, and other associated factors.
Random failures: These are failures that appear arbitrarily during the lifetime of a device. Random failures can be further divided into two categories: transient faults (single-event upsets or soft errors) or permanent faults (hard errors such as stuck at a logic level). These types of failures are generally addressed by introducing safety mechanisms that help identify the faults so the system can take actions such as correcting the fault or maneuvering to maintain a safe state.

Several safety mechanisms are employed at the memory hardware and system levels:

Redundancy — Typically implemented at the hardware level.
Cyclic redundancy check — Typically used for error detection.
Error correction code — Generally used for both error detection and correction.
Built-in-self-test — Takes the form of additional circuitry that verifies accurate device operation, either continuously or during power-up.

Various metrics measure the effectiveness of the safety mechanisms used to detect random failures in time (FIT) and the likelihood of risk. These metrics include single-point fault metric (SPFM) and latent fault metric (LFM), both used to measure the functional safety of a given hardware component.

ASILs

ASIL refers to the Automotive Safety Integrity Level. There are four ASIL levels defined by the ISO 26262 standard. ASIL A systems have the

asil levels
For hardware components, ASIL requirements identify the requisite values for failure metrics. LFM = latent fault metric, SPFM= single-point fault metric. Click image to enlarge.

least stringent level of safety reduction, whereas ASIL D is the most stringent. Higher ASIL levels typically imply rising cost and complexity, thus the ASIL level required for a given system directly correlates to the severity, exposure and controllability of that system’s failure on the operation of the vehicle.

Memory and storage in the modern vehicle is expected to grow and total to more than 1 TB. Thus there is understandably an ever-increasing focus on the role of memory in achieving functional safety levels. The ISO 26262:2018 release had a focus on semiconductors. Specifically, Part 8, Clause 13 classifies a hardware element as either, basic, intermediate, or complex – a reference to the general complexity of a given semiconductor device or sensor.

ISO 26262 hardware classifications
ISO 26262 Part 8, Clause 13 focuses on the classification of a hardware element as either, Basic, Intermediate, or Complex – a reference to the general complexity of a given semiconductor device or sensor. Click image to enlarge.

Historically, DRAM has been classified as a Class II – intermediate device, which belies the underlying complexity of DRAM. The underlying circuitry within a DRAM makes it apparent that DRAM would be more appropriately recognized in the Class III Complex range. The complexities include the following:

•Multiple states, operating modes, registers
•Many internal states/modes cannot be tested or analyzed without deep knowledge of implementation details and/or access to test modes
•Many failure modes cannot be identified, understood, and analyzed without knowledge of the design, implementation, and production process
•Safety mechanisms relevant for the safety concept are integrated

When designing automotive applications such as ADAS, system architects typically use commercial-off-the-shelf (COTS) devices, or automotive derivatives of these devices. There is a wide range of available auto-qualified COTS components including LPDDR4 and LPDDR5 DRAM.

Sometimes, designers may assume that legacy error-handling measures sufficiently address the end application. They don’t evaluate the effectiveness of these measures when used as safety mechanisms. Examples might include the use of in-line or sideband ECC on the host SoC – similar to its use in server or consumer applications.

ecc failures
Standard host-ECC schemes do not perfectly cover all potential failure modes in the external DRAM. Click image to enlarge.

The rationale for this type of memory is that the host-ECC adequately covers the external DRAM. However, in the context of functional safety, and for some of the reasons described earlier (why DRAM should be considered a Class III hardware element), it becomes clear that standard host-ECC schemes do not perfectly cover all potential failure modes in the external DRAM. As such, diagnostic coverage of traditional host-based ECC solutions may be sufficient only for applications requiring up to ASIL B.

Because the automotive code footprint is expected to reach 300 million lines, a detailed understanding of DRAM operation is becoming necessary for achieving the requisite ASIL level. Detailed understanding and modeling of DRAM makes it clear that a classification as a Category II Hardware Element is over-simplistic.

To go beyond ASIL B, designers should specify a memory with systematic fault coverage addressed by an ISO 26262-certified process. Designers should also request data regarding any safety mechanisms that address such items as latent faults and multiple bit errors, as well as about other features that can help reach the ASIL target. Also recommended is that designers work closely with the memory supplier and the associated Functional Safety Office to design guidelines, associated random fault coverage features (as applicable) are employed for the desired ASIL level.

It’s important for system designers to keep in mind that memory by itself can’t be the whole safety solution for vehicles. Designers are ultimately responsible for building-in redundancies and safety mechanisms and for ensuring the holistic system design is safe and reliable.

References
Microchip Technology, “Functional Safety for an Expanding Set of Applications”
Microchip Technology, “Functional Safety Ready MCUs for Automotive Applications”

You may also like:

  • router security
    Worst suspicions confirmed: The terrible security of internet routers
  • BLE hacks
    Breaking BLE — Vulnerabilities in pairing protocols leave Bluetooth devices…
  • RF won't hurt you
    No, IoT RF radiation won’t cause a pandemic
  • lidar
    A better way to measure LiDAR
  • flash
    Flash memory keeps cars connected

Filed Under: Applications, Automotive, Embedded, FAQ, Featured Tagged With: FAQ, microntechnologyinc

Reader Interactions

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Featured Contributions

Five challenges for developing next-generation ADAS and autonomous vehicles

Securing IoT devices against quantum computing risks

RISC-V implementation strategies for certification of safety-critical systems

What’s new with Matter: how Matter 1.4 is reshaping interoperability and energy management

Edge AI: Revolutionizing real-time data processing and automation

More Featured Contributions

EE TECH TOOLBOX

“ee
Tech Toolbox: Internet of Things
Explore practical strategies for minimizing attack surfaces, managing memory efficiently, and securing firmware. Download now to ensure your IoT implementations remain secure, efficient, and future-ready.

EE Learning Center

EE Learning Center

EE ENGINEERING TRAINING DAYS

engineering
“bills
“microcontroller
EXPAND YOUR KNOWLEDGE AND STAY CONNECTED
Get the latest info on technologies, tools and strategies for EE professionals.

RSS Current EDABoard.com discussions

  • Output return loss mismatch
  • CST Studio – How to increase frequency step size (e.g. to 100 MHz)?
  • What is the difference between MIMO antenna elements arragned radially across the pentagon shaped substrate versus rectangle shaed substrate?
  • General purpose CMOS Op Amp and PMOS & NMOS from LTSpice library
  • Simple Active Bandpass Filter Oscillates

RSS Current Electro-Tech-Online.com Discussions

  • Cpu coin acceptor and zero delay arcade board.
  • Capacitive Touch On The Profile
  • JBL charge 4 dead motherboard?
  • Guitar electronics project
  • can a AT89C51 be used as a rom?

DesignFast

Design Fast Logo
Component Selection Made Simple.

Try it Today
design fast globle

Footer

Microcontroller Tips

EE World Online Network

  • 5G Technology World
  • EE World Online
  • Engineers Garage
  • Analog IC Tips
  • Battery Power Tips
  • Connector Tips
  • DesignFast
  • EDA Board Forums
  • Electro Tech Online Forums
  • EV Engineering
  • Power Electronic Tips
  • Sensor Tips
  • Test and Measurement Tips

Microcontroller Tips

  • Subscribe to our newsletter
  • Advertise with us
  • Contact us
  • About us

Copyright © 2025 · 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