Automotive software and optimizations

The power of scale—how software optimizations make cars more affordable

The most expensive module of the car is not the engine, it’s the electronics. This might come as a surprise to many, but more than 30% of car costs go directly to the electronic parts. There are somewhere between 80-160 microcomputers (ECUs) onboard of the car, and they all need a reliable connection in between. This results in more than 20 meters of cabling all over the automobile, and added to that, cars have dozens of sensors—all of which create extra costs in car production.

With cars becoming increasingly connected and data-driven, in-car electronics systems only get pricier, getting closer to the 40% margin of the cost. These factors generate a growing demand to find cost-efficient solutions, in order to make next-generation features, like level-3 autonomous functionality, affordable for the average consumer.

The core requirement for cutting the costs is to fundamentally change how electronics purchasing happens within the industry. The common process is to go “hardware-first”, meaning that the electronics elements of the car are determined initially, and only afterward, software options are evaluated.

To achieve a better result-per-buck, car manufacturers must rethink this process, as in many cases it is the software stack of the architecture that determines the end performance of the system. That doesn’t mean that car manufacturers need to go all-in with the software-defined approach just yet. But it does create a requirement for OEMs and Tier-1s to lead the change and to evaluate both software and hardware right from the beginning of the electronics architecture design.

A combined approach to electronics architecture design brings multiple benefits, such as:

  • Lower requirements for the hardware
  • A more robust long-term performance of the system
  • Possibility to integrate hypervisors and to consolidate ECUs

Such improvements directly affect the end cost of the car electronics, but also ensure automotive-grade reliability for the whole system, as all elements of the hardware and software architecture are developed more in sync.

A good example is the storage infrastructure of autonomous vehicles, where computer vision sensors, such as LIDARs and cameras, can generate up to 11 TB of raw data in just one day. This makes the “black box” architecture of the car an increasingly important part of the production vehicle design. If going with a hardware-first approach, choosing H265-codec compatible hardware might be a slightly more expensive decision and may be overseen, but it cuts the recorded end-size video files by half. This results in substantial savings in edge storage needs for the car. Something like this might seem obvious when looking from the bigger picture, but if approached without the whole software and hardware architecture in mind, could be easily missed—resulting in increased costs of the car electronics.

Optimizing software for hardware

To achieve even better performance for the use case, the software stack of the architecture must be optimized to ensure that it uses hardware at its maximal potential. For example, here at Tuxera, we do enhancements between the flash storage of the car and the storage software (file system), optimizing the whole storage stack for a specific use case. This allows us to prolong the lifetime of flash memory, while maintaining a sustained level of high performance for the storage. In some cases, lifetime optimizations can reduce the long-term storage costs by up to half, while the performance increases allow for more affordable solutions in the storage infrastructure blueprint.

Similar optimizations can be applied for multiple elements of the car, bringing improvements to overall performance and stability of the system, and providing extra opportunities for costs consolidation.

Achieving such optimizations and software improvements can be quite a manual task, as it requires a lot of hands-on testing in the process. Despite being a large investment in the development phase, in-depth optimizations, software improvements, and fine testing create a software-hardware architecture that takes advantage of the scaling and saves in the end costs for each production vehicle.

Final Thoughts

Including software in the initial architecture design will lead the way for efficient automotive electronics, making room for more affordable connected cars. However, in the long-run, consolidation will be predominantly software-defined. The reason is simple. The future of transportation lies in data-driven and autonomous vehicles, and it is the software stack that sets the requirements in such use cases.

Car makers need to embrace this change on all aspects of the car design and should actively follow and implement the latest software developments, as only then highly intelligent autonomous vehicles will get to market at a consumer-friendly price.

Car makers and Tier-1 suppliers, discover how we can help you save on BOM costs.


Tuxera – What ECU consolidation means for automotive storage

What does ECU consolidation mean for automotive storage?

Since the 1970s, the way to add new capabilities into the car has been to add an electronic control unit (ECU) for each new feature. ECUs give us convenient features such as electronic mirror controls, but some take care of many of today’s safety-critical systems like anti-lock brakes. Over time, the number of ECUs inside a car has grown to over 100 in top-of-the-line cars.

Understandably, we’re reaching a point where the number of ECUs is exceeding the finite space able to house all the electronics and associated cabling required to connect everything together. Not to mention the costs—the cabling to network all these ECUs is the third most costly car component. Thus, a movement to consolidate ECUs began sweeping through the automotive industry. As cars become smarter and increasingly autonomous, this trend toward consolidation continues, but it’s not without challenges.

