Meet Tuxera at CES 2020

Come and visit us at booth 1815 to discuss automotive data storage and see our demos.

CES 2020 is in full swing. This year, we’re proud to announce that we’ll be with AGL and GENIVI – and we’re super excited to talk to you directly about automotive data handling. As the leading innovator in data storage software for autonomous cars, consumer electronics, IoT devices, and data-driven enterprises, we'll be there to help solve your most complex storage challenges. At booth 1815, we'll have product demos and even a game for you to experience. 

Here’s a short overview of where you can meet us and what you can expect to see:

Automotive Grade Linux Showcase

January 7-10, 2020

Booth 1815, Stand B3

Westgate Las Vegas Resort & Casino

We’re working with car makers, Tier-1s and other suppliers in the industry to show how to maximize flash memory storage reliability, performance, and lifetime of IVI and cluster storage. Come meet us at the AGL Showcase to learn more about our flash memory testing service, which analyzes performance, level of fail-safety, durability, risk analysis, and lifetime cost of the entire automotive storage stack.

A fun spin on fragmentation

Get a new perspective on how file systems can affect the flash lifetime and performance in cars with Frag Fighters, our fast-paced game playable at the AGL booth and GENIVI. Beat the high score and you could even win some cool prizes. See some of the gameplay in action below.

*This post was updated on January 8th, 2020.

So if you’re around, drop by the booth and let’s talk about solving your automotive data storage challenges. Or contact us directly to learn more about how we can help you do more with your data.



Tesla troubles – averting automotive flash memory failure

Oops is an understatement here. Tesla’s got a problem with dead eMMC flash memory cards in Model S and Model X cars equipped with their MCUv1 (Media Control Unit). And according to InsideEVs, this dead part could cost more than $1,800 to repair! As reported in InsideEVs, the problem stems from excessive writing to a log file that’s causing flash wear. This, combined with the ever-increasing size of Tesla’s firmware (which has grown from 300 MB to 1 GB), leads to a situation where the MCUv1’s storage reaches its maximum endurance and fails.

A closer look at Tesla’s MCUv1 flash memory failure

An application in Tesla’s MCUv1 was writing and rewriting massive amounts of log data. But flash memory lifetime is limited by a finite number of write and erase cycles, typically in the tens of thousands. Over time in these intensive write-rewrite scenarios, the blocks in the flash memory storage eventually “die out,” making them unusable for storing any data. And when blocks fail, portions of the firmware file may become unreadable, which can lead to application crashes or complete failure of the MCU.

A lot of suggestions have been made which could have prevented the problem:

  1. Intelligent wear leveling

We caught up with our Technical Product Manager, Thom Denholm, to explain the wear leveling aspect in more detail. “Wear leveling describes techniques used to ensure even use of the blocks on flash media, with the purpose of achieving the longest possible lifetime of the storage.

The most basic wear leveling design is dynamic wear leveling. For each data write, the algorithm makes sure the block being written to is the least erased block. Unfortunately, this “quick and dirty” design has a flaw on most use cases that will compromise the lifetime of the flash. Any blocks containing data written only once (so-called static data) are left out of rotation for wear leveling. If a system contains a large portion of these static data blocks, that means fewer blocks available to balance the load. This could have perhaps been a problem in the Tesla case.”

Thom’s technical assessment of the situation is spot on! That said, even with good wear leveling at the flash management or file system level, the Tesla MCU would have still failed under such write and erase conditions. But proper wear leveling would have bought considerably more lifetime for the system.

  1. Retaining all the logged data in RAM

The InsideEVs article suggests that the logged data could instead be moved to RAM to essentially trick the system. This, however, would have drawbacks in poorer performance and the mere fact that logs would be in volatile memory. According to Joel Catala, our Director of Engineering, “This solution potentially defeats the initial intentions of the system designers, and might result in troublesome situations if the needed data isn't available in case of a crash.”

  1. The right grade of memory hardware

In a post on LinkedIn about the Tesla issue, Kevin Kilbuck, VP of Business Development for Longsys and Lexar comments, “As someone who has worked in the semiconductor memory industry for over 30 years, I can state emphatically that not all flash is created equal. There are many ‘grades’ of flash memory produced, ranging from low-end consumer grade, that is really only suitable for things like entry-level (cheap) USB drives and other consumer products, to enterprise-grade flash, which is utilized in high-reliability/endurance applications, such as write-intensive flash storage arrays.”

Kevin continues, “As others have pointed out, the hardware (controller) and software used to manage the flash are also important. That being said, it is not possible to take a low grade of flash and use it in a high-endurance application, no matter how robust your flash management is. The lower grades of flash have other failure mechanisms that error management software/hardware cannot correct. These lower grades are perfectly fine for the intended application, but not much else. I am in no way suggesting that Tesla tried to use a lower grade of flash than they should have, only that the silicon matters as well as the flash management techniques.”

  1. Putting the logged data on separate memory hardware

