Car-borne data storage is becoming a vital aspect of cars, trucks and lorries as they get smarter.
Intelligent vehicles will use and generate a lot of data that needs storage inside the vehicle. Although early days, we can begin to understand how much storage could be needed, and its characteristics.
Let’s start by defining what we mean by an intelligent vehicle. This an autonomous or near-autonomous road vehicle, using IT to manage vehicle component functions and assist or replace the driver.
Steps to autonomous vehicles
The Society of Automotive Engineers (SAE) defines five levels of autonomy.
- L0 – none as human driver controls everything, except stuff like an engine fuel injection system
- L1 – a single driver process is automated, like auto cruise control or lane-keep assist
- L2 – Multiple driver functions taken over by IT, such as cruise control, lane-centring and steering and braking
- L3 – Conditional automation with human driver on standby to take over
- L4 – fully autonomous cars with no human driver control.
The higher the autonomy level, the more IT is needed, and the more data that needs to be stored. The data is generated by a car’s sensors, which can be outward-looking, like cameras, radar and lidar instruments, and also inward-looking, such as logged engine output, exhaust emissions and suspension spring rates.
The data can also be preloaded in the car; firmware for embedded computer systems for example, and sent to it over-the-air, such as map data for navigation systems.
Data generation
As yet, there is no consensus on just how much data intelligent vehicles will generate.
According to Mark Pastor, archive product marketing director, Quantum, autonomous test vehicles typically generate 5TB and 20TB of data per day. This figure is higher for test vehicles than that anticipated for normal operating mode.
Stan Dmitriev, an author at Tuxera which develops automotive storage systems, says autonomous cars will generate more than 300TB of data per year – less than 1TB/day.
Dmitriev has not published the number of hours per year but 300TB for 365×24 usage seems unrealistic. For the purpose of this article we will assume that this refers to 12 hour car usage per day.
He says cars at up to L2 autonomy can generate about 25GB/hour. That means 300GB in 12 hours – 0.3TB/day.
At CES this month Seagate highlighted that a single vehicle equipped with Renovo’s (AV software platform company) software can generate up to 32TB/day per vehicle. This is the headline number for data that will be collected and stored at the edge before being migrated to the cloud.
This is a wide, wide range, from 5TB/day to 32TB/day.
John Hayes, CEO of self-driving car technology company Ghost, said about the 32TB/day of data generation: “The headline data requirements are off by about a factor of 10,000.” He thinks Seagate and Renovo are talking tosh in other words and implies around 3.2GB/day is more plausible.
Keeping it safe
How the data is stored will depend upon the IT design in the car. This can basically be centralised, distributed or some combination of the two. A distributed design will need storage for each distributed computing element. A centralised scheme will have a central data storage facility, and a hybrid scheme will have a smaller central facility, and various storage elements in sub-systems around the car.
We’ll assume a hybrid scheme for now, with a main controlling computer for navigation and driving the car, complemented with subsidiary component ones for engine management, suspension and braking control, etc.
It is generally assumed an intelligent vehicle will be connected over-the-air to a remote host such as the manufacturer or a robo-taxi fleet operator, sending generated data to the host and receiving reference information such as traffic alerts.
The smart vehicle must make instant braking and steering decisions to avoid hazards and it needs to store information to carry out such real-time functions. The communications network cannot be assumed to be 100 per cent reliable and the car has to store generated data between uplink periods.
There could be minutes or hours of interrupted communications, or even days if the vehicle leaves mobile coverage areas for extended periods.
At Seagate’s high-end 32TB/day estimate of generated data, a 30 day storage period to cover extended non-uplink time would require 960TB capacity.
Mission-critical storage
The car’s central data storage system will be mission critical for what is in effect a mobile edge computing data centre. If it fails, operations can be compromised, causing loss of functions and even failure of the vehicle or an accident.
It seems intuitively obvious that disk drive storage is too unreliable in a car’s vibrating environment and wide temperature ranges. Also it is possibly too slow to retrieve data for instantaneous decision making. These issues indicate flash storage will be needed.
That is more expensive than disk. The mixed read-write workload and a vehicle’s operating life will make read/write endurance important. We can also see that, at the extreme data generation and storage period above, a 960TB SSD would add tens of thousands of dollars to a car’s cost.
A 30TB Samsung PM643 SSD costs $12,09.99 on CDW. We would be looking at $30,000 or so for a 960TB drive; that seems a totally unrealistic cost. The moral here is that data generation and its storage are going to need careful consideration by manufacturers,
Selecting components that can operate inside an automotive environment and store data for a vehicle’s lifetime will be crucial. (I’m driving a 13-year old car and that would blow an SSD’s warranted working life out of the water.) Initial mistakes can come back to haunt a manufacturer, as has happened with Tesla.
Tesla‘s data storage problems
Tesla has been caught out with limited flash endurance. InsideEVs reports that Tesla fitted a Media Control Unit (MCU) to Tesla Model S and X cars from 2010 to 2018. This controls the car’s main touchscreen and has a flash card soldered to a motherboard housing the NVIDIA Tegra Arm-based CPU. It is an 8GB SK Hynix eMMC flash card and stores the firmware for the system.
At launch the MCUv1 firmware was 300MB in size but grew to take up 1GB.
Car logging information is written to the flash card, and this fills the card up. That means there are no extra cells (over-provisioning) for use by the card’s wear-levelling function and the MCU’s functionality becomes affected. The web browser may not work, for example, or system startup could take minutes or even fail. The car is still drivable though.
As the cars developed the fault Tesla replaced the entire MCU board as a fix under warranty. Out-of warranty cars need a fix costing $3,000 or more by a Tesla support shop. The firmware and card were upgraded in 2018 to handle the logging load, and this MCUv2 has a 32GB flash card.
Tesla owners have set up a petition to replace MCUv1 units with MCUv2 ones. A Tesla owners’ forum also discusses the issue.
Poster DallasModelS said in April last year: “Love the car but I’m afraid that service centers have no empathy and are just cold. Just can’t make a product, you have to stand behind it. How does a MCU which controls 99 per cent of the function of the car fail in under 3 years?”
Tesla has been contacted for a comment.
