Matching non-volatile memory selection to automotive-system requirements


October 09, 2017

maheshcypresskishorekumar,-October 09, 2017

Designing vehicles has become more complex as automotive systems continue to integrate new functionality such as Advanced Driver Assistance Systems (ADAS), Graphical Instrument Clusters (GIC), HVAC, and Infotainment Systems. To ensure reliable and safe operation, each of these subsystems requires some form of non-volatile memory for storing some information during resets and power toggling. Non-volatile memories are used to store executable code or other important data like constants, calibration data, safety and security related information for future retrieval.

There are several different types of non-volatile memories in the market, including NOR Flash, NAND Flash, EEPROM (Electronically Erasable Programmable Read Only Memory), FRAM (Ferroelectric Random-Access Memory), MRAM (Magnetic RAM), and NVSRAM (Non-Volatile Synchronous RAM), among others. Each memory type has its own advantages and disadvantages over other memories in terms of different performance metrics: memory density, read/write bandwidth, interface frequency, endurance, data retention, current consumption at different power modes (active, standby/sleep, hibernate), soak time, susceptibility to external electro-magnetic interferences, etc.

To understand the real requirement of non-volatile memories in these emerging automotive systems, engineers need to consider real-world use cases like:

  • After starting a car, will drivers be willing to wait a few minutes before being able to drive for the cluster to boot-up and show the graphics related to speedometer, fuel quantity, etc.?

  • A driver has just made personal adjustment with respect to seating position, steering wheel position, temperature settings, and favorite radio channel and then has to quickly turn off the engine. How annoyed would the driver be if the car didn’t remember these settings before power to these subsystems was cut off?

  • A vehicle is in an accident despite having ADAS safety systems. Will you be able to provide the investigation team with the data they need, such as the state of different sensors the few seconds before the accident occurred?

In the case of ADAS systems, it is extremely important to capture real-time data of certain sensors instantly and store data in non-volatile memory. Similarly, Infotainment system settings need to be stored instantaneously to be able to retrieve them upon power loss.  Both GIS and Infotainment systems utilize high-end graphics and so require relative huge amounts of overlay data as part of the boot code sequence that needs to be stored and retrieved from external non-volatile memory.

Apart from meeting application-level requirements, non-volatile memories also need to ensure sufficient write-cycle endurance to log data for at least 20 years. In addition, achieve automotive grade certifications and qualifications, subsystems should also have AEC-Q100-qualified memory components.  Functional safety (ISO 26262) is another important aspect in these safety critical applications. 

ADAS Memory Requirements

ADAS systems are developed to automate/adapt/enhance vehicle systems for safer and better driving. Safety features are designed to avoid accidents by offering technologies that alert the driver to potential problems or avoid collisions by implementing safeguards and taking over control of the vehicle. Adaptive features may automate lighting, provide adaptive cruise control, automate braking, incorporate GPS/traffic warnings, connect to smartphones, alert driver to other cars or dangers, keep the driver in the correct lane, or show what is in the driver’s blind spots.

Figure 1. Block Diagram of ADAS System (Source: Cypress)

Figure 1 shows a simplified block diagram of an ADAS systems utilizing FRAM and NOR Flash. External NOR Flash memory is typically used to store the boot code. However, various sensors in the ADAS system send data to the MCU at regular intervals over the CAN (Controller Area Network) interface. The MCU runs adaptive algorithms to check if there is a chance of collision or if a collision has already happened. The runtime variables of processing algorithms and the current state of the sensors are stored inside the RAM of the MCU.

When the algorithm detects an accident, the airbag control module should deploy the airbag instantaneously using backup power to ensure deployment even in the case of power-loss during an accident. The state of the sensors during the accident should also be immediately stored to non-volatile memory for data recording. This information can be extremely useful to understand the cause of an accident so that automotive manufactures can deploy more advanced safety systems and insurance companies can determine whether a particular claim is valid or not.

Event Data Recorders (EDRs) are systems which capture data of different critical subsystems just before an accident happen. EDRs can either be part of the same ADAS MCU or a different MCU that receives the critical sensor data and communicates with the ADAS MCU. Today, multicore devices such as Cypress Traveo MCUs enable an entire CPU core to be dedicated to EDR functionality.

Continue reading on page two >>


< Previous
Page 1 of 3
Next >

Loading comments...