Sure, this could have solved Tesla’s problem. But memory hardware is costly and adds extra weight to the system, and there are better ways to solve the problem.

So what do we at Tuxera feel would have been the best solution to preventing Tesla’s MCU storage failure?

Go back to the basics – understand and test your entire storage stack

“Correct understanding of the memory devices (and their limitations), of software components such as data management (file system and flash management), and application behavior is key to designing systems that will be robust and survive the X number of years they are intended to live,” writes Joel Catala, our director of Engineering. This overview of the entire storage stack and all the data workload requirements must be done in the planning and design phase, not as an afterthought.

Joel continues, “At Tuxera, we've encountered issues like Tesla’s several times, and we are continuously collaborating with customers and partners on activities such as workload analysis, lifetime estimation, write amplification measures, and ultimately selection of data management software and storage devices.” Tuxera offers a Flash Memory Cost Analysis and Testing service to provide this level of understanding, and to help prevent memory failures.

Final thoughts

Let’s be clear. We’re actually big fans of Tesla over here at Tuxera (did someone say Caraoke? Yuss!). You can typically find a few Teslas in the parking lot behind our HQ here in Finland. But the Tesla MCU memory failure illustrates the need to fully understand everything going on in storage stack – from hardware, to software, to the use cases and potential workloads from when the car leaves the factory to 5 years from that date. These factors are the key to designing robust systems that will match the lifetime of the car.

We work with car makers and Tier-1 suppliers to help them choose the optimal storage hardware-software combinations for their specific use cases. Let’s solve your automotive flash memory challenges.


Using NVME over fabric in a centralized automotive storage architecture

Today’s automotive data storage architecture presents several challenges for OEMs in terms of cost, security, and serviceability. The various systems and ECUs in the car – infotainment, navigation, cluster, rear-seat entertainment, ADAS, EDR, and others – all have their own storage hardware. All these individual storages which are comprised of NVMe™, SSD, eMMC, or UFS hardware bump up costs. Consequently, the memory footprint of the autonomous vehicle is becoming very expensive – not to mention the added hassle of servicing and replacing the various storage components should they fail over time. What's more, the complexity of securing each storage device from harmful attacks or data theft is an ever looming issue.

Centralized automotive storage is the answer

Together with Marvell®, we’re working to simplify these challenges. At Embedded World 2019, we announced our cooperation with Marvell to bring scalable shared storage infrastructure to autonomous and connected cars. Combining Tuxera’s storage software expertise with Marvell’s state-of-the-art connectivity and NVMe over Fabric (NVMe-oF™) SSD storage technology, the companies are tackling the growing demand for high performance, reliable storage. Our joint proof-of-concept is a multi-purpose centralized storage infrastructure with minimal footprint on the hardware stack. Check out this video for an understanding of how centralized storage using NVMe-oF works. Marvell’s leading NVMe-oF SSD controller and networking switching technology ensures shared access to data to various ECUs. Coupled with Reliance Velocity – our high-performance storage management software – this centralized storage architecture is fail-safe, can share data between multiple operating systems, the flash memory hardware lasts longer, and the data is rapidly stored and accessed.

Potential use cases for automotive centralized storage

In theory, any scenario in which more than one system needs to access the same data or files is a potential use case for centralized storage. Map files are a good example, especially considering multiple data layers make the map files a gigabyte or more in size. To access those map files, the current on-board storage architecture requires two separate storages for a cluster and an infotainment system – which can add up in BOM costs. In the Marvell-Tuxera centralized storage architecture, only one storage is required to serve both these hosts, and they don’t even have to be running on the same operating system to access the shared map data. Another possible use case is for storing over-the-air (OTA) updates. ECUs use a module that connects to the cloud, then downloads the update to the on-board storage. But each system having its own storage for updates leaves multiple potential security vulnerabilities. With the Marvell-Tuxera centralized storage architecture, security is easier to manage. Only one storage would be needed to securely store the update from the cloud module, then provide the various update files to multiple hosts in need of an update. Car makers and Tier-1s are already approaching us asking how we can help them with their storage management needs in a centralized storage architecture. Use cases we’ve been consulted about are sharing data from cameras and sensors in ADAS or EDR systems. A large concern here is for data persistence in crash data collection. In this scenario, multiple hosts – meaning the various sensors recording data – need write access to one central storage.

Final thoughts