Consolidation is complex, all the way down to the storage

Consolidation has been a complicated issue to solve, with software being a large part of the complexity. Traditionally, ECUs used real-time operating systems (RTOS) to run their various tasks and interfaced with simple EEPROM or NOR storage to do only a few bytes of writing when required. However, today, some safety-critical ECUs (for example, driver assistance systems or event data recorders) handle much more complex functions such as object recognition and sensor fusion. These systems are doing very intensive data writing to large-capacity NAND-flash storages built on eMMC, UFS, and PCIe flash standards. At the same time, we’ve seen overwhelming growth of Linux and Android OSes inside the car, especially in infotainment systems.

The core goal of consolidation is to reduce the amount of hardware. This goal is facilitated through virtualization of the hardware using software, usually using a host/guest OS architecture. Such architecture can be enabled using a hypervisor layer to share the hardware for each “parallel” OS, or by simply running virtual machines inside the host OS. In many vehicle domains, conflicts are created by mixing safety critical and non-safety critical systems together. The most common example is the consolidated cockpit, where the safety-critical cluster (running an RTOS) and the IVI-system (running Linux) are sharing the same hardware—including storage.

Storage software differs across platforms

The biggest challenge that arises from this shared storage access is the file systems for the chosen RTOS. File systems play an important role in storage read and write performance, data integrity (or fail-safety), flash endurance, and data and storage interoperability. Generally, RTOSes do not have very sophisticated file systems and data storage functionality. And even in the case that an RTOS file system is well developed, these RTOS file systems are vastly different than those used in Linux or Android.

In a virtualized, consolidated ecosystem, it takes a lot of additional effort to know how the file systems work, especially if there is integration, debugging, and optimizations to be done. Auto makers would need many experts within the company to do the integration and optimization work, because deep familiarity with many different systems is required. Plus, testing and validation of the end-product is harder when there are different file systems present. Not to mention there is a huge difference in features that file systems offer and how they’re implemented: encryption and compression are good examples which can be implemented in many different ways—either built in to the file system or as separate modules. There aren’t common APIs to do this all this.

The only file system that makes consolidation easier

But there is one file system solution that bridges the gap between all these various operating systems. Reliance Velocity is our premier embedded data storage engine, designed to bring the ultimate performance, reliability, security, and longest lifetime to any flash hardware—whether it’s UFS, eMMC, SSD, or SD. It is also the only file system to reliably support all the major automotive operating systems including, Linux, QNX, Android, and Green Hills Integrity. Reliance Velocity also brings support for complex file system features such as encryption, compression, and health monitoring to all of the supported platforms unlike ever seen before.

At Tuxera, we have a long history of providing interoperable file systems in the automotive industry. Because of our solid reputation, our customers rely on us for help in these complex consolidation efforts. We handle the storage integration across all these various operating systems, achieving the best data read and write performance for each component accessing a shared storage.

Auto makers and Tier-1 suppliers: get more technical info about Tuxera Flash File System.


Tuxera – Cars driving have black boxes with file systems inside

Protecting precious cargo – how car black boxes store data

Despite what some people believe, the black box inside your car doesn’t serve up a steady stream of data to some overlord who’s tracking you. It’s there as a benefit. With the data collected from black boxes, safety analysts and accident investigators can evaluate how cars perform in crashes and ultimately design safer cars.

The black box – or more technically, Event Data Recorder (EDR) – is a small computer in your car that stores data before and during a crash. Its main requirement is ultimate durability in order to preserve data integrity. To this end, the case enveloping this small computer is made of hardened steel that can withstand a variety of crash conditions. Plus, all the electronics and hardware inside must meet durability and performance requirements.

The type of data collected by the EDR depends on your government’s regulations and the level of automation of your car. Vehicle speed, braking, engine RPM, location, radar, LIDAR, and video streams from various cameras are just a few examples of the event data possibly stored inside EDRs. With all this data at hand, accident investigators can piece together the details of the incident. They can tell whether defensive maneuvers were taken, like braking and throttle decrease, or if there were other vehicles or objects in the proximity.

But how does the black box preserve the data so investigators can retrieve and analyze it?

What goes on inside the box

First, the EDR needs to know when to start recording and save crash data. Some EDRs record the data continuously until the power is cut (for our purposes, this means a crash occurred). Other EDRs are triggered by sensors that detect crash-like events, such as sudden changes in wheel speed.

Just like a computer, the EDR has some basic elements needed for storing data: memory hardware to hold the data, file system software to save the data in a standardized format, and an operating system (OS). The OS is the interface between the various sensors outside the EDR, and the file system and memory hardware inside the box.

