嵌入式微控制器应用中的无线(OTA)更新：设计权衡与经验教训
|
摘要 许多嵌入式系统部署在操作人员难以或无法接近的地方。物联网(IoT)应用尤其如此，这些应用通常大量部署并且电池寿命有限。实例包括监控人员或机器健康状况的嵌入式系统。这些挑战加上快速迭代的软件生命周期，导致许多系统需要支持无线(OTA)更新。OTA更新用新软件替换嵌入式系统的微控制器或微处理器上的软件。虽然很多人非常熟悉移动设备上的OTA更新，但在资源受限的系统上设计和实施会带来许多不同的挑战。本文将介绍针对OTA更新的若干不同软件设计，并讨论其优缺点。我们将了解OTA更新软件如何利用两款超低功耗微控制器的硬件特性。 构建模块 服务器和客户端 OTA更新用新软件替换器件上的当前软件，新软件以无线方式下载。在嵌入式系统中，运行此软件的器件通常是微控制器。微控制器是一种小型计算器件，其存储器、速度和功耗均很有限。微控制器通常包含微处理器(核心)和用于执行特定操作的数字硬件模块(外设)。工作模式下典型功耗为30μA/MHz至40μA/MHz的超低功耗微控制器是此类应用的理想选择。使用这些微控制器上的特定硬件外设并将其置于低功耗模式，是OTA更新软件设计的重要组成部分。图1显示了一个可能需要OTA更新的嵌入式系统实例。可以看到，一个微控制器与无线电和传感器相连，这可用在物联网应用中，利用传感器收集有关环境的数据，并利用无线电定期报告数据。系统的这一部分称为边缘节点或客户端，是OTA更新的目标。系统的另一部分称为云或服务器，是新软件的提供者。服务器和客户端利用收发器(无线电)通过无线连接进行通信。
图1.示例嵌入式系统中的服务器/客户端架构 何为软件应用程序? OTA更新过程的大部分操作是将新软件从服务器传输到客户端。软件从源格式转换为二进制格式之后，作为一个字节序列进行传输。转换过程会编译源代码文件(例如c、cpp)，将其链接成一个可执行文件(例如exe、elf)，然后将可执行文件转换为可移植的二进制文件格式(例如bin、hex)。概言之，这些文件格式包含一个字节序列，此字节序列属于微控制器中存储器的特定地址。通常，我们将通过无线链路发送的信息概念化为数据，例如更改系统状态的命令或系统收集的传感器数据。就OTA更新而言，数据就是二进制格式的新软件。在很多情况下，二进制文件非常大，无法通过单次传输从服务器发送到客户端，这意味着需要将二进制文件放入多个不同的数据包中，此过程称为“分包”。为了更好地说明此过程，图2演示了软件的不同版本如何生成不同的二进制文件，从而在OTA更新期间发送不同的数据包。在这个简单例子中，每个数据包包含8字节数据，前4个字节表示客户端存储器中用来存储后4个字节的地址。 主要挑战 基于对OTA更新过程的这种高层次描述，OTA更新解决方案必须应对三大挑战。第一个挑战与存储器有关。软件解决方案必须将新软件应用程序组织到客户端器件的易失性或非易失性存储器中，以便在更新过程完成时可以执行它。解决方案必须确保将前一版本的软件保留为后备应用程序，以防新软件出现问题。此外，当复位和断电重启时，我们必须让客户端器件的状态——例如当前运行的软件版本以及它在存储器中的位置——保持不变。第二大挑战是通信。新软件必须以离散数据包的形式从服务器发送到客户端，每个数据包都要放在客户端存储器中的特定地址。分包方案、数据包结构和数据传输协议必须在软件设计中考虑周全。最后一个主要挑战是安全性。当新软件以无线方式从服务器发送到客户端时，我们必须确保服务器是可信任方。这种安全挑战称为身份验证。我们还必须对新软件进行模糊处理以防观察者偷窥，因为其中可能包含敏感信息。这种安全挑战称为保密。安全性的最后一个要素是完整性，即确保新软件在通过无线方式发送时不会损坏。
图2.软件应用程序的二进制转换和分包过程 第二阶段引导加载程序(SSBL) 了解引导序列 主引导加载程序是一种软件应用程序，永久驻留在微控制器的只读存储器中。主引导加载程序所在的存储区域称为信息空间，有时用户无法访问。每次复位都会执行该应用程序，一般完成一些必要的硬件初始化，并且可能将用户软件加载到存储器中。但是，如果微控制器包含片内非易失性存储器(如闪存)，则引导加载程序不需要进行任何加载，只需将控制权转移到闪存中的程序即可。如果主引导加载程序不支持OTA更新，则必须有第二阶段引导加载程序。与主引导加载程序一样，SSBL会在每次复位时运行，但将实施OTA更新过程的一部分。此引导序列如图3所示。本节将说明为什么需要第二阶段引导加载程序，并解释如何指定此应用程序的作用是一个重要设计权衡。 经验教训：务必有一个SSBL 从概念上讲，省略SSBL并将所有OTA更新功能放入用户应用程序似乎更简单，因为这样的话，OTA过程可以无缝利用现有的软件框架、操作系统和设备驱动程序。图4显示了一个选择此方法的系统的存储器映射和引导序列。 应用程序A是部署在现场微控制器上的原始应用程序。此应用程序包含OTA更新相关软件，当服务器请求时，利用该软件可下载应用程序B。下载完成且应用程序B经过验证之后，应用程序A将对应用程序B的复位处理程序执行分支指令，以将控制权转移给应用程序B。复位处理程序是一小段代码，用作软件应用程序的入口点，并在复位时运行。在这种情况下，复位是通过执行一个分支来模拟，这相当于函数调用。这种方法有两大问题： ► 许多嵌入式软件应用程序采用实时操作系统(RTOS)，其允许将软件拆分为多个并发任务，每个任务在系统中具有不同的职责。例如，图1所示的应用程序可能有用于读取传感器的RTOS任务，对传感器数据运行某种算法的RTOS任务，以及与无线电接口的RTOS任务。RTOS本身始终处于活动状态，负责根据异步事件或特定的基于时间的延迟切换这些任务。因此，从RTOS任务分支到新程序是不安全的，因为其他任务会在后台继续运行。对于实时操作系统，终止某个程序的唯一安全方法是通过复位。
图3.使用SSBL的存储器映射和引导流程示例
图4.没有SSBL的存储器映射和引导流程示例 |