As the race toward level 5 autonomy presses forward, the amount of data any one car could potentially produce is growing at a colossal rate – to the tune of 380 TB to 5,100 TB of data in just one year. As it’s simply neither feasible nor entirely safe to push all this data to the cloud, vehicles need on-board local data storage. The message here is that local storage inside vehicles isn’t going away soon. And as ECU consolidation continues to be a trend into the future, it makes sense to begin consolidating the on-board storage as well. That’s why we’re partnering with leading hardware companies like Marvell, designing cutting-edge solutions to tackle tomorrow’s challenges in automotive storage. So come and talk to us at FMS 2019 at Marvell's booth, 511! Or get in touch with us for help designing a centralized storage architecture for your automotive projects.

Contact us

Tuxera presenting on data storage integrity at Flash Memory Summit 2019

Come see our presentations and a panel discussion on data storage integrity, managed NAND media failures, and automotive storage security at FMS 2019.

Flash Memory Summit in sunny San Jose is just around the corner. This year, we’re proud to announce we’ll have two speakers presenting, plus we’ll be part of an automotive session panel. If you’re headed there, please join us for our talks. Read on for all the details!

Presentation 1: Tomorrow's Data Storage Integrity and Safety for Autonomous Cars

Session title
AUTO-101-1: Tomorrow's Auto Safety/Security Requirements

Session time
Tuesday, August 6th 8:30 – 10:50 am

Bernd Niedermeier, Sales Director Automotive, Europe, Tuxera

With autonomous and connected cars becoming extremely data-driven, storage infrastructure plays a key role in the intelligent systems of vehicles. From black-box applications to running the operating systems, and transferring data from sensors, multiple critical features of autonomous vehicles highly depend on data stored on flash storage technology. From a storage perspective, risks can occur on multiple levels – including cyber security, data management software, and the storage hardware itself.

With so many potential risks, addressing the questions of safety becomes a first-priority concern. What happens if a hacker gets access to user-sensitive data? How can we ensure continuous stable performance of the flash hardware in mission-critical applications? And what happens if the flash memory cells prematurely wear out due to intensive data reads and write?

Join our talk as we discuss the challenges of autonomous data storage safety and integrity, and the steps that can be taken to reduce or prevent these risks.

Intended audience
Automotive system designers, hardware and software designers, engineering managers, system engineers and analysts, product marketing engineers, computer and communications specialists.

Presenter bio
Bernd is leading Automotive Sales in Europe at Tuxera, having joined from Operating System vendor QNX, where he was also responsible for state-of-the-art IVI, Cluster and ADAS programs for major tier-1s and OEMs. Over the last 30 years, he's held Sales and Sales Management positions at companies like Altera, Mentor Graphics, MathWorks, Altium/Tasking, working with customers to solve global challenges using cutting-edge products. Developing customer-based solutions in a wide variety of environments has made him appreciate the complexity of work on the customer side. Bernd has a degree in Electrical Engineering from the Munich University of Applied Sciences. Besides Sales and Technology, he also has a background in Communications Theory, and enjoys discussing automotive legislation.

Presentation 2: How to Detect and Handle SD and SSD Media Failures

Session title
SSDS-102-1: Enterprise SSDs

Session time
Tuesday, August 6th 3:40 – 6:00 pm

Thom Denholm, Technical Product Manager, Datalight (a Tuxera company)

Managed NAND media (SD and SSD) has failure modes which can be devastating to embedded systems. Even error-correcting codes and CRC codes can't eliminate all of them. Some of the most difficult to detect or correct include partially programmed pages, read disturb errors (known metaphorically as "bit rot"), metadata corruption, and stale data. The use of sequence numbers and a validation technique called Merkle Trees can help.

Intended audience
Executives, Engineers, End Users, Technology Journalists, Press, Technologists, Marketing Professionals, Applications Engineers, Entrepreneurs, Academics, Students, and other Researchers.

Presenter bio
Thom Denholm is a Technical Product Manager at Datalight, a leading provider of embedded file systems. He works on product planning and worldwide marketing of the software products, provides pre-sales support and technical assistance, and trains partners, channel participants, and customers. He is a frequent blogger on embedded systems and also does webinars and demonstration videos. With over 20 years of experience in the embedded space, he combines a strong focus on operating system and file system internals with a knowledge of modern flash devices. Thom holds a degree in Mathematics and Computer Science from Gonzaga University (Spokane, WA). He has spoken at many events, including past Flash Memory Summits.

Panel discussion:  AUTO-202B-1: Auto Roundtable (Automotive Applications Track)

Panel time
Wednesday, August 7th 4:35-5:40 PM

Session description
Evaluating the storage management challenges of the autonomous transportation ecosystem. What types of data do moving vehicles need from the physical environment – streets, roads, signals, signs – and in what form? How much of the data needs to be saved by the vehicle to "learn" so it can anticipate the wants and needs of the people and products being transferred? Will most of the data be held in the cloud and used while the vehicle is in motion, or should it be retained within the vehicle itself? Who will have access to that data, and who will be responsible for keeping it safe, secure, and private?

