The Black Box In Auto Vehicles

Driving a modern car or truck today is like driving a complex computer system which has the scope to take people and freight from one geographic point to another through the infrastructure and, to do so, it just happens it has an engine and wheels.

Among the most significant developments in automotive electronics in the last several years is the inclusion of an EDR (Event Data Recorder) in every new vehicle. In layman terms, it’s referred as the “Black Box.”

The EDR, which sits on the CAN-bus, continuously receives data from several sensors and electronic modules assembled and cabled within the vehicle while its microcontroller (MCU) continuously logs around 5 seconds of data in non-volatile memory (R/W NVM) of floating gate type.

Among the most relevant is the data from accelerometers in the Restraint System Control Module, which sense abrupt accelerations and deploys the airbags if the acceleration intensity exceeds some threshold (measured in gravitational force). After one to three seconds following such event, the MCU stops logging the data in the NVM. The NVM will therefore contain the few seconds of data surrounding the event.

The few seconds of stored data includes wheel direction, vehicle speed, throttle opening, breaks activity, lateral and longitudinal acceleration. This data, once retrieved, (especially if collected in a public database of national scale, currently unavailable) is priceless to several entities, all aiming to improve vehicle standards, transportation infrastructure and human behavior toward higher safety levels. The primary users and beneficiaries of this data are automakers, insurance companies, regulators and authorities.

Long debates took place regarding the ownership of the recorded data. It was an extremely important topic that extended into privacy concerns. Regulators finally decided the data belongs to the vehicle owner and can be accessed by third parties only after the owner’s consent or, in absence of that, through court order.

In its simplest configuration, the EDR is composed of a MCU with NVM (mainly EEPROM or Flash) and with an interface to the CAN-bus. The stored data can be read either through proprietary readers of the vehicle manufacturer or through the standard Bosch Crash Data Retrieval (CDR). In both cases, the readers will connect to the CAN-bus via the On-Board-Diagnostic (OBD) connector, certainly available somewhere in the vehicle.

An additional feature, not always integrated, is the mobile communication chip set which connects to the cellular network, GSM for instance.

This feature is mainly advertised and recommended by the car insurance industry. In fact, for vehicles not equipped with connection to the cellular network, several insurance companies offer to the policy holder an additional EDR of simple installation that includes such a connection.

This connection sends real-time positional data to a Service Center that logs them and promptly responds in case of abrupt events the accelerometer detects, like a crash. Moreover, in case of a vehicle break down for instance, the driver can call the Service Center which will send help to the logged geographic location.

While the purposes and benefits of the EDR are unarguable, the regulatory standardization for its basic requirements allows automakers to decide on almost everything about EDR: features, architecture, data collection, software updates, localization within the vehicle body, etc.

The case for antifuse OTP in the EDR
In the EDR, the MCU firmware and software are either stored in ROM or in R/W NVM like EEPROM or Flash, which allow updates. The few seconds of data received from sensors and other ECUs are stored in EEPROM or Flash as described above.

The problem of accessing and modifying the code stored in R/W NVM is a security problem. Imagine the damage if maleficent intruders access the EDR and change the software or the data collected after a crash event.

Since the EDR can easily be accessed through the CAN-bus, the access itself should be verified and authorized via security keys. Security keys should be unattainable, such that unauthorized agents and intruders would not be able to modify the R/W NVM content.

Storing security keys in antifuse OTP (technology based on gate oxide breakdown) makes them unattainable as it’s impossible to visually detect (after delayering the silicon) the content of the single bit. That’s unlike OTP based on fuse technologies where the single bit is a broken or integral metal wire, thus perfectly visible.

Moreover, it’s quite simple for providers to implement techniques, including data obfuscation, that impede the detection of antifuse OTP content via voltage tampering, microscope scan (aimed to detect hot-spots that identify active vs inactive bits) or data tampering.

Another area where antifuse OTP can add value is the time immediately after a crash event. For reliability enhancements and data preservation, the crash data stored in the EEPROM or Flash could be immediately copied in antifuse OTP, which is immune from radiation and offers data redundancy through a technology different than floating gate. Here, a potential issue is the time required to write the OTP, which is around 4µs per bit, hence about half a second for 128Kbit.

Currently, antifuse OTP are available with capacities from a few Kbit to 1Mbit. And it’s quite straight forward to qualify these products for automotive grade 0 standards.

Thanks to their very low cost and their robust technology (currently available in 10nm), it’s evident that antifuse OTP is gaining traction and taking strong positions in the automotive market segment.