嵌入式系统自更新机制的设计与应用

嵌入式系统自更新机制的设计与应用

　　随着嵌入式系统的发展和广泛应用,必不可少的维护工作变得日益繁重。如移动电话在用户使用过程中，部分未能在软件研发阶段发现的缺陷会逐渐暴露,不可避免地增加了维护成本。 又如在设备运行期间,用户往往会基于原有软硬件对产品提出新功能或更高的性能要求，这对软件重用性提出了挑战。在移动设备数量较多, 而且使用地点无法预知的情况下, 采用传统的人工更新方式会耗费大量的人力物力。自更新技术在嵌入式系统中分为两个相互联系又相互独立的阶段：首先是将更新包下载至本地移动设备中，然后在本地移动设备中实现自更新。

　　将自更新技术嵌入RTOS中的关键在于自更新后系统启动的稳定性。嵌入式移动系统一般都有独立的bootloader对系统进行初始化并引导加载内核。这种启动基于bootloader，该自更新机制决定了bootloader不仅仅起到加载内核镜像这一基本功能，而是被看作是一个虚拟系统。

图1  自更新机制架构图

1  自更新机制的架构

　　支持自更新功能的嵌入式系统由服务器端和客户端两部分组成。服务器端通过OMA协议，与客户端建立无线连接。客户端采用基于ARM9的微处理器,配有8 MB的RAM和32 MB的NOR  Flash存储器,及其他相关外围设备，具有相对可见的bootloader程序。自更新机制架构如图1所示。

　　自更新机制总体流程如下： a. 设备厂商根据需求，生成包括升级到新版本或返回到旧版本的多个更新包。b. 这些更新包将被送至无线服务提供商处进行统一管理，并最终将更新包提供给用户。c. 在更新包提供给用户前，每个单独的移动设备将会选择最优方案（即网络提供商）。d. 服务器端通过传输机制(如OMADL 1.0协议标准或网络提供商标准)与客户端建立会话连接，客户端将下载并存储更新包。e. 更新应用程序将与用户交互以获得更新权限并进入更新进程。整个更新过程由bootloader完全控制，直到更新成功。f. 更新后的目标设备重启，并将更新结果发送至服务器端。

2  更新系统的设计

2.1  Flash 存储器的布局

　　原有嵌入式系统Flash存储器的布局如图2(a)所示。系统启动时从Flash的首地址开始执行，而bootloader和RTOS都位于code区，也就是bootloader并不独立于内核。将原本与
代码区相邻的文件系统区后移，用于存储更新包。这种布局也是很多嵌入式系统所采用的，尤其是许多商业系统。系统在更新过程中根据自更新算法与原有代码区进行比对，烧写到Flash中。这种Flash部署方法有一个致命的缺点，就是没有考虑到更新过程中可能遇到的突发事件。比如，在更新过程中因为不可预料的掉电使得烧写错误,完全可能导致软件更新后系统无法启动,出现这种情况后必须人工重新烧写原有软件。

图2  存储器布局

　　为了在原有基础上使系统具有高稳定性与扩展性,需要对Flash进行重新布局, 如图2(b)所示。将代码区划分为两个区域：bootloader区，这个区域不可被擦写更新；RTOS区域，存放内核及应用程序。将更新包存储区设计为4部分。其中一个用来存储系统启动和更新过程的标识参数，这些数据极为重要，掉电后仍需保存于Flash中。另一个存储区用于存放更新时用到的更新包, 称为更新包区。第三个区域存储下载的更新包,称为更新包备份区。最后一个区域存放设备出厂时的软件版本。bootloader固定在第一个分区,这样的设计具有很强的可扩展性，涵盖了更新算法。为了使人机接口更人性化，此区域包括LCD及其控制器的驱动和应用程序，使更新过程对用户可见。系统启动时设置异常向量表，初始化内存、堆栈指针寄存器、I/O器件、系统需求的RAM变量，使能中断,然后根据启动地址和更新标识这两个参数跳转执行相应代码，每次更新都不改变bootloader区域的内容。其中，启动地址指向bootloader要执行的代码,更新标识用于记录更新阶段。

2.2  更新进程的设计

　　系统每次启动后, 服务器端主动报告当前有无可更新的软件包。如果客户端响应并发起会话，则随后检查Flash上的更新包备份区,存储下载的更新包，并更新标识。为了增强传输过程的安全性, 在应用层设计一套具有校验、确认和断点续传功能的收发协议, 以保证数据能够准确地通过移动通信系统传输到客户端。

图3  更新进程流程

　　当更新包下载完毕后, 先将更新包由备份区拷贝至更新包区，更新进程根据已经设定的代码区在Flash中的地址,调用Flash 的读写函数通过比对算法将更新包写入代码区。更新结束后设置标识,如果由于某种原因没有更新成功则标识位不变,系统复位后继续更新直到更新成功。可参考如下代码：

　　ldrr0,=v_Update_flag
　　ldrr1,[r0]
　　ldrhr0,[r1]
　　ldrr1,=MC_ENTER_RTOS_FLAG
　　cmpr0,r1
　　beqcontinue
　　BEnter_Update_process
　　continue
　　ldrpc,=Enter_rtos

　　更新进程的程序流程如图3 所示。

2.3  更新后的启动流程

　　通过以上更新流程,系统完成了一次软件版本的升级。重新部署Flash后，客户端具有相对独立的bootloader,并固化在Flash的低地址处,能够保证系统启动后总是先进入bootloader。bootloader通过读取对比标识存储区的启动地址参数来跳转执行代码。在正常情况下, 启动地址总是指向RTOS。当更新完成重新启动客户端后, bootloader便会引导新的镜像文件。

　　为了确保软件更新后系统启动的稳定性,通过设计异常处理程序来加载代码备份存储区的文件防止系统瘫痪。当bootloader 引导更新后的镜像文件失败后, 系统进入异常处理函数, 在此函数中将启动地址指向代码备份区,并设置标识位。代码备份区保存的是设备出厂时最初版本的image文件，具有非常高的稳定性，这样就保证系统功能正常运行,并确保服务器端与客户端正常通信。异常处理流程如图4所示。

图4  异常处理流程图

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

3  测试

　　为了评估自更新机制的稳定性和安全性，确保其适用于真实设备与网络，测试应尽可能覆盖现实情况中可能遇到的情况。用户能看到的升级性能主要有更新包下载时间和自更新时间。设备厂商关注的是高稳定性和安全性，以及更新包所占Flash的比例。测试中应考虑到各种版本，制作测试矩阵，然后按顺序测试，包括回退更新。

　　在一个实际运行的移动设备中验证和测试更新机制的性能。首先测试更新进程的通信状况。结果表明, 每次均能正确地与服务器端建立会话，并进行数据传输；更新包均能通过无线网络准确下载并存储至客户端。测试的重点是系统更新结束后新程序启动的稳定性和安全性。对软件更新过程进行干扰,以测试bootloader 能否正确启动。测试中模拟了两大类情况:一类是更新包随机挑选版本的相互升级,另一类是人为设置导致更新包出现不能启动错误的数据,然后进行升级。设计三种具体方案进行测试, 每个方案测试30 次,查看系统能否按预期结果启动程序。测试方案及结果如表1所列。

表1  启动可靠性测试结果

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

结语

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