Panel Members
Doug Mitchell, Product Marketing Engineer MPS, Cypress Semiconductor
Ivan Ivanov, Distinguished Engineer, CoC Systems, Harman
Bernd Niedermeier, Sales Director Automotive, Europe, Tuxera
Michael Huonker, Engineer Advanced Head Unit, Daimler AG
Alan Messer, Chief Strategy & Technology Officer, InnovationShift

Intended audience
IoT, environment planners, developers, vehicle and system developers and planners, senior and engineering management for storage firms, Tier 1 and automotive producers. City and state transportation planners, as well as solution providers.

Meet us at Booth 845 during FMS 2019
You can also find us at the Flash Memory Summit Expo. There we’ll be demoing Reliance Velocity (formerly Tuxera Flash File System) – designed to bring ultimate performance, reliability, security, and longest lifetime to any flash hardware. It's also the only file system to reliably support all the major automotive operating systems. Visit us to compare Reliance Velocity performance and lifetime against ext4.

Let's talk more about your challenges when it comes to flash memory storage performance. Pre-book a time to see our demos at Flash Memory Summit, or drop by our booth 845 any time.

Request meeting

Tuxera acquires mission-critical embedded flash storage leader Datalight

Offers the most comprehensive storage management software portfolio available to the market

SEATTLE, Washington, and ESPOO, Finland – June 5, 2019 – Tuxera, the world-leading storage software and networking technology company, has signed an agreement to acquire Datalight, the North American developer of embedded file systems, and flash management and acceleration software.

The companies’ combined forces will now provide the most comprehensive embedded storage management software portfolio to meet the growing global demand for data storage. According to the International Data Corporation (IDC), these demands will grow to an estimated global datasphere of 175 zetabytes (ZB) by 2025. Meeting these global demands will require over 22 ZB of storage capacity across all media types from 2018 to 2025.1

Pushing the boundaries of data storage technology

Since 2008, Tuxera has been developing fail-safe, high-performance proprietary implementations of industry-standard file systems such as FAT, exFAT, NTFS, APFS, and HFS+. The company’s solutions have shipped in billions of consumer devices and vehicles to date. Tuxera also has its own high-performance file system, Reliance Velocity, as well as network storage and streaming software solutions.

“Together, we will continue to develop new features for our existing products and bring market-leading innovations in embedded storage. Our combined product portfolio addresses the full spectrum of storage management needs, allowing us to better support our customers’ current and future business and technical requirements,” says Szabolcs Szakacsits, President and CTO of Tuxera.

Datalight, founded in 1983, develops both flash file systems and flash management software, such as Reliance Edge, Reliance Nitro, FlashFXe, and FlashFX Tera. The company brings to Tuxera a deep understanding of technologies applied in flash controllers as well as file system technology used across many different embedded operating systems.

“We’re excited to join forces with Tuxera to create the industry’s broadest portfolio of data management solutions. Our shared experiences in “making it work” for our customers in diverse markets around the world gives us a common foundation on which to build innovative solutions to tomorrow’s data challenges,” says Kerri McConnell, CEO of Datalight.

All the leading expertise in flash management and file systems in one place

The engineering teams of the two companies combined now encompasses the top file systems and embedded storage experts around the globe. Their experience and understanding of storage technology covers any operating system or real-time operating system, any flash memory type, any hardware environment, and any interface, being either internal or external storage.

The merging of the two companies will bring significant benefits to any device, vehicle, or industrial products manufacturer with onboard or edge storage requirements. These benefits include:

  • comprehensive storage management support for a broad range of devices from deeply embedded (such as microcontrollers), to vehicles, aircraft, and spacecraft, and for all consumer and industrial IoT devices
  • improved file system performance, data reliability, flash memory lifetime, and hardware costs reduction
  • data storage support for both managed and unmanaged flash memory
  • industry-standard, fail-safe file systems like FAT, exFAT, NTFS, APFS, and HFS+
  • industry-standard file sharing protocol support such as SMB
  • flash memory quality and cost evaluation services


Transaction advisors

Nordhaven Corporate Finance acted as exclusive financial advisor to Tuxera. DLA Piper acted legal advisor, and KPMG acted as tax advisor.

Corum Group acted as exclusive financial advisor to Datalight, and Summit Law Group acted as legal advisor.


For more information, please contact:

Tiffiny Rossi

Head of Marketing, Tuxera


About Tuxera

Tuxera is the leading provider of storage and networking technologies. From the latest flagship smartphones, to cars, cameras, routers, and drones – Tuxera’s software makes file transfers fast, and content easily accessible. The company is an active member of multiple standard organizations, including JEDEC, AGL, SD Association, UFS Association, and many others. Founded in 2008, Tuxera’s headquarters are located in Finland, with regional offices in China, India, Germany, South Korea, Japan, Taiwan, and the US.


About Datalight

When data integrity, device lifespan and design flexibility matter, the world’s best-known device manufacturers rely on Datalight to enhance performance and speed time-to-market. Datalight’s flash memory drivers and reliable file systems improve user experience by boosting throughput, cutting file seek time, shortening boot time and eliminating data corruption in hundreds of millions of embedded devices worldwide. Datalight’s software, and expert consulting optimize solid-state storage for demanding product categories, including automotive, medical, retail, industrial automation and military/aerospace. Datalight is headquartered just north of Seattle, WA and has been developing embedded software since 1983.



[1] The Digitization of the World From Edge to Core, An IDC White Paper – #US44413318, Sponsored by Seagate.

Tuxera Flash File System security features

File system encryption ensures data security in connected cars

The growing demand for connectivity within cars exposes more and more critical embedded systems to security risks.

Car manufacturers and service providers are finding innovative ways to personalize our rides, or make in-vehicle purchases more convenient (some even automated – like toll booth fees). While these services bring a lot of value, they also demand that more private, personal data is stored inside connected cars. That means your car, if hacked, could essentially be a runaway credit card on wheels. Not to mention that embedded systems control the actual behavior of the car as well, and any compromise of these systems could lead to damage or harm.

A poll by American Insurance Group revealed that 75% of respondents expressed concern that autonomous cars, and even cars with autonomous features, could be hacked. Alongside these fears is the growing demand for connectivity within cars – even into deeply embedded automotive systems. As more critical systems become exposed to this connectivity, the security risks magnify. This means securing smart cars has now crossed far beyond securing just the physical networks on cars.

Whenever private, potentially sensitive data is handled, security measures must be in place to protect it from malicious attacks. So it makes sense that the software and hardware handling the storage of this information should have features that allow only authorized access to that data.

How is data inside cars handled and stored?

Storage management software – in particular, file systems – handles the data that goes to various storage devices inside connected cars. Just like what happens in your computer, file systems organize data into files, making it easy for applications to find stored data. But they also play an important role in storage read and write performance, flash endurance, data and storage interoperability, data integrity – and to some degree – data security. For a file system, security means ensuring that the data it handles is not misused and/or altered by unwanted parties. One security measure that can be implemented at the file-system level is encryption.

What is file system encryption?

Encryption is commonly used to prevent unintended access to information. Generally speaking, encryption works by encoding information in a way that only authorized parties with the right “key” can gain access to it. The file system can implement encryption in different ways, each having some effect on CPU performance and processing speed. During the encryption process, factors that play a role in CPU usage and efficiency are 1) the cryptographic algorithm, and 2) the encryption implementation itself.

  1. Cryptographic algorithms can be categorized into symmetric or asymmetric. Symmetric algorithms, as opposed to asymmetric ones, use the same secret key for both encryption and decryption. Symmetric algorithms have the primary advantage of efficiency and fast execution speed.
  2.  Encryption implementations include stream and block ciphers. Stream ciphers work on encrypting small bits of data at a time, so they are generally faster than block ciphers, which encrypt large chunks of data.

How do file systems handle encryption?

Encryption can be run through software, hardware, or a combination of both. In any case, some sort of software execution is needed. A file system can perform software-based encryption on files or directories. As an example, Reliance Velocity, encrypts file data, file names, and symbolic links (a type of file that contains references to other files or directories). We chose the AES-256 encryption algorithm for Reliance Velocity, or Advanced Encryption Standard (AES) with a 256-bit key. This option has several advantages:

  1. AES in general is one of the most accepted encryption standards, meaning it is a fitting choice for use in automotive software.
  2. AES is a symmetric cryptographic algorithm, so that generally entails less CPU to execute.
  3. The mathematical strength of a 256-bit key makes it virtually impossible to hack by attacking the algorithm itself. This means it’s a great choice for very sensitive files stored in today’s smart cars.

However, there is a potential cost for using such a strong encryption method. The AES algorithm is very fast and efficient, despite its status as a block cipher. But choosing such a strong cipher key (256-bit) requires more computational power. This could potentially drag down the CPU running the encryption algorithm.

How can hardware-accelerated encryption increase performance?

In cases where performance is a concern, or when a customer would have a specific requirement, the hardware can instead be used to accelerate the cryptographic algorithms. Benchmarks show that hardware-based encryption acceleration could be anywhere from a couple to several orders of magnitude faster than a purely software-based equivalent. Not to mention, research indicates that hardware-accelerated encryption makes it even more improbable an attacker can access the data.

That’s where Arm fits nicely into the picture. When our customers use processors with Armv8 architecture, we can configure our file system to use the Armv8 Cryptography Extensions. The Cryptography Extensions are special CPU instructions that give the software a sizable performance boost from the hardware to execute the process. In this way, the file system can keep the required level of read-write performance and provide rock-solid security measures to protect the data saved to the storage.

