Rethinking Storage Architecture for Software-Defined Embedded Systems

Some of the most important architectural decisions in an embedded platform are made early in development. Once the platform requirements and hardware specifications have been established, engineers determine how storage will be allocated to support operating systems, applications, logs, software updates and the expected growth of software throughout the product's lifetime. The constraints introduced by these decisions often remain throughout the platform's operational lifetime.

For many years, those decisions rarely needed revisiting. Embedded systems generally performed a defined set of functions; software changed relatively little after deployment, and storage requirements remained reasonably predictable. Once the storage architecture had been validated, it could often remain unchanged for the lifetime of the platform.

Increasingly, that's no longer the case. Software-defined systems are expected to evolve throughout their operational lives. Vehicles continue to receive new features through over-the-air (OTA) updates; industrial equipment requires ongoing software maintenance and reliability improvements, while connected edge devices continue adding new capabilities.

Across all these systems, cybersecurity updates have become a continuous requirement throughout the product lifecycle. AI workloads are also becoming more common at the edge, bringing larger software stacks and growing storage requirements with them. The result is that storage decisions made during development now have to support software that will continue changing for years after the hardware has shipped.

Static Partitioning Solved the Right Problem

Static storage architectures became the traditional approach for good reasons. They provide predictable behavior, isolate applications from one another, and make it easier to validate software before products reach the field. Safety-critical applications can be protected from less critical workloads, while update mechanisms remain clearly separated from operational software.

Static partitioning has long been the default approach for many embedded platforms, and what has changed is the nature of embedded software. Rather than remaining relatively stable throughout the lifetime of a product, software is becoming something that evolves continuously. New functionality is added after deployment; connected services expand, telemetry increases, and security updates become routine. Individual software releases may only require modest additional storage, but over ten or fifteen years those changes accumulate.

Engineers often discover that the original partition layout still contains enough flash overall, but it is not available where it's needed. Some applications grow far more quickly than anticipated, while others require little or no additional storage beyond their original allocation, leaving capacity stranded in one partition while another reaches its limits.

At that point, the obvious solution is often to specify a larger flash device. Sometimes that's entirely appropriate. In other cases, it raises a different question around the limitation of the amount of storage available, or the way that storage has been allocated.

Software-defined vehicles require storage architectures that can evolve alongside software.

Why the Data Layer Deserves More Attention

Engineering teams look beyond storage capacity alone. The data layer, i.e., the part of the system responsible for storing, organising and maintaining software and data throughout the life of a device, is becoming a more important architectural consideration than it once was.

Storage decisions influence far more than where applications reside. They affect how efficiently updates can be delivered, how software grows over time, and how effectively available storage capacity is used throughout the lifetime of the platform.

As software lifecycles become longer and less predictable, those decisions become increasingly more critical. Rather than treating storage as a static resource allocated once during development, engineers are beginning to explore architectures that allow storage to adapt alongside software.

One approach to receiving growing attention is dynamic partitioning. Instead of permanently assigning storage to individual applications, dynamic partitioning allows storage to be managed more flexibly as workloads evolve. Applications remain isolated, but unused capacity no longer has to remain tied indefinitely to partitions that may never require it. Shared storage pools, subvolumes, and quotas are all examples of techniques that can support this approach while still preserving the isolation and reliability expected in embedded systems.

Why Flexibility and Reliability Can Go Hand In Hand

More flexible storage management doesn't remove the engineering constraints that embedded systems have always depended on. Deterministic behavior, predictable performance, and strong isolation remain essential, particularly in automotive, industrial, and other safety-critical applications. Any change to storage architecture still has to meet the same requirements for validation, fault recovery, and long-term reliability.

Dynamic partitioning doesn't replace those principles. It simply changes how storage is allocated. Rather than permanently reserving flash for every application based on assumptions made during development, capacity can be managed as a shared resource while still enforcing clear boundaries. Reservations ensure that critical software always retains the storage it needs, while quotas prevent less critical workloads from consuming more than their allocated share.

The result is a system that can adapt as software evolves without sacrificing the predictability, isolation, and reliability that embedded engineers expect.

Fixed and Dynamic partitions

Storage Efficiency as a Design Constraint

