Every embedded project eventually needs to address similar challenges around how much storage should be allocated to the operating system, how much should be reserved for applications, how much capacity should be allocated for system and diagnostic logs, and whether there is enough space for future software updates.
These decisions are usually made early in development, long before the first product reaches the field.
For years, that approach served the embedded industry well. Software changed relatively slowly after deployment, applications performed clearly defined functions, and storage requirements were stable enough that engineers could make sensible decisions upfront and rarely revisit them.
Today, many teams are discovering those decisions don’t last nearly as long as they used to. Products that once received only occasional firmware updates now continue evolving throughout operational lifetimes that often exceed 15 years. The hardware stays the same, but the software keeps changing.
Moving beyond static partitions
Static storage partitioning solved an important engineering problem. Applications were isolated from one another, storage behaviour was predictable, and engineers knew exactly where critical software and data would reside. In embedded systems, that level of determinism remains valuable. Today, the challenge is that software-defined systems rarely evolve evenly.
One application may barely change throughout the life of a product. Another may double in size over several software releases. At the same time, logging requirements increase, configuration data expands, and new AI models arrive years after the original storage layout was designed.
Eventually, the symptoms become familiar. One partition starts running out of space while another still has capacity that will probably never be used. Software teams spend time optimizing storage layouts instead of developing new functionality. Hardware that still has usable flash becomes constrained because it cannot be used where it’s needed most.
Why overprovisioning isn’t a long-term answer
One obvious response is to reserve more storage during development. Many embedded platforms already include generous safety margins for exactly this reason. If engineers don’t know which applications are likely to grow over the next decade, the safest option is often to allocate additional storage to all of them. That approach reduces immediate risk, but it also leaves flash capacity permanently tied to assumptions that may never prove correct.
As software-defined products become more complex, and flash prices continue to rise, this strategy becomes increasingly difficult to justify. Industry analysts have reported significant increases in NAND and NOR flash prices over the past year, meaning every additional gigabyte contributes to higher hardware costs. As a result, overprovisioning has become a bill-of-materials (BoM) consideration.
The impact of software updates
Over-the-air (OTA) updates illustrate the problem particularly well. Reliable update strategies require storage for downloading, validating, and, if necessary, rolling back software when something goes wrong. Traditional A/B partitioning addresses this by maintaining duplicate software images so that the previous version remains available until the update has been verified. This means significant amounts of flash remain reserved for situations that occur only during the update process.
A/B partitioning remains a proven and widely adopted approach because it provides a straightforward and reliable rollback mechanism if an update fails. The trade-off is that maintaining two complete software images requires a significant amount of flash to remain reserved for the update process.
As software-defined systems become more capable, that approach can increase storage requirements, enlarge software downloads, and add to the cost and complexity of deploying updates across connected devices. With flash prices continuing to rise, many engineering teams are beginning to question whether permanently reserving that capacity remains the right trade-off for every platform.
Looking at storage differently
Rather than treating storage as a collection of permanently assigned partitions, more engineers are beginning to view it as a managed system resource. This is where the concept of a dynamic data layer becomes useful.
One of the challenges it addresses is static storage allocation. Instead of permanently assigning flash to individual applications, storage can be managed as a shared resource. Applications remain isolated through mechanisms such as subvolumes, while quotas define how much storage individual workloads may consume and reservations ensure critical functions always retain guaranteed capacity.
This allows storage to adapt as software evolves. Capacity that would otherwise remain stranded in one partition can be made available elsewhere, improving utilization without sacrificing isolation or predictability.
Rethinking OTA architectures
The data layer also creates opportunities to rethink how over-the-air updates are managed. Traditional A/B partitioning remains a robust and widely adopted approach because it provides a straightforward rollback mechanism if an update fails. However, maintaining duplicate software images permanently reserves a significant amount of flash capacity.
Snapshot-based approaches provide an alternative. Rather than storing two complete software images, the file system tracks changes at the block level so only modified data needs to be written during an update.
The pre-update snapshot provides a reliable rollback point while reducing storage overhead, download size, and update effort. As flash prices continue rising, more engineering teams are evaluating these techniques as another way to improve storage efficiency without compromising reliability.
Flexibility still requires discipline
Dynamic storage management doesn’t remove the engineering constraints embedded systems have always depended on. Deterministic behavior remains essential as critical applications still require guaranteed resources. Functional safety, reliability, and predictable recovery mechanisms continue driving architectural decisions.
The objective isn’t to make storage dynamic for its own sake but to recognize that software is no longer static in the way it was when many of today’s storage architectures were originally conceived. As systems continue to evolve throughout their operational lifetime, storage management must evolve with it.
A different role for the data layer
Storage has traditionally been viewed as supporting infrastructure. Once the partition layout was complete, attention naturally shifted to processors, applications, and communications.
Software-defined systems are changing that perspective. The data layer is becoming a more active part of system architecture because it influences how efficiently software can evolve throughout the life of a product. It affects update strategies, application growth, storage utilization, and long-term maintainability just as much as raw flash capacity.
Instead of asking whether today’s applications fit into today’s partition layout, engineers are beginning to ask whether the storage architecture itself is capable of supporting software that hasn’t yet been written. While the answer will differ from one platform to another, what seems increasingly clear is that storage can no longer be designed around the assumption that software remains static after deployment.
Embedded systems have entered an era of continuous software evolution, and the architectures beneath them need to evolve for the same reality.
Sami Kassimäki is product manager at Tuxera.
Related Content
- Embedded Basics
- 8 pillars of embedded software
- 7 tips for optimizing embedded software
- Embedded systems: The marketplace in 2028
- Can Agentic AI Solve the Embedded Software Problem?
The post Why software-defined systems require a dynamic data layer appeared first on EDN.