Why selecting the best software program technique could make or break an SDV
As vehicles become increasingly software-defined, many OEMs default to open-source solutions for their embedded software stacks.
Open source promises flexibility, rapid prototyping, and cost efficiency. But in the context of always-on, safety-critical software-defined vehicle (SDV) platforms, these perceived benefits often come with significant risks.
Leads Automotive Market Development at Tuxera.
While SDVs are the real trend, the transition is still incomplete, especially for traditional OEMs navigating legacy development cycles, hierarchical decision-making, and a culture that prioritizes avoiding mistakes over moving fast.
Latest Videos From
The SDV era requires robust, deterministic performance under extreme conditions, endurance across 10–15-year lifespans, and resilience in the face of power loss and hardware variation. These are precisely the areas where open-source software, especially in foundational layers like file systems, can fall short.
Why open source isn’t always production-grade
There’s no denying the power of open source for innovation and speed. It’s used by engineers worldwide to build proofs-of-concept and kickstart development. But the transition from prototype to production, particularly in vehicles with zero margin for failure, raises critical concerns.
Most open-source embedded file systems were not designed for deterministic/safety-critical constraints.
While many open-source file systems provide crash consistency, they typically do not guarantee bounded recovery time, deterministic behavior after repeated sudden power loss, or validation evidence aligned with functional-safety requirements.
These systems can exhibit non-deterministic latency and recovery times under heavy write loads or repeated power interruptions..
Worse, they frequently lack the documentation, support, or certification pathways that OEMs need to satisfy safety standards like ISO 26262 or cybersecurity frameworks like ISO/SAE 21434.
Open-source communities, while vibrant, are not bound to product roadmaps or service-level agreements (SLAs). This can lead to inconsistencies in support, unpredictable updates, or bugs that remain unresolved for long periods.
In the context of a safety-critical system, unbounded delays or unexpected recovery behavior can violate real-time timing budgets and impact overall system reliability.
Collaborative open-source efforts such as Eclipse SDV or S-Core show great potential, but waiting for these stacks to fully mature could slow down progress. Commercial-grade software already available today allows OEMs to start the transition now, while still leaving room for optimization through open source later.
The hidden costs of open source
Open source is often assumed to be ‘free’, but the engineering costs of adapting, qualifying, and maintaining it are substantial.
This work must either be carried out internally or outsourced to specialized service providers. In both cases, teams spend months validating edge cases, maintaining custom patches, and ensuring consistent performance across hardware variants.
The result is not zero cost, but a shift from license fees to ongoing engineering or consulting expenses, often creating dependency on specific integrators rather than a product vendor. Teams must spend months testing for edge cases, creating custom patches, and ensuring performance across varied hardware configurations.
This consumes valuable developer time, especially in companies that don’t specialize in embedded software.
Worse, there’s no formal SLA or product roadmap. That means bugs can go unresolved, and changes in open-source communities can lead to incompatibility or introduce regressions.
For mission-critical systems in SDVs, this can result in unpredictable failures at the worst possible times, such as during OTA updates, power-down events, or when logs are needed most.
For example, early Tesla Model S units experienced eMMC wear-out partly due to heavy logging and insufficient flash endurance margins, a reminder that storage architecture, logging strategy, and flash management must be considered together.
Engineering teams often underestimate the testing burden required to bring open-source components to production-grade maturity.
Without rigorous qualification and lifecycle testing, subtle bugs in memory management, timing, or I/O operations can slip through, only to surface months or years into a vehicle’s life when fixes are costlier and more reputationally damaging.
Newer market entrants, especially in China, are embracing a “wolf culture” approach with small, high-ownership teams making fast, expert-led decisions. By comparison, many traditional OEMs remain slowed by layered approvals and centralized decision-making structures, leading to an “agility gap”.
Cybersecurity adds another layer of responsibility that is often underestimated when relying on open source. Open-source communities are not obligated to monitor vulnerabilities, provide timely fixes, or support products over a defined lifecycle.
In production vehicles, this responsibility does not disappear but shifts entirely to the OEM or its suppliers. Teams must continuously track vulnerabilities, assess exposure, backport fixes, and provide evidence that risks are managed in line with regulations such as ISO/SAE 21434 and UN R155.
Whether this work is done internally or outsourced to third parties, it represents an ongoing operational cost and organizational burden that must be accounted for when open source components are used in safety and security-relevant systems.
The importance of predictability
In safety-critical domains, predictability and consistency matter as much as functionality. Vehicles are expected to operate reliably for over a decade in fluctuating environmental conditions.
Meeting these requirements with open-source solutions typically demands substantial additional qualification, customization, and long-term ownership effort.
For example, open-source file systems like ext4 or F2FS were originally designed for servers, desktops, and Android, not for the constrained, deterministic environments typical of in-vehicle systems.
These file systems may experience unpredictable mount times, data corruption after unclean shutdowns, or rapid degradation under high write loads.
Even the most advanced driver assistance systems can be rendered ineffective when systems boot slowly, data becomes corrupted, or when logs disappear during crashes. Because failures may not show up during validation but only after years of field use, OEMs face reputational and financial risk.
OEMs must provide stronger safety and cybersecurity evidence across the entire software stack. Components without clear ownership, documentation, or long-term support make this compliance process significantly harder.
Why flash-aware file systems outperform
Commercial embedded file systems, especially those that are flash-aware, are designed with these realities in mind. They optimize write patterns, reduce write amplification, and ensure that performance and mount times remain consistent, even after thousands of sudden power-offs.
For instance, real-world tests of flash-aware file systems in automotive environments have shown 100% data integrity after 15,000+ hard power-off cycles, levels of validation that are typically difficult to achieve without dedicated engineering effort when using general-purpose open-source file systems.
Flash-aware file systems also minimize fragmentation and wear, helping embedded flash memory last as long as the vehicle. This allows OEMs to use more cost-efficient memory technologies without sacrificing reliability.
In addition, commercial-grade file systems typically come with engineering support, long-term maintenance options, and a validation roadmap aligned to industry standards. This enables OEMs to focus on vehicle functionality while relying on storage experts to handle the foundational integrity of the data layer.
No software strategy can succeed without deep awareness of the underlying hardware. Ignoring flash behavior, boot requirements, or power-fail scenarios can lead to systemic failures regardless of what stack is chosen.
Control without compromise
OEMs don’t need to abandon open source entirely. It has a vital role in enabling innovation and platform flexibility. But it must be used with care, and augmented where necessary.
This is especially true at the embedded layer, where data integrity, safety, and resilience cannot be compromised. Here, the most successful OEMs combine the flexibility of open source at the application layer with the predictability and performance of commercial-grade software infrastructure beneath it.
By using commercial embedded file systems where it counts OEMs can reduce the total cost of ownership, simplify validation, and accelerate time to market.
In fact, many leading OEMs are embracing hybrid approaches using open-source stacks for higher-level services, while locking down storage, logging, and OTA systems with purpose-built, certifiable file systems. This balance enables faster innovation without putting mission-critical reliability at risk.
Engineering for the future
SDVs are expected to last for over a decade, support evolving software platforms, and deliver consistent performance under demanding conditions. Relying solely on open source in foundational layers of these platforms is risky.
OEMs that understand the full lifecycle cost of embedded software will be better equipped to deliver vehicles that are safe, secure, and future-proof. It’s also about developer enablement.
When in-house teams are freed from debugging low-level file system issues or reverse-engineering recovery logic, they can focus on building the features that truly differentiate the vehicle, such as connectivity, UX, autonomy, and performance.
In the SDV era, the software stack is the vehicle and when it fails, the cost is far greater than a reboot.
We’ve featured the best small business software.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit