软件定义系统时代，存储架构为何需要走向动态化？

随着软件定义系统（Software-Defined Systems）快速发展，嵌入式产品正在经历一场重要变化：硬件趋于稳定，而软件持续演进。过去，一款嵌入式产品的软件功能相对固定，产品发布后通常只进行少量固件更新。因此，在开发初期确定操作系统、应用程序、日志以及升级空间的存储分配方式，通常就可以满足整个产品生命周期的需求。但这种模式正在发生改变。

如今，汽车、工业设备以及其他智能终端的生命周期可能超过15年，而软件却会在整个生命周期内持续升级。新的应用、更复杂的算法、AI模型、日志数据和配置文件不断加入，使得最初设计的存储架构越来越难以应对未来需求。硬件没有改变，但软件一直在变。这意味着，传统的静态存储分区正在面临新的挑战。

从“固定分区”到“共享存储资源”

传统嵌入式系统通常会提前划分固定的存储空间，例如为操作系统、不同应用、日志以及OTA升级分别预留容量。这种方式最大的优势是简单、稳定且具有良好的可预测性。每个应用都有明确的存储边界，关键软件和数据也能够被放置在指定区域。但问题在于，软件并不会按照最初的规划平均增长。

一个应用可能在产品生命周期内几乎没有变化，而另一个应用却可能经过几次软件升级后体积翻倍。同时，系统日志不断增加，配置数据持续扩展，甚至可能在产品上市多年之后加入新的AI模型。最终，一个熟悉的问题就会出现：一个分区已经空间不足，而另一个分区却仍然拥有大量闲置容量。

这些闲置空间无法被真正需要它们的应用使用。软件团队不得不不断优化存储布局，而硬件本身明明还有可用的Flash，却因为固定分区的限制而无法发挥全部容量。因此，越来越多的工程团队开始重新思考：存储空间是否应该像CPU、内存等系统资源一样，根据实际需求进行更加灵活的管理？

为什么简单增加Flash容量并不是最佳答案？

面对未来的不确定性，一个最直接的办法就是在产品设计阶段预留更多Flash。例如，如果预计未来需要128GB，那么直接选择256GB甚至更大的存储容量，为软件增长留出足够的余量。这种方式确实能够降低短期风险，但也意味着大量存储容量可能长期处于闲置状态。对于生命周期较长的软件定义产品而言，这不仅是架构问题，也会直接影响BOM成本。

尤其是在NAND、NOR等Flash存储器价格上涨的情况下，每增加一定的存储容量，都意味着额外的硬件成本。因此，“多留一些空间”正在从一种简单的工程保险措施，逐渐变成需要认真评估的成本决策。

OTA升级让存储问题更加突出

OTA（Over-the-Air）升级是软件持续演进的典型场景。为了确保升级可靠，系统不仅需要空间下载新的软件版本，还需要进行完整性验证，并在升级失败时能够恢复到之前的版本。目前，A/B分区是一种成熟且广泛采用的解决方案。简单来说，系统同时保留两个软件版本：

· A区运行当前版本；

· B区用于写入新版本；

· 新版本验证成功后切换；

· 如果升级失败，则回退到原来的版本。

这种方式最大的优势是可靠、简单，而且回滚机制清晰。但它也带来了明显的存储成本：系统需要长期保留两套完整的软件镜像。如果操作系统和应用程序本身就占用大量空间，那么为了OTA而额外预留一套完整的软件环境，会进一步推高Flash容量需求。随着软件功能越来越复杂，这种存储开销也会不断增加。

动态数据层：让存储空间随软件一起演进

这也是“动态数据层（Dynamic Data Layer）”概念受到关注的原因。与其把Flash永久划分成多个固定分区，不如将存储空间看作一个统一管理的资源池，根据不同应用在不同阶段的实际需求进行分配。这并不意味着取消应用之间的隔离。通过Subvolume（子卷）、Quota（配额）以及Reservation（容量预留）等机制，可以同时实现：

· 应用之间的存储隔离；

· 对不同应用设置容量上限；

· 为关键功能预留可靠的存储空间；

· 在不同应用之间更加高效地利用闲置容量。

这样，当软件发生变化时，存储架构也能够随之调整。原本被锁定在某个分区中的闲置容量，可以被重新利用，而不必因为某一个应用空间不足就立即更换更大容量的Flash。这为软件定义系统提供了一种更加灵活的存储管理方式。

Snapshot为OTA带来新的思路

动态数据层不仅能够改善日常的存储利用率，也为OTA架构提供了新的可能。传统A/B方案需要长期保留两套完整的软件镜像，而基于Snapshot（快照）的方案则可以采用不同的思路。系统可以在升级之前创建一个Snapshot，记录当前系统状态。升级过程中，文件系统只需要记录发生变化的数据，而不必重新保存一整套完整的软件镜像。如果升级成功，系统继续运行新版本；如果升级失败，则可以利用升级前的Snapshot恢复到之前的状态。这种方式有机会减少：存储空间占用、OTA下载数据量以及升级过程中的数据写入量。对于需要长期运行、持续升级的软件定义系统而言，这种方式尤其值得关注。

动态并不意味着失去确定性

当然，动态存储并不是简单地“让所有应用自由使用Flash”。对于汽车电子、工业控制以及其他安全关键型嵌入式系统而言，确定性和可靠性依然是架构设计的基础。关键应用必须获得稳定且有保障的资源，系统也必须具备可靠的故障恢复机制。尤其是在涉及功能安全（Functional Safety）的系统中，任何存储管理策略都不能影响关键功能的正常运行。因此，动态存储的真正目标并不是追求“动态”本身，而是：在保证隔离性、可靠性和确定性的前提下，让有限的存储资源得到更加合理的利用。

存储正在成为系统架构的重要组成部分

过去，存储更多被视为一种基础设施。工程师完成分区规划之后，注意力往往会转向处理器、应用程序和通信接口。但在软件定义系统时代，情况正在发生变化。存储架构已经开始直接影响软件的生命周期管理，包括：

· 软件升级策略；

· 应用程序扩展；

· AI模型部署；

· 存储资源利用率；

· OTA实施成本；

· 产品长期维护能力。

因此，工程师需要思考的问题也正在发生变化。过去我们关注的是：“今天的软件能不能放进今天的存储分区？”而未来更加重要的问题可能是：“今天设计的存储架构，能不能支持未来还没有开发出来的软件？”这也是软件定义系统带来的一个重要变化。

面向持续演进的嵌入式系统

从传统嵌入式系统到软件定义系统，最大的变化之一并不是硬件本身，而是软件生命周期的改变。产品发布不再意味着软件开发的结束，而可能只是一个长期软件演进周期的开始。

随着汽车电子、工业设备以及智能终端不断引入OTA、AI和更多软件功能，存储架构也需要从“为今天规划”逐渐转向“为未来演进”。软件在持续变化，支撑软件运行的数据层也需要具备持续演进的能力。这或许正是动态数据层真正的价值所在：它不是简单地增加更多存储空间，而是让有限的存储资源能够更灵活、更高效地服务于一个不断变化的软件系统。

——来源：https://www.edn.com/