Driving design changes in EDRs

Article By : Harsha Medu

Advances in automotive electronics have substantially increased the challenges associated with EDR datalogging.

Event data recorders (EDRs), often called black boxes, are not new in automotive electronics. EDRs have been recording data in cars for almost 50 years. During this time, the electronics inside cars has evolved dramatically. And, with so much research into self-driving technology, even more changes are to come.

These advances in automotive electronics have substantially increased the challenges associated with EDR datalogging. It is therefore surprising that, in all these years, basic EDR design has not changed. A tear down of an early GM airbag controller has substantially similarity to the datalogging architecture used in today’s EDRs. Then and now the EDR waits for an event to trigger before logging the first data into non-volatile memory. This 1970s-era approach to datalogging has persisted while other subsystems within the vehicle have advanced through many generations.

In part, this situation exists because memories have not been considered central to EDR design. As a result, the limitations of EEPROM and Flash have, in turn, limited the capabilities of today’s EDRs. In this article we will address this perception and explore an alternative solution to advance datalogging so that EDRs can meet the reliability requirements of vehicles today and tomorrow.

What is driving design changes in EDRs?

New regulations in Europe and China mandating the use of EDRs in most classes of motor vehicles is adding new focus to EDR design. There is a common misconception that EDRs have been mandatory for a long time, but that’s not true. Even today, North America does not mandate use of EDRs. Nevertheless, use of EDRs has been widely adopted by automakers and is almost ubiquitous in North America. Europe and China are going one step further by mandating the EDR in certain categories of vehicles. In today’s vehicles, the sources of critical data are increasing and regulations are requiring larger amounts of data storage for better decision making.

Apart from regulations, there is also a genuine need to accommodate increased parameters in autonomous vehicles. For example, in L2+ partially autonomous vehicles (according the SAE levels of driving automation), there are more ways the system can store sensor and image data. But no single system can provide the complete picture of a critical event, especially a crash. So, it becomes imperative that some data from ADAS be stored in an EDR to establish the synchronization between ADAS storage and the EDR when analyzing the event.

Challenges in existing design

Let’s examine existing EDR design and understand the challenges in adopting new regulations. Figure 1 shows a typical Airbag control and EDR design.

click for full size image

Figure 1: Typical EDR Design. (Source: Cypress Semiconductor)

The EDR/Airbag controller monitors the sudden change in vehicle velocity and acceleration to identify the start of an event. Once the event is detected, the EDR collects data on multiple performance and safety parameters. Depending on the type and severity of the event, the EDR controller decides to log the record during the course of the event or after the event is over. Generally, during a crash, the main battery is assumed to be cut-off and power to the EDR controller is supplied by back-up capacitor. Hence, the data log would be powered by the backup capacitors.

A deeper dive into the architecture shows current EDRs use either EEPROM or data flash non-volatile memory to store data. Since these memories use page-based writes and have low write endurance (less than 106 write cycles), the EDR controller reserves a RAM buffer equivalent to the size of one EDR record to store the data locally. The RAM buffer is located within the MCU with a size ranging from between 8KB to 16KB to temporarily buffer data before it is written to non-volatile memory. Sampling would typically end 250ms after the event is triggered. After that, the contents of the RAM buffer are transferred to the non-volatile memory. Due to the slow write speeds of EEPROM and data flash, this process can take from a few hundreds of milliseconds to a second to store 16KB of data. The whole process is shown in Figure 2.

click for full size image

Figure 2: A typical EDR Data Logging example with EEPROM / Data Flash. (Source: Cypress Semiconductor)

The backup capacitors must be designed to provide enough energy to power the entire transfer. The capacitors are also used to power the airbag deployment. Of course, the main job of EDR controller is to deploy the airbag and protect the occupants. Therefore, in a situation when there is not enough backup energy, airbag deployment will be prioritized over logging data into non-volatile memory. Hence, relying on backup capacitance to log data puts data at risk. In worst-case events, through-hole, back-up capacitors may pop out of the board during accidents, risking the entire operation.

Another consideration, for data logging, the use of EEPROM and data flash non-volatile memory would add complexity. Since the data transfer to non-volatile memory takes place using backup capacitors which may not be always stable, the data integrity of the write process should be guaranteed. The easiest way would be a checksum but it adds time and complexity in firmware.

New architecture with F-RAM memory

Use of F-RAM as external non-volatile memory would allow an entirely different data logging architecture. It may not be obvious from the block diagram in Figure 3 as F-RAM would just drop-in replace a component on the board. But it allows development of a different firmware architecture whose benefits can be easily seen at system level.

click for full size image

Figure 3: EDR Design with F-RAM. (Source: Cypress Semiconductor)

F-RAM technology provides fast random-access writes combined with instant non-volatility and virtually infinite endurance. This eliminates the need for RAM buffers in the microcontroller to temporary hold the EDR record. EDR firmware can divide the memory in F-RAMs into multiple EDR records. One record will always be working memory while the rest are either empty or locked with event data. Data can be logged into working EDR memory continuously in a rolling buffer.

To understand the rolling buffer architecture, let’s say the working EDR memory can hold data for 10 seconds. If there is no event in 10 seconds, the data in working memory will be overwritten with fresh data. This is possible because of F-RAM’s virtually infinite endurance. This means that during events, when the EDR controller is still assessing the severity of the event and making decisions whether to log the data or not, the data is already stored in non-volatile F-RAM as shown in Figure 4.

click for full size image

Figure 4: A typical EDR data logging example with F-RAM. (Source: Cypress Semiconductor)

At the end of the event, the only decision the EDR controller has to make is whether to keep the log or overwrite the log. If the event is severe enough to keep the record, the EDR controller would lock the working memory into an EDR event record and use a new buffer in F-RAM as working memory in anticipation of the next event. The firmware flow is shown in Figure 5.

click for full size image

Figure 5: A typical firmware flow for EDR data logging with F-RAM. (Source: Cypress Semiconductor)

The other advantage is that the EDR data storage is a separate event which does not rely on backup capacitors. The EDR system can work with smaller capacitors while guaranteeing data integrity is not compromised. The firmware complexity in the microcontroller to manage memory and storage is also reduced. Table 1 shows a comparison between two architectures.

click for full size image

Table 1: EDR architecture comparison based on non-volatile memory in use. (Source: Cypress Semiconductor)

With mandatory regulations to implement EDRs with increasing demand for datalogs, the possibility of losing data should be taken out of the design and a safer and more reliable architecture for better data integrity should be embraced. F-RAM technology was developed specifically for mission critical applications like EDRs. F-RAM based architectures will meet the demanding requirements of next-generation EDRs purpose built for the most advanced automotive demands.

This article was originally published on Embedded.

Harsha Medu is senior staff applications engineer at Cypress Semiconductor. He has worked on design and application aspects of various non-volatile memory products and defined system solutions based on new products. He holds a Bachelor of Engineering degree in Electronics and Communication and a Master of Business Administration.

Leave a comment