The primary memory hardware inside today’s EDRs is typically a flash memory chip, such as eMMC (embedded multi-media controller) or UFS (universal flash storage), or sometimes an SD card. The operating systems used in EDRs are typically real-time operating systems (RTOS) or Linux.

So how is the data saved during a crash?

Working in between the OS and the hardware, a file system saves the data to the memory. When the sensors detect a crash event, the operating system instructs the file system to get to work! In a matter of milliseconds, the file system neatly organizes and structures all the incident data onto the memory hardware in a standardized format.

After an incident, an investigator can connect the EDR to a laptop to see what data was stored. The file system software on the investigator’s laptop would interface with the corresponding file system software on the EDR, and thus the data would be easy to find and sort through.

What file systems are used on EDRs?

The most common file system found on EDRs running RTOS is FAT (File Allocation Table), because it’s designed for simple folder structures – which suits RTOS well. It’s not the best file system for handling video data, however, because the file size with FAT is limited to 4 GB. Lengthy, high-quality video files, such as those saved in a continuously recording EDR, will easily exceed that limitation. exFAT (Extended File Allocation Table) would be a better choice of file system in this case because it can handle large file sizes. For Linux-based EDR systems, FAT, exFAT, and ext4 (fourth extended file system) are the most commonly used file systems.

How file systems make a difference in EDRs

There’s an issue with these tried-but-true file systems, however. They were designed for decades-old hard disk drive (HDD) memory technology. And as I explained above, modern cars use flash memory technology in the EDR. Flash memory has some unique challenges, such as degradation over time. As it turns out, the file system can play a large role in flash memory degradation. Especially for Linux-based EDR systems, we recommend a flash-friendly file system that reduces the factors leading up to memory degradation, such as Fusion File Share by Tuxera (formerly Tuxera SMB).

Final thoughts

To sum up, the black box's reason-to-be is to preserve a very precious cargo according to our modern-day terms: data. The file system inside plays a major role in that function – ensuring the data is intact and easily accessible after an incident. Once data has been analyzed, we get a broader picture of all the various crash scenarios and conditions, and vehicle performance under those conditions. In turn, governments and car manufacturers get valuable information to pass better safety regulations and make safer cars for everyone.

We preserve data integrity in today's connected cars. Car manufacturers and Tier-1 suppliers, find out how:

Go to Tuxera's automotive solutions

Tuxera – Software for Industrial PLCs

Smart factories are moving to Linux – here's why

Tuxera visited Nuremberg, Germany for the annual embedded world exhibition and conference. Although the hot topic on the floor was IoT security and safety, the event had a hidden gem of insight for those working with embedded software:

Linux is now gaining a foothold as the operating system for industrial processes.

From the Industrial Era to the Linux Era

For years, the industrial sector has lagged behind in terms of processing power and memory capabilities. The reason: the processors used in manufacturing and industrial environments – programmable logic controllers (PLCs) – only needed to do one or a few tasks. Thus, because there wasn’t any pressing need for complex “brains,” PLCs ran application-layer tasks using real-time operating systems (RTOS) or even no operating system at all (otherwise known as a bare metal environments).

But that’s changed.

Today’s manufacturing processes are smarter and more data-driven than ever before.  Data from multiple sensors pours in from various points throughout the process delivering info on the line speed, environmental conditions, equipment conditions, and more – plus the machines also communicate and share data between each other. To crunch, store, and share that data, that takes an operating system, along with a way to store the data. Because Linux is the go-to OS for embedded systems, it makes sense that the industrial sector would eventually follow suite.

Industrial PLCs have very demanding requirements due to the harsh extremes and safety concerns in these environments. The hardware needs to withstand temperature extremes, vibration, and have a long lifetime. Likewise, dependable software is a must-have. Linux has proven itself so far across every industry – even in automotive where environmental and safety demands are most taxing.

Final thoughts

Today’s smart factories need resilient hardware and software to boot. All the data used to make manufacturing operations more efficient needs reliable, fail-safe, and power-safe storage management – and that means more than just the hardware. Data corruptions or inefficient reading and writing of data compromises the efficiency of today’s smart industrial operations. This is where fail-safe file systems such as Microsoft FAT by Tuxera (formerly Tuxera FAT) and Reliance Velocity (formerly Tuxera Flash File System) make all the difference.

Having trouble with data corruption in your industrial operations? We’ll help you find the right fail-safe data storage software!

Get in touch