Although we’re unable to disclose any specific information about customer benchmarks, this is something we’re testing in our own R&D lab. However, some informal results online suggest that the Armv8 Cryptography Extensions do make an impact. One developer reports a speed boost of nearly 18 times with the hardware extensions enabled. When performance and safety are both critical requirements – which is increasingly the case in automotive applications – using hardware-based encryption acceleration may be worth the effort in implementation.

As we reach new levels of autonomy, the amount of data being generated, stored, and transmitted over wireless connections will only increase. At the same time, more critical systems within the car are becoming connected with each other and the outside world, bringing new challenges on how we keep data protected and vehicles secure. Tuxera’s file system encryption technology provides an effective solution to these security challenges, helping to enable the next generation of autonomous vehicles. Tuxera Reliance Velocity file system features encryption at multiple levels – learn more about our state-of-the-art file system here.

* This post is also available at Arm's blog.

Autonomous and ADAS test cars will generate over 11 TB of data per day

Autonomous and ADAS test cars generate hundreds of TB of data per day

In one of our most popular posts about data, we reported that an autonomous car will generate over 300 TB per year. That figure was based on the driving habits of the average American. But there’s a vast stream of data currently being generated by autonomous test vehicles every day all around the world. Take for example, Waymo, the self-driving technology development company. They reported that their test vehicles logged over 8 million miles (nearly 13 million kilometers) on public roads during 2018 alone, all the while collecting data using onboard sensors.

Calculating test vehicle data-storage needs

Pinning down exactly how many hours per day these test vehicles drive is difficult, as Waymo did not disclose its fleet size. Forbes reporter David Silver estimated that 200 vehicles driving 8 hours per day at 15 mph would match Waymo’s reported mileage rate. Plus, as we reported in our earlier post, the sensors in an autonomous vehicle record between 1.4 terabytes (TB) to around 19 TB per hour. Combined with the Waymo estimates, we can calculate conservatively the amount of data generated by one autonomous test car ranges between 11 TB and 152 TB per day! Multiply that by an estimated 200 vehicles in Waymo’s fleet—that means Waymo probably needed to store anywhere from 2.2 petabytes (PB) to 30.4 PB of sensor data per day for their entire fleet in 2018.

Volume of data created by autonomous car sensors – Tuxera
Adapted from source: Stephan Heinrich of Lucid Motors

And this is just the hypothetical amount of data generated and stored by one company in 2018. The amount of sensors and data generated in these test scenarios has only continued to multiply since these 2018 figures. The numbers for one test car today are probably on the order of hundreds of terabytes.

It’s also worth mentioning that ADAS testing is not limited to Waymo. All the major car companies and suppliers across the globe also test drive vehicles with varying levels of autonomy, each collecting data of its own to store, process, and analyze.

Storing autonomous and ADAS data brings new challenges

As autonomous vehicles take advantage of various technologies used in advanced driver assistance systems (or ADAS), testing in this area is broadly categorized under ADAS research and development.

This R&D work brings new challenges in storing the massive volumes of data produced by test cars. These vehicles generally have a huge PC platform in the trunk, loaded with tens or hundreds of terabytes of storage provided by flash solid-state drives (SSD). The SSD arrays are swapped out for new ones as they fill, while data from the used SSDs is transferred to a server rack.

On top of the sheer volumes of data, the dispersed nature of the data collection and storage adds another layer of complexity. Test engineers pool data from tens or hundreds of these roving vehicles distributed across many different locations. Under these conditions, it would be much harder to guarantee the fleet’s data is always available for processing and analysis using traditional storage methods. This would require duplicating the data in the servers at each location—which would get extremely expensive.

Not to mention, there’s a lot more to ADAS and autonomous R&D than simply driving test vehicles on actual roads. A lot of simulated driving also goes on in the lab, using algorithms and input data to test and teach vehicles. Methods like software- and hardware-in-loop testing (SIL and HIL) allow test engineers to feed collected sensor data to ADAS software or hardware to see it how the system behaves.

Car makers and Tier-1 suppliers – find out how we can help you store and manage autonomous vehicle data.


This post was updated Dec 2021 to reflect the latest data trends and information.

File system fragmentation

Could fragmentation be your storage performance bottleneck?

It’s important for car makers and Tier-1 suppliers to choose their file system implementations wisely. File systems impact read and write performance of the storage, the integrity of the data stored, flash endurance or the lifetime of the memory hardware, and data and storage interoperability. Specific factors that affect file system performance include file size, device partitioning, or the file system implementations themselves. One additional factor Tuxera is currently testing is how fragmentation affects flash performance and lifetime.

What is fragmentation?

