这种做法有两个主要问题：
许多嵌入式软件应用程序使用实时操作系统（RTOS） ，它允许将软件分解成并发任务，每个任务在系统中有不同的职责。 例如，图1所示的应用程序可能具有读取传感器、在传感器数据上运行算法以及与无线模块连接的 RTOS 任务。 RTOS本身总是处于活动状态，负责基于异步事件或特定的时间延迟在这些任务之间切换。 因为其他任务将保持在后台运行，所以从 RTOS 任务分支到一个新的程序是不安全的， 唯一安全的方法是通过通过重置来终止一个程序与实时操作系统。
基于图4，解决上一个问题的办法是将主引导加载程序切换到应用程序B，而不是应用程序A。然而，在一些微控制器上，主引导加载程序总是运行中断向量表（IVT）的程序，IVT 是应用程序中描述中断处理函数的关键部分，位于地址0。 这意味着需要某种形式的IVT重新定位到应用程序B的重置映射。 如果电源重启在 IVT 重新定位过程中发生，则可能使系统处于永久性的破坏状态。
如图3所示，通过在地址0处设置 SSBL 可以减轻这些问题。 由于SSBL是一个非RTOS程序，它可以安全地切换到一个新的应用程序。无需对电源重启关注，因为 IVT 的 SSBL 在地址0是从来没有重置的。
SSBL 的功能
了解了 SSBL 及其与应用软件的关系，那这个 SSBL 做什么呢？ 最起码，程序必须确定当前应用程序是什么（开始的位置） ，然后再切换到该地址。 如图3所示，微控制器内存中各种应用程序的位置通常保存在一个目录（ToC）中。 这是持久内存的一个共享区域，SSBL和应用程序软件都使用它们来相互通信。
当 OTA 更新过程完成时，ToC 将使用新的应用程序信息进行更新。 OTA更新功能的一部分也可以推送到SSBL。在开发 OTA 更新软件时，“确定哪些部分”是一个重要的设计决策。 上面描述的最小 SSBL 将是非常简单的，易于验证，并且很可能不需要在应用程序的生命周期中进行修改。
但是，这意味着每个应用程序必须负责下载并验证下一个应用程序。 这可能导致无线堆栈、设备固件和 OTA 更新软件方面的代码重复。 另一方面，可以选择将整个 OTA 更新过程推送到 SSBL。 在这种情况下，应用程序只需在 ToC 中设置一个标志来请求更新，然后执行复位。 SSBL然后执行下载序列和验证过程。 这将最大限度地减少代码重复，并简化应用程序特定的软件。
这带来了一个新的挑战，可能需要更新 SSBL 本身（即升级更新代码）。 最后，决定在 SSBL 中放置什么功能将取决于客户端设备的内存约束、下载应用程序之间的相似性以及 OTA 更新软件的可移植性。
设计权衡： 缓存和压缩
OTA更新软件中的另一个关键设计决策是在 OTA 更新过程中如何在内存中组织收到的应用程序。 微控制器中两种典型的存储器是非易失性存储器（例如，闪存）和易失性存储器（例如，SRAM）。 闪存将用于存储程序代码和应用程序的只读数据，以及其他系统级数据，如 ToC 和事件日志。 SRAM将用于存储软件应用程序的可修改部分，例如非常量全局变量和堆栈。 图2所示的软件应用程序二进制代码只包含程序在非易失性存储器中的部分。 在启动例程期间，应用程序将初始化属于可变内存中的部分。
在 OTA 更新过程中，每当客户端设备从服务器接收到一个包含部分二进制的数据包时，它将被存储在 SRAM 中。 这个数据包可以是压缩的，也可以是未压缩的。 压缩应用程序二进制文件的好处是它的体积更小，允许发送的数据包更少，在下载过程中 SRAM 中存储它们所需的空间更少。 这种方法的缺点是压缩和解压缩会给更新过程增加额外的处理时间，而且必须在 OTA 更新软件中捆绑相关代码。
由于新的应用软件在升级过程中位于闪存中，但是在升级过程中却进入了 SRAM，所以 OTA 的升级软件在升级过程中需要对闪存进行写操作。 在 SRAM 中临时存储新应用程序称为缓存。 在高层，OTA 更新软件可以采取三种不同的方法进行缓存。
禁用高速缓存： 每当包含一部分新应用程序的数据包到达时，将其写到闪存中的目标位置。 此方案非常简单，可以最小化 OTA 更新软件的逻辑量，但是它要求新应用程序的闪存区域被完全擦除。 这种方法削弱了闪存，增加了开销。
部分缓存： 保留一个 SRAM 区域用于缓存，当新数据包到达时将它们存储在 SRAM 的区域中。 当区域填满时，通过将数据写入快闪存储器来清空它。 如果数据包无序到达，或者在新的应用程序二进制文件中存在间隙，这可能会变得很复杂，因为需要一种将 SRAM 地址映射到闪存地址的方法。 一种策略是将高速缓存作为闪存的一部分镜像。 闪存分为小区域的页面，这是写操作的最小划分。 由于这种自然的划分，一个好的方法是在 SRAM 中缓存一页闪存，当它填满或者下一个数据包属于不同的页面时，通过写该页面的闪存来刷新缓存。
完全缓存： 在 OTA 更新过程中，将整个新应用程序存储在 SRAM 中，并只在从服务器完全下载后将其写入闪存。 这种方法通过减少对闪存的写入次数，避免了 OTA 更新软件复杂的缓存逻辑，克服了以往方法的缺点。 但是，这将限制下载新应用程序的大小，因为系统上可用 SRAM 的数量通常远小于可用闪存的数量。
图5 利用 SRAM 实现一页高速缓存
在 OTA 更新过程中使用部分缓存的第二种方案如图5所示，其中图3和图4中应用程序 a 的闪存部分被放大，而 SSBL 的 SRAM 功能存储器映射图则如图所示。 显示了一个2 kB 大小的 flash 页面示例。最终，这个设计决策将根据新应用程序的大小和允许的 OTA 更新软件的复杂性来确定。
安全及通信设计权衡： 软件 vs 协议
OTA更新解决方案还必须解决安全性和通信问题。 许多类似于图1所示的系统将具有在硬件和软件中实现的通信协议，用于正常的（非OTA更新相关的）系统行为，如交换传感器数据。 这意味着在服务器和客户机之间已经建立了一种（可能是安全的）无线通信方法。 像图1这样的嵌入式系统可能使用的通信协议，例如，BLE或6LoWPAN。 有时这些协议支持安全性和数据交换，OTA更新软件可以更新过程中利用这些安全性和数据交换。
必须构建 OTA 更新软件中的通信功能，但最终将取决于现有通信协议提供了多少抽象。 现有的通信协议是在服务器和客户机之间发送和接收文件的工具，OTA 更新软件可以简单地利用这些工具进行下载。 然而，如果通信协议比较原始，并且只能发送原始数据，则 OTA 更新软件可能需要执行分包，并随新的应用程序二进制文件提供元数据。 这也适用于安全挑战。 如果通信协议不支持，则 OTA 更新软件可能负责解密通过空中发送的用于保密的字节。
总之，构建诸如自定义包结构、服务器／客户端同步、加密和密钥交换功能，并把它们房到 OTA 更新软件中的工具将根据系统的通信协议提供的内容以及对安全性和可靠性的要求来确定。
解决安全挑战
安全解决方案需要对通过空中发送的新应用程序保密，检测新应用程序中的任何损坏，并验证新应用程序是从受信任的服务器发送的，而不是从恶意方发送的。 这些挑战可以通过使用加密（crypto）操作来解决。
具体来说，可以在安全解决方案中使用两种称为加密和哈希的加密操作。 加密技术将在客户端和服务器之间使用一个共享的密钥（密码）来混淆无线传输的数据。 微控制器的密码硬件加速器可能支持的一种特殊类型的加密被称为 AES－128或 AES－256，这取决于密钥的大小。 与加密的数据一起，服务器可以发送摘要，以确保没有损坏。 这个摘要是通过散列数据包（一个生成唯一代码的不可逆数学函数）生成的。 如果消息或摘要的任何部分在服务器创建它们之后被修改，比如在无线通信期间有一个位被翻转，当客户端对数据包执行相同的哈希函数并比较摘要时，它会注意到这个修改。
微控制器的加密硬件加速器可能支持的一种特定类型哈希方式是 SHA－256。 图6显示了微控制器中的加密硬件外设的框图，OTA 更新软件位于 Cortex－M4应用层。 此图还显示了对外围设备中的受保护密钥存储的支持，可以在 OTA 更新软件解决方案中利用该支持来安全存储客户端的密钥。
图6 基于 ADuCM4050的密码加速器硬件框图
使用非对称加密是解决身份验证最后挑战的一种常用技术。 对于此操作，服务器生成一个公私密钥对。只有服务器知道私钥，而客户机知道公钥。 使用私钥，服务器可以生成给定数据块的签名——就像将通过无线方式发送的包的摘要一样。 签名被发送到客户端，客户端可以使用公钥验证签名。 这使客户机能够确认消息是从服务器发出的，而不是由流氓第三方发出的。 这个序列如图7所示，用实箭头表示函数的输入 ／ 输出，用虚箭头表示通过空中发送的信息。
图7 使用非对称加密对消息进行身份验证
大多数微控制器没有硬件加速器来实现这些非对称加密操作，但可以使用诸如 Micro－ECC 等软件库来实现，这些软件库专门针对资源受限的设备。库需要一个用户定义的随机数母函数，这可以实现使用真随机数发生器的硬件外围的微控制器。
尽管这些非对称加密操作解决了 OTA 更新过程中的信任问题，但它们在处理时间方面代价高昂，而且需要将签名与数据一起发送，这增加了数据包的大小。 可以在下载结束时执行一次检查，使用最终包的摘要或整个新软件应用程序的摘要，但这将允许第三方下载不受信任的软件到客户端，这并不理想。 理想情况下，希望验证所收到的每个数据包都是来自受信任的服务器，而且每次都不需要签名的开销。 这可以通过哈希链来实现。
