Accelerating Data Access in Automotive Designs
Quenching drivers’ thirst for information without compromising security or risking power loss.
The modern car and commercial vehicle are arguably a rolling Internet of Things (IoT). Computers control the dashboard, engine dynamics, safety systems and more (Figure 1). Each subsystem has its own critical data, and some of that data is useful to other systems within the car. Today’s driver wants access to all the information available so they can be the best driver possible, but also so they can have the best driving experience. But choosing the right Real Time Operating System (RTOS) and file system to ensure seamless, reliable and secure access to data across subsystems is challenging.
The first electronic control units (ECUs) in cars were analog and handled the minutiae of fuel injection for Volkswagen and Chevrolet. It wasn’t long before microprocessors were in control of other key systems. Forty years later, cars have more than 100 ECUs with millions of lines of code controlling them. Dozens of microprocessors must now not only collect their sensor data and control their specific subsystems, but they must also communicate with other device systems—and occasionally with devices outside the car as well.
Each of these microprocessors has its own RTOS environment. From the console In Vehicle Infotainment (IVI), to the engine dynamics, to the overall vehicle diagnostics and data logging, each subsystem designer has chosen the right RTOS for their design. However, it is becoming increasingly important to also consider the interaction of systems within the automobile.
For each individual RTOS environment, there are a handful of default file system formats—though Linux would require big hands. These formats are nearly always incompatible with one another, so media written by one RTOS will not be directly readable by another RTOS unless a special driver is loaded. One exception to this is the FAT file system, which is generally common across all platforms and RTOS choices, but features some limitations.
The FAT file system introduces a host of problems, from access time for files (unless a FAT cache is also used) to the tendency to overwrite when modifying in place (unless unusual programming techniques are used). It lacks a reliable way to detect media or power interruption problems, and with that checking can be quite slow to mount. FAT also doesn’t feature user controls and real security attributes for files.
Other RTOS environments, including Wind River’s VxWorks and Mentor Graphics’ Nucleus, also lack full security attributes for their file system solutions. This is one reason many applications have been somewhat shielded from the actual hardware. However, applications can be modified to provide some of the missing security at the cost of a larger footprint and less flexibility.
Instead of using a common file system to share data among several subsystems, one could instead use a network or API to transfer data between the different RTOS environments. In this instance, the original copy of the data is never at risk, but the growing size of the data involved could cause problems with internal bandwidth and latency. The only common protocol in most automotive environments today is the Controller Area Network (CAN) protocol, which is insufficient for large transfers. Another concern for a network or API solution is later redesign or addition of components, which would then have to meet older standards for a wide variety of vehicles.
The Most Data in the Safest Manner
By using a common on-media format that has reliability and security built in, each application can have required access to common data when needed. The IVI console can display average results from engine metrics and controls for the telematics control unit (GPS and other external networks) without interrupting those functions. Any critical data can be accessed to help make intelligent choices, leaving the internal CAN and other networks free for vital functions.
Designers of automotive systems and subsystems have choices besides transmitting data across internal networks and sharing data on a common drive format that is vulnerable to power loss. Datalight’s Reliance Nitro is designed to be robust against power loss and flexible to meet the designer’s needs. Security attributes from Linux are used internally and can be added to VxWorks and other environments through a dynamic hooks interface. This solution will allow the most data available to the operator in the safest manner, resulting in the best driving experience.
Thom Denholm is a technical product manager at Datalight. He is an embedded software engineer with more than 20 years of experience, combining a strong focus on operating system and fie system internals with a knowledge of modern flash devices. Thom holds a BS in Mathematics and Computer Science from Gonzaga University. His love for solving difficult technical problems has served him well in his fifteen years with Datalight. In his spare time, he works as a professional baseball umpire and an Internet librarian. Though he has lived in and around Seattle all his life, he has never had a cup of coffee.