Fragmentation happens when a file system lays out files in non-contiguous parts, or fragments. It generally occurs because there’s no space left to write new file content next to older file content. Some recent groundbreaking studies into flash memory performance have shown that fragmentation is a bottleneck for or cause for degrading performance. It’s also a factor we’ve currently been testing in our performance benchmarking lab.

File system fragmentation infographic

What are the potential impacts of fragmentation on user experience?

Our automotive customers and partners come to us because they suspect the file system could be a root cause of problems such as frame loss, latency issues, and other performance concerns. Fragmentation affects the long-term performance of flash storage. In applications with intensive reading, writing, and rewriting of data, (such as cameras for autonomous driving) fragmentation may cause anything from small errors to critical system failure. If the storage is full and heavily fragmented, there will definitely be read/write issues. This can’t happen in a mission-critical system where safety and lives are concerned.

In the case of infotainment systems, performance loss due to fragmentation boils down to concerns over user experience and customer satisfaction. If the in-vehicle infotainment (IVI) storage is heavily fragmented, this means longer wait times for music and navigation apps to launch and be available to use. A minor inconvenience, but user experience is no small issue when it comes to differentiation for auto makers in the coming years.

So what's the answer?

Data-driven cars of tomorrow need intelligent storage software design today. Get everything you need to know about file system fragmentation—what it is, how it impacts storage performance, our research and test results, and how to solve it in our whitepaper, "The Impacts of File System Fragmentation on Automotive Storage Performance."


Tuxera developer book recommendations

Book roundup: basics for aspiring QA engineers and embedded developers

Looking to brush up on some skills? We asked our developers to suggest some books to help budding embedded and Linux kernel developers, and here's what they recommended:

"Just automate it"

Tuxera: books for embedded developersPro Bash Programming
Scripting the GNU/Linux Shell
by Chris F.A. Johnson

“I suppose the age-old thought-sapping phrase 'Just automate it' applies. If you find yourself doing one thing a lot, it can probably be automated into a script. For example, if you are 'grepping' lots of values from many files (like test results) and you want them to be displayed in a table quickly on the terminal, you can write a solution for that. Or when you are doing testing and you need to create a specific environment many times, you can have a script that sets it up quickly without your attention required."

Mikael Heino, Software Engineer in Test


Get deeper under the hood

Tuxera– Book recommendation for embedded devsThe Elements of Computing Systems
Building a Modern Computer from First Principles
by Noam Nisan and Shimon Schoken

"For quite a long time in my career as a software engineer, I had a very vague idea how computing systems work at levels below the application software that I was working on. Studying such topics as 'Operating Systems' or 'Instruction Set Architecture' seemed like an enormous task to me. Recently, I came across the book 'The Elements of Computing Systems' and the corresponding Nand2Tetris course. The idea of the course is to build a computer (both hardware and software) by yourself from the very basics and learn a little bit about every level of computing systems in the process.

As the name suggests, the course starts with an introduction to Boolean algebra and logic gates—the most basic devices that are used to build all computers today. Then we continue with building more complex circuits, including the CPU. After we implement all the necessary hardware for our computer, we start writing software for it: assembler, compiler, virtual machine, operating system, and finally, applications. At the end of the course, we have a computer that is able to run games such as Tetris!

Every chapter in the book covers a particular topic and includes a practical exercise where we implement some piece of hardware or software for our computer. To a certain extent, they resemble actual hardware and software found in real computers. As a result, operating systems, compilers, and assembly languages are no longer a black box to me, and I am not afraid to look under the hood if a need arises!"

Rostislav Skudnov, Software Engineer in Test

If these topics interest you, we’re always on the lookout for great talent! Check out our careers page for open developer positions.

Tuxera Careers

Tuxera – Automotive data storage and handling interviews

Automotive data storage and handling—now, the future, the challenges, and the risks

What better place than The Motor City—Detroit, Michigan, USA—for some serious car talk? At the 2018 TU-Automotive conference in Detroit, we had the privilege of interviewing experts from Harman, Renesas, Western Digital, and WirelessCar about data storage and handling in connected and autonomous cars. These companies are leading the way to help car makers store, process, secure, and create meaningful consumer services from all the data generated by connected and autonomous cars.

Watch the video to learn about the state of automotive edge storage now and in the future, plus get an idea of the various challenges with collecting and storing data across the industry.



Below you’ll find more about each company, and a transcript of the interviews.

John Buszek, Director of ADAS & Autonomous Driving Systems at Renesas Electronics

We asked John to start off with a brief intro to what Renesas does. Here’s what he had to say:

“We’re a semiconductor manufacturer invested in all different types of industries, but especially automotive. We're actually the largest manufacturer of automotive processors of any company in the world.”

John Buszek, Renesas Electronics

Tiffiny: “How many different storages are in a car rolling off the lines today?”

