嵌入式系统中的OTA更新的若干不同软件设计探讨.pdfVIP

嵌入式系统中的 OTA 更新的若干不同软件设计探讨 许多嵌入式系统部署在操作人员难以或无法接近的地方。物联网（ IoT ）应用 尤其如此，这些应用通常大量部署并且电池寿命有限。 实例包括监控人员或机器健康状况 的嵌入式系统。这些挑战加上快速迭代的软件生命周期，导致许多系统需要支持无线 （OTA ）更新。OTA 更新用新软件替换嵌入式系统的微控制器或微处理器上的软件。 虽然 很多人非常熟悉移动设备上的 OTA 更新，但在资源受限的系统上设计和实施会带来许多 不同的挑战。本文将介绍针对 OTA 更新的若干不同软件设计，并讨论其优缺点。我们将 了解 OTA 更新软件如何利用两款超低功耗微控制器的硬件特性。 构建模块 服务器和客户端 OTA 更新用新软件替换器件上的当前软件， 新软件以无线方式下载。 在嵌入式系统中， 运 行此软件的器件通常是微控制器。微控制器是一种小型计算器件，其存储器、速度和功耗 均很有限。微控制器通常包含微处理器（核心）和用于执行特定操作的数字硬件模块（外 设）。工作模式下典型功耗为 30 μA/MHz 至 40 μA/MHz 的超低功耗微控制器是此类应用 的理想选择。使用这些微控制器上的特定硬件外设并将其置于低功耗模式，是 OTA 更新 软件设计的重要组成部分。图 1 显示了一个可能需要 OTA 更新的嵌入式系统实例。可以 看到，一个微控制器与无线电和传感器相连，这可用在物联网应用中，利用传感器收集有 关环境的数据，并利用无线电定期报告数据。系统的这一部分称为边缘节点或客户端，是 OTA 更新的目标。 系统的另一部分称为云或服务器， 是新软件的提供者。 服务器和客户端 利用收发器（无线电）通过无线连接进行通信。 何为软件应用程序？ OTA 更新过程的大部分操作是将新软件从服务器传输到客户端。 软件从源格式转换为二进 制格式之后，作为一个字节序列进行传输。转换过程会编译源代码文件（例如 c、cpp ）， 将其链接成一个可执行文件 （例如exe、elf ），然后将可执行文件转换为可移植的二进制文 件格式（例如 bin 、hex）。概言之，这些文件格式包含一个字节序列，此字节序列属于微 控制器中存储器的特定地址。通常，我们将通过无线链路发送的信息概念化为数据，例如 更改系统状态的命令或系统收集的传感器数据。就 OTA 更新而言，数据就是二进制格式 的新软件。在很多情况下， 二进制文件非常大， 无法通过单次传输从服务器发送到客户端， 这意味着需要将二进制文件放入多个不同的数据包中，此过程称为“分包” 。为了更好地 说明此过程，图 2 演示了软件的不同版本如何生成不同的二进制文件，从而在 OTA 更新 期间发送不同的数据包。在这个简单例子中，每个数据包包含 8 字节数据，前 4 个字节表 示客户端存储器中用来存储后 4 个字节的地址。 主要挑战 基于对 OTA 更新过程的这种高层次描述， OTA 更新解决方案必须应对三大挑战。第一个 挑战与存储器有关。 软件解决方案必须将新软件应用程序组织到客户端器件的易失性或非 易失性存储器中， 以便在更新过程完成时可以执行它。 解决方案必须确保将前一版本的软 件保留为后备应用程序，以防新软件出现问题。此外，当复位和断电重启时，我们必须让 客户端器件的状态 --例如当前运行的软件版本以及它在存储器中的位置 -- 保持不变。第二 大挑战是通信。新软件必须