许多嵌入式系统部署在人类操作员很难或无法访问的地方。 对于物联网应用程序来说尤其如此，物联网应用程序通常数量较大，电池寿命有限。 一些例子是监视人或机器健康状况的嵌入式系统。 这些挑战，再加上快速的软件生命周期，导致许多系统需要对OTA更新提供支持。

OTA更新以新的软件替代了嵌入式系统中单片机或微处理器上的软件。 虽然许多人非常熟悉他们的移动设备上的 OTA 更新，但是在资源受限的系统上的设计和实现会带来许多不同的挑战。

在IoT固／软件更新及开源选项一文中，学习了一些开源的技术，在这里，将描述几种不同的OTA更新软件设计，并讨论它们的利弊，并将了解两个超低功耗微控制器的硬件特性如何在 OTA更新软件中得到的利用。

构建基础嵌入式系统中的CS架构

OTA升级用新的软件取代了设备上现有的软件，新的软件通过无线网络下载。 在嵌入式系统中，运行这个软件的设备通常是一个微控制器。 微控制器是一种小型计算设备，具有有限的存储器，速度和功耗。 微控制器通常包含一个微处理器（核心）以及用于特定操作（外围设备）的数字硬件。 超低功耗微控制器通常在主动模式下消耗30 微安／Mhz到40微安／Mhz，是这种类型应用的理想选择。

在这些微控制器上使用特定的硬件外设，并将其设置为低功耗模式，是 OTA 更新软件设计的重要组成部分。 图1显示了一个可能需要 OTA 更新的嵌入式系统示例。 这里的一个微控制器连接着一个无线模块和传感器，它可以用在物联网应用中，通过传感器收集环境数据，并定期用无线模块报告。 系统的这一部分称为边缘节点或客户端，是 OTA 更新的目标。 系统的另一部分称为云或服务器，是新软件的提供者。 服务器和客户端通过使用收发信机（无线电）进行通信。

图1 嵌入式系统中的客户机／服务器体系结构

OTA 的软件本质

OTA更新流程的大部分工作是将新软件从服务器转移到客户端。 当软件从源代码格式转换为二进制格式后，软件以字节序列的形式传输。 转换过程包括编译源代码文件（例如 c、 cpp） ，将它们链接到一个可执行文件（例如 exe、 elf）中，然后将可执行文件转换为可移植的二进制文件格式（例如 bin、 hex）。这些文件格式包含一个字节序列，属于微控制器内存的特定地址。

通常，通过无线链路发送的信息概念化为数据，例如更改系统状态或系统收集的传感器数据的命令。 在 OTA 更新的情况下，数据是二进制格式的新软件。 在许多情况下，二进制文件太大，无法将一次传输从服务器发送到客户机，这意味着需要将二进制文件放入单独的数据包中，这个过程被称为打包。 为了更好地将这一过程可视化，图2演示了不同版本的软件如何生成不同的二进制文件，从而在 OTA 更新期间发送不同的数据包。 在这个简单的示例中，每个数据包包含8个字节的数据，前4个字节表示客户机内存中的地址，用于存储后4个字节的数据。

图2 软件应用的二进制转换和打包过程

OTA的主要挑战

基于这种对 OTA 更新流程的描述，OTA 更新解决方案必须解决三大挑战。

第一个挑战与内存有关。 软件解决方案必须将新的软件应用程序组织到客户端设备的易失性或非易失性存储器中，以便在更新过程完成时执行。 解决方案必须确保以前的软件版本在新软件出现问题时作为后备应用程序保留下来。 此外，必须保留客户端设备的状态之间的重置和电源周期，如软件的版本，已经目前正在运行在内存中的位置。

第二个挑战是通信。新软件必须以离散数据包的形式从服务器发送到客户机，每个数据包针对客户机内存中的特定地址。 软件设计中必须考虑数据包的分组方案、分组结构和传输协议。

最后一个主要挑战是安全问题。 随着新的软件从服务器无线发送到客户端，必须确保服务器是可信的。 这种安全挑战称为身份验证，还必须确保新软件对任何观察者进行模糊处理，因为它可能包含敏感信息。这种安全挑战称为保密性。 安全的最后一个要素是完整性，确保新软件在空中发送时不会损坏。

引导加载程序理解启动顺序

主引导加载程序是永久驻留在微控制器只读内存上的软件应用程序。 主引导加载程序驻留的内存区域称为信息空间，用户有时无法访问该区域。 这个应用程序在每次重置时执行，通常执行一些必要的硬件初始化，并可能加载用户软件到内存中。

但是，如果单片机包含片内非易失性内存，如闪存，启动加载程序不需要做任何加载，只需将控制权转移到闪存中的程序。 如果主引导加载程序没有对 OTA 更新的任何支持，则有必要使用第二阶段引导加载程序（SSBL）。 与主引导加载程序一样，SSBL 将在每次reset时运行，但将实现OTA更新过程的一部分。 引导顺序如图3所示。 在这里将学习为什么需要第二阶段引导加载程序，以及如何指定此应用程序的角色是一个关键的设计权衡。

图3 用SSBL实现内存映射和引导流的示例

不使用SSBL的问题

从概念上讲，省略 SSBL 将所有的OTA更新功能放到用户应用程序中似乎更简单，因为它将允许现有的软件框架、操作系统和设备驱动程序无缝地用于OTA过程。 选择这种方法的系统内存映射和引导顺序如图4所示。

图4 没有SSBL的内存映射和启动流

应用程序A是原来的应用，是部署在微控制器的控制域。 此应用程序包含与 OTA 更新相关的软件，当服务器请求时，将利用该软件下载应用程序 B。 在完成下载并验证了应用程序B 之后，应用程序A将通过向应用程序B执行reset指令将控制转移到应用程序B。 reset处理程序是一小段代码，它是软件应用程序的入口点，并在重置时运行。 在这种情况下，通过执行分支（相当于函数调用）来模仿reset。