John: “Well, there's all different types of storage. From the microprocessor perspective, some are in the chip, some are external to the chip. And when you think about how in 2016 we actually shipped over a billion processors, you're looking at at least a billion instances of storage in 2016.”

Tiffiny: “What do you think about in ten years from now?”

John: “I think you might see that reduce a little bit. The amount of memory might not reduce, but how discrete it is—how many locations might reduce. I think you will see a trend, it's hard to say how much, of a lot of electronics dispersed throughout the car—distributed architectures—you'll see them become centralized a little bit to offer some cross benefits: some ease of engineering in the vehicle.”

Oded Sagee, Senior Director, Devices Group at Western Digital

Oded first gave us a quick intro about Western Digital:

“Western Digital is one of the largest storage companies in the world, storage being media for storing data. We have a very wide portfolio of products ranging from hard drives through solid-state drives. I specifically am responsible for our embedded solutions—those are the small chips that go inside mobile phones—but obviously automotive subsystems today is a big growing market for us, plus surveillance cameras, and home devices.”

Oded Sagee, Western Digital

Tiffiny: “How many different storages are in cars rolling off the lines today?”

Oded: “Today we're still kind of leaning on design that started three, four years ago. In most of the cases, cars today have one storage device mainly for the infotainment and maps, although there are some cars already out there today with up to three storage devices. Some of the emerging technologies already deployed are obviously over-the-air gateways that have storage for firmware updates, and some digital cluster applications have the storage separate from the entertainment system. However, into the future, we're already now working on designs for cars that have five storage devices inside. So that's growing and expanding as we move along.

Tiffiny: “What about ten years from now? Will there only be a few?”

Oded: “Even in ten years, I think we're going to see all all sorts of types of vehicles. At a high-level we're going to have fleet vehicles, which are going to have a certain architecture of storage. We're still going to have consumer high-end and mid-range cars with different architectures, and we're going to have some fully autonomous cars. In between these three segments, I would say some are going to take a centralized storage approach with virtualization and hypervisors, but some are still going to have these subsystems with different storage devices. We may see those devices being shared in some form or shape, but still separate devices for subsystems.”

Tiffiny: “What are the biggest technical challenges in storing all this data in self-driving cars?”

Oded: “I don't know about self-driving yet. I think it's pretty far out, but in between now and full self-driving, the biggest challenge is obviously forecasting or foreseeing the future. There's still a lot of work to be done to determine what is the use case, how is data being used in the car, and how is data being used between the car and the cloud with all the connectivity and the data monetization that is going on. So identifying the use case—really understanding how it works—is our biggest challenge.

But then the other challenges that we have are obviously around the environment. The vehicle is obviously operating under a wide range of temperatures. It's a moving device, so between the mechanics and the temperature, that's probably our biggest challenge: how do we build devices that operate in these conditions, and then how do we build devices that keep the data in shape for a long time under these conditions. Those are probably the biggest challenges in the automotive space.”

Jason Bartley, Customer Program Manager at WirelessCar

First off, Jason’s brief intro to WirelessCar:

“WirelessCar is a connected car platform and services company. We started in the late 90s, launched our first program with Volvo cars in 2001, and in the last 16 years we've launched 13 different OEM programs.”

Jason Bartley, WirelessCar

Tiffiny: “What are the biggest technical challenges in recording and storing all this data that's coming in from connected cars?”

Jason: “That's an interesting question. There are certainly a lot of those challenges. To me, the fact that we're getting more data and more complex data all the time makes us really analyze what database and storage technologies we're using. Plus, how do we relate the data, but do that in a way that we still anonymize, abstract, and protect the data so that we are certainly mindful of the customers rights and compliant with regulatory requirements such as GDPR, which is now an official requirement in the European Union. I think those are the biggest challenges we have these days.”

Dvir Reznik, Senior Marketing Manager, Automotive Cyber Security at Harman

Dvir’s quick intro to Harman:

“Harman is the leading Tier-1 company for the automotive industry. We develop a lot of software and hardware for the automotive industry, starting from digital cockpit solutions, to automotive cloud, telematics, UX, obviously the well-known brand audio from JBL and Harman Kardon—which we integrate into the vehicles—and cybersecurity. So, we do a lot of very cool stuff for automotive, and now for the past year with the Samsung acquisition, we're really building up on those synergies and offering the OEMs ever greater possibilities and technologies for their vehicles."

Dvir Reznik, Harman

Tiffiny: What's the biggest challenge in securing all this data for connected and smart cars?”

Dvir: “I think that it's the unknown. Protecting anything unknown. Because from our perspective, you must have visibility into any type of security-related event that's happening in the vehicle. And this is certainly something that we're pushing with the OEMs and working with the industry to get more information out. I think that moving forward, you would definitely need to be more aware of what types of data are coming out of the car and how will we keep them protected.”