Storage efficiency is becoming an increasingly important design consideration as flash prices continue to rise and software footprints expand. Industry analysts have reported significant increases in both NAND and NOR flash pricing during the past year, making it more expensive for OEMs and Tier-1 suppliers to simply increase storage capacity whenever software grows.

Static partitioning typically requires engineers to allocate storage conservatively, reserving additional capacity for future software growth. That approach has served the industry well, but it can also result in flash remaining underutilised while contributing to higher bill-of-material (BoM) costs. As flash becomes more expensive, engineering teams are naturally asking whether the available storage can be managed more efficiently before specifying larger devices.

OTA Updates Show Why Storage Architecture Matters

Software updates are a good example of where these architectural decisions become visible. Most embedded platforms today are expected to receive updates throughout their operational life. Some deliver occasional maintenance releases, while others receive regular feature enhancements, security patches, or application updates.

Traditional storage layouts often accommodate this through duplicate software images. These approaches are well understood and remain appropriate for many systems because they provide a straightforward rollback mechanism if an update fails.

However, as software images become larger, the storage reserved for those update strategies also grows. For some platforms, that's an entirely acceptable trade-off. For others, particularly systems expected to receive years of continuous software updates, it prompts a broader discussion about whether storage can be managed more efficiently without compromising resilience. Rather than viewing OTA strategy and storage architecture as separate design decisions, many engineering teams are beginning to consider them together.

From Storage Management to Dynamic Data Architecture

Viewed individually, techniques such as shared storage pools, subvolumes, quotas, and dynamic partitioning solve specific engineering problems. Taken together, they represent a different approach to storage architecture that can improve flash utilisation while helping OEMs and Tier-1 suppliers manage the increasing hardware costs associated with rising flash prices.

Instead of assuming that software layouts defined during development will remain appropriate throughout the life of a product, storage is designed with the expectation that applications, workloads, and update strategies will continue evolving. This is the foundation of what many engineers are beginning to describe as a dynamic data architecture. Storage becomes an active part of system architecture rather than a static hardware resource established once and left unchanged.

That doesn't mean every embedded platform should abandon static partitioning. Many applications continue to benefit from its simplicity and predictability. The point is that software-defined systems are presenting a different set of engineering requirements than the systems those architectures were originally designed to support.

Designing for the Next Decade

Long-lived embedded systems are becoming the norm rather than the exception. Whether the platform is an industrial controller, an intelligent edge device or a software-defined vehicle, engineers are increasingly designing hardware that will support years of software evolution after deployment.

That makes storage architecture an important design decision rather than simply a deployment detail.

Before finalising a storage architecture, engineers should consider how the platform is expected to evolve over its operational lifetime. That means looking beyond today's software requirements to consider how frequently the system is likely to receive updates, which applications are most likely to grow, and whether the storage layout will still make efficient use of available flash several years after deployment. It is also worth considering whether a more flexible approach to storage management could improve utilisation while continuing to meet the platform's requirements for reliability, determinism, application isolation, and storage lifetime.

Some products will continue relying on traditional static partitioning because it remains the simplest and most appropriate solution. Others may benefit from more flexible approaches that allow storage to evolve alongside software.

What's becoming increasingly clear is that the data layer deserves more attention than it has traditionally received. As software-defined systems become the norm across automotive, industrial and edge computing environments, it influences not only where software is stored, but how efficiently platforms can accommodate years of updates, new functionality and changing workloads.
Engineers have always balanced performance, reliability, and complexity when making architectural decisions. As embedded software continues evolving long after deployment, storage architecture is becoming part of that same conversation and one that's likely to shape the next generation of software-defined systems just as much as advances in processors, connectivity and AI.

Tuxera works with OEMs and embedded system developers to address the storage and connectivity challenges created by increasingly software-defined systems. Our technologies underpin a resilient and secure embedded data layer, providing software for data at rest and data in transit, and helping manufacturers build reliable storage architectures for mission-critical devices that support long operational lifetimes, dependable software updates, data integrity, and efficient management of embedded storage as platforms continue to evolve.

As software becomes a defining characteristic of modern embedded systems, the embedded data layer and its supporting storage architecture play an increasingly strategic role in overall system design.

All images used courtesy of Tuxera.