Building automotive data logging with F-RAM flash combo

Advances in the automotive industry continue to make cars safer, more efficient, and more reliable than ever. As motor vehicles become more advanced, so do the silicon components that serve as the backbone of their advanced features. Case in point: the requirement for and proliferation of data logging systems is an item that has become increasingly prevalent.

In particular, event data recorder (EDR) and data storage system for autonomous driving (DSSAD) have been the source of significant attention due to recent worldwide legislation. While both systems function to provide safe and reliable storage of driving data, there are a few key distinctions (Table 1).

Table 1 Here is a comparison between EDR and DSSAD data loggers. Source: Infineon

As regulations governing automotive data logging evolve, so do the specifications for the associated memory that stores the data. For instance, in the United States, these storage requirements were recently revised to “extend the EDR recording period for timed data metrics from 5 seconds of pre-crash data at a frequency of 2 Hz to 20 seconds of pre-crash data at a frequency of 10 Hz”. These effects will be enforced on September 1, 2027, for most manufacturers with a few exceptions for altered vehicles and small-volume production lines.

Regulations such as these are not unique to the United States but rather echoed worldwide. Recently, the United Nations Economic Commission for Europe (UNECE) has sought to standardize automotive data logging requirements across its constituents with key pieces of regulation. These regulations provide guidelines for EDR in passenger vehicles, heavy-duty vehicles, and DSSAD as it pertains to Automated Lane Keeping Systems (ALKS). As these regulations grow and are adopted by constituents, the demand for hardware storage systems becomes paramount in the automotive industry.

Data storage requirements

The National Highway Traffic Safety Administration (NHTSA) in the United States gives insight into existing EDR solutions, describing them as having “a random-access memory (RAM) buffer the size of one EDR record to locally store data before the data is written to memory. The data is typically stored using electrically erasable programmable read-only memory (EEPROM) or data flash memory”.

This document also provides an overview of concerns and industry feedback regarding the requirement changes. The feedback indicated that “while the proposed 20 seconds of pre-crash data could be recorded by EDRs, some EDRs may require significant hardware and software changes to meet these demands”.

On the other hand, DSSAD requires storage of all events over a set period. While the previously referenced NHTSA document applies only to EDR, a similar solution could fulfill these requirements by buffering incoming signals before transferring them to long-term storage in a non-volatile memory.

Given the strain on current systems from growth in requirements, the quest for an optimized solution becomes pertinent. All things considered, the ideal system must provide power-loss robustness for buffered data and enough space for long-term storage. With these requirements in mind, this article will discuss how using F-RAM and NOR flash together meets the modern challenges of data logging.

Flash F-RAM combo

Ferroelectric random-access memory (F-RAM) stores information in a ferroelectric capacitor. The dipoles within this material—oriented based on the direction of applied charge—maintain their orientation after power is no longer applied. This type of memory is characterized by fast write speeds and high endurance (~10¹⁴ cycles).

These characteristics give F-RAM a unique advantage over other non-volatile memory technologies. However, densities for F-RAM are low, ranging from a few kilobits to tens of megabits, limiting its scope for high density applications.

NOR flash is another type of memory which uses a MOSFET to store electric charge within a non-metallic region of the transistor’s gate. This memory is typically more complex in its operation—for instance, the necessity of an erase operation—than F-RAM and may offer additional features such as password protection or a one-time programmable secure silicon region. NOR flash offers small-granular random access for reading but requires large-granular access to write operations.

Multiple bits must be erased simultaneously and then programmed in order to “write” to the device. Thus, timing for device operations is generally slower compared to F-RAM, and endurance is comparatively limited (~10⁶ cycles). However, NOR flash holds the advantage of a larger storage size, with ranges up to a few gigabits.

This article will showcase how F-RAM + NOR flash compares to RAM + NOR flash as a solution for EDR and DSSAD. For this analysis, data was logged in a ring buffer within the front-end device continuously. During event triggers for EDR or conditions where the buffer filled for DSSAD, the information was transferred to the back-end device, where the data was held in long term storage (Figure 1).

Figure 1 The block diagram shows front-end and back-end storage in a logging operation. Source: Infineon

To evaluate performance, Table 2 below uses requirements from both EDR and DSSAD for the comparison. These specifications for EDR and DSSAD were based on the UN regulations for heavy duty vehicles and for ALKS DSSAD requirements, respectively. To discuss how these systems work, it’s important to review the specifications from these documents and highlight the assumptions made by the comparison.

Table 2 The performance comparison between EDR and DSSAD is conducted across multiple technologies. Source: Infineon

