2．3 更新后的启动流程
    通过以上更新流程，系统完成了一次软件版本的升级。重新部署Flash后，客户端具有相对独立的bootloader，并固化在Flash的低地址处，能够保证系统启动后总是先进入bootloader。bootloader通过读取对比标识存储区的启动地址参数来跳转执行代码。在正常情况下，启动地址总是指向RTOS。当更新完成重新启动客户端后，bootloader便会引导新的镜像文件。
    为了确保软件更新后系统启动的稳定性，通过设计异常处理程序来加载代码备份存储区的文件防止系统瘫痪。当bootloader引导更新后的镜像文件失败后，系统进入异常处理函数，在此函数中将启动地址指向代码备份区，并设置标识位。代码备份区保存的是设备出厂时最初版本的image文件，具有非常高的稳定性，这样就保证系统功能正常运行，并确保服务器端与客户端正常通信。异常处理流程如图4所示。

    当软件更新过程中遇到致命异常时，通过异常处理程序，系统能够重新启动备份的软件版本，有效地提高了嵌入式系统自更新机制的安全性，避免了系统彻底崩溃。

3 测 试
    为了评估自更新机制的稳定性和安全性，确保其适用于真实设备与网络，测试应尽可能覆盖现实情况中可能遇到的情况。用户能看到的升级性能主要有更新包下载时间和自更新时间。设备厂商关注的是高稳定性和安全性，以及更新包所占Flash的比例。测试中应考虑到各种版本，制作测试矩阵，然后按顺序测试，包括回退更新。
    在一个实际运行的移动设备中验证和测试更新机制的性能。首先测试更新进程的通信状况。结果表明，每次均能正确地与服务器端建立会话，并进行数据传输；更新包均能通过无线网络准确下载并存储至客户端。测试的重点是系统更新结束后新程序启动的稳定性和安全性。对软件更新过程进行干扰，以测试bootloader能否正确启动。测试中模拟了两大类情况：一类是更新包随机挑选版本的相互升级，另一类是人为设置导致更新包出现不能启动错误的数据，然后进行升级。设计三种具体方案进行测试，每个方案测试30次，查看系统能否按预期结果启动程序。测试方案及结果如表1所列。

    从测试结果看出，系统更新后，每次均能正确启动程序；此外，更新机制对代码区具有较强的修复能力，防止了由于数据异常而导致的无法启动。本更新机制能有效地提高嵌入式软件更新后重新启动的稳定性和可靠性。

结 语
    本文提出了一种具有较高稳定性和安全性、基于bootloader的嵌入式软件自动更新机制。该更新机制同时保存了3个文件，需要较多的Flash存储空间，但同时降低了维护成本。其创新点在于设置1个标识区、3个程序存储区并设计了异常机制，提高了嵌入式系统更新过程的稳定性，尤其能够有效地防止软件更新后系统启动失败的情况，具有较高的实用价值。