For logging systems that use EDR, data elements are required to be logged continuously and transferred to long term storage solely in the case of an event, such as a car accident. A ring buffer in the front-end device accomplishes this effectively. To determine the size of this buffer, the expected EDR data rate is needed alongside the storage time requirements.

From the legislation, required parameters were used as a part of the calculation. The relevant time interval (commonly 20 seconds pre-crash data, 10 seconds post-crash data) and logging frequency (4 Hz, 10 Hz, or single instance) were also utilized for calculations. One important assumption was a fixed EDR data packet size of 12 Bytes.

The UNECE document has no requirement for using a set number of bytes for storage or for storing any information outside of the parameter data. This comparison assumes an 8-byte time stamp of metadata will be included alongside an estimated 3 bytes for parameter data and 1 byte for parameter identification. Using the previous calculations and assumptions, the expected buffer size was calculated to be 790 Kbits.

In the case of the event, the entire buffer would be transferred to the back-end storage. It is required that “the EDR non-volatile memory buffer shall accommodate the data related to at least five different events”. Thus, five events worth of storage were allocated, resulting in a back-end EDR buffer size of 3.95 Mbits.

On the other hand, DSSAD requires all data elements to be stored rather than a set amount of data within an event window. Therefore, a relatively small buffer can be used on the front-end which can be migrated to the back-end device once filled. It was assumed that the buffer must be large enough to store all events if a sector erase is in progress and must be completed before transferring the data to NOR flash.

For this analysis, the maximum DSSAD rate is assumed to be 10 events/second. Furthermore, each packet was estimated to be a fixed size of 25 bytes. This would include the time and date stamp (estimated as 8 bytes) and parameter data (estimated as 1 byte) which are required in the regulation, alongside the GPS coordinates (estimated as 16 bytes), which are not required but are included as metadata in this analysis. This results in a front-end DSSAD buffer size of 5.3 Kbits.

Meanwhile, for the back-end device, an assumption of 6 months of DSSAD data storage was implemented. The size of the back-end buffer is determined by the average expected DSSAD rate multiplied by the 6-month period. Using an estimated DSSAD rate 4 events/minute and the fixed 25-byte packet size, the back-end buffer was calculated to be 210 Mbits.

Memory endurance characteristics

The sum of the buffer sizes determined the required densities for each of the components in Table 2. For this analysis, the F-RAM and NOR flash endurance characteristics were demonstrated by Infineon’s SEMPER NOR flash and EXCELON F-RAM devices. Endurance was assumed to be infinite for the front-end SRAM device, but data packets are considered lost during a power failure as this is a volatile memory.

This comparison model attempted to find the smallest density that could meet a life expectancy endurance requirement of 20 years.  The results of this comparison are shown in Table 2.

As shown in the table, the critical F-RAM + NOR flash solution advantage is in the case of a power loss situation. The worst-case scenario is in a situation where buffered information in volatile RAM without using a back-up battery would result in the loss of significant vehicle data during a crash.

In this case, if an erase is required at the start of an event, the system could lose all 20 seconds of pre-crash data plus the 2.68 seconds of time it takes to perform an erase on a 256-Mb SEMPER NOR device if the power is lost as the erase is completed. The corresponding data lost is calculated based on the assumed EDR and DSSAD data rates over this time.

Despite the high rate of cycling through the ring buffer, the EXCELON F-RAM was able to meet the endurance requirements and match the life expectancy of the RAM + SEMPER NOR flash solution.

As far as other potential front-end solutions, it should be noted that using other non-volatile technologies for the front-end such as EEPROM or RRAM would potentially require higher density requirements due to the lower endurance capabilities compared to F-RAM. Furthermore, the fast write time of EXCELON F-RAM provides proper storage for data packets sent to the front-end device in the immediate time frame prior to a power loss.

Why memory matters in data logging

Given the growth of EDR and DSSAD and the legal implications associated with these systems, reliable data storage is paramount and therefore reflected in legislative requirements. For instance, the requirement of “adequate protection against manipulation like data erasure of stored data such as anti-tampering design”. While there are different ways to secure the logged data on a system, a simple and robust method involves hardware.

The future of autonomous driving depends on logging for legal records, safety, and cutting-edge features. As systems become more complex, memory technologies are frequently challenged for performance, requiring creative solutions to satisfy the requirements.

Kyle Holub is applications engineer at Infineon Technologies.

Related Content

• FRAM MCUs For Dummies
• Cypress Sees a Future for FRAM
• 7 Ways a Data Logger Can Save You Money
• Why FRAMs suit data logging in EDR for airbags, ADAS
• Why FRAM memories are suitable for data logging in ADAS designs

The post Building automotive data logging with F-RAM flash combo appeared first on EDN.