程晓兰 蔡晓丽

（四川长虹网络科技有限责任公司 四川省绵阳市 621000）

机顶盒软件在开发和调试阶段，可以通过芯片平台提供的某种工具，来下载及测试系统。但是当软件开发完成，通过运营商发放到用户手上之后。如果运营商需要增加一些功能或者修补一些bug，不可能用芯片平台提供的工具来下载，也不可能回收对产品进行升级，这就产生了在线升级软件的需求。

在线升级就是将升级数据放到运营商服务端，通过光纤或者网线下载到机顶盒端再编程的过程。每款产品生产商都会不定期地提供用户升级软件，来实现运营商新增功能，提高产品的适应性和延长产品的生命周期。

无论通过哪种方式升级，升级数据升级到那个分区或者地址，升级数据的生成商信息，软件版本，压缩加密方式等说明，都需要一个特定的工具将这些信息打包到升级数据中，以便机顶盒将数据编程到相对应正确的位置。

1 升级方式

根据下载数据的载体不同，将升级方式分为：芯片平台提供的烧写工具升级、USB/SDcard 升级、cable 线升级、IP 升级。使用芯片平台提供的烧写工具升级，一般处于开发阶段，为了节省开发工作量，所以升级的数据一般都是原始数据。对于USB/SDcard 升级，一般用于开发完成后，测试人员测试迭代软件，或者运营商不用配置升级系统，单独升级个别机顶盒时，常用的升级方式。Cable 线升级、IP 升级，一般是机顶盒已经投放到用户手中，有软件bug 需要修改，或需要增加新功能要用的升级方式。无论是USB/SDcard升级，还是Cable 线升级、IP 升级，都是对外发布软件，就要考虑到知识产权保护，系统安全等因素。所以对于升级的数据，需要压缩，加密等特殊处理。

2 升级数据配置

在机顶盒协议标准中，有一个非常重要的标准《RFC4627》，在这个标准里面提供一种结构化数据序列化的一种文本格式。本文中重点运用该规范，定义了一系列名称/值，来实现升级数据配置。

2.1 升级软件版本信息update_cfg.json

该json 文件主要描述升级软件的属性，也是机顶盒判断是否可以升级的重要手段。如表1 所示。

表1

2.2 分区升级信息update_part.json

该json 文件分为part 和ubi 部分。part 对应的升级文件是uboot_s.bin,kernel.bin,rootfs.sqfs 等可以直接烧写到flash 的文件。ubi 对应的customer.ubifs 等UBIFS 格式的升级文件，因为该格式文件写flash 需要做对应的特殊处理，所以与part 分别开来。详细如表2 所示。

表2

2.3 升级数据结构

如表3 所示，该数据结构详细罗列了升级数据包中每个字节代表的意义。

表3

2.4 触发升级标识结构

应用APP 和升级APP 通过读写该数据结构来进行通信。如表4 所示。

表4

3 升级类型

3.1 前台升级

所谓前台升级，是指机顶盒用户在收看节目或者使用其他应用的过程中，当系统检测到有高于本地系统软件版本时，将提醒用户是否升级。当用户同意升级时，系统将调整到升级应用进行升级。从发现高版本软件到进入升级，到升级过程，用户可以直观看到整个升级流程。

而对于机顶盒软件，实现前台升级，需要进行如下步骤：

（1）将各分区数据用特定工具合并成一个文件，并放置到服务器端，并播发数据。

（2）主应用APP 检测到有升级信息，保存升级参数（cable 线参数或者ip 参数），设置升级标志位，重启。

（3）在boot 阶段，检测到升级标志位，跳转到升级APP。

（4）在升级APP 中，根据卫星参数，cable 参数或者IP 参数，下载数据。

（5）校验下载数据，并写数据到相应分区。

（6）清除升级标志位，重启进入到主应用APP。

3.2 后台升级

经过多年机顶盒软件编写的经验，和实际应用场景经验，我们总结出了一套行之有效的后台升级的方法。所谓后台升级，是指当系统检测到有高版本的软件版本时，直接将升级数据下载到内容后，只需做简单的数据完整性校验后，就写到备份分区，并设置需要升级的标志位。当下次开机，系统自动检测到备份分区有升级的标志位时，再将数据更新到真正的数据分区，升级完成后再直接进行机顶盒应用。在开机过程中，如果需要升级，校验数据和更新数据只需多用几秒时间，用户完全几乎感觉不到。

对于机顶盒软件，实现后台升级，需要进行如下步骤：

（1）将软硬件版本及机顶盒属性配置到update_cfg.json，将需要升级的分区名和分区文件一一对应，并配置到update_part.json 中，再将两个json 文件和需要升级的分区文件，用linux zip 命令打包成pack.zip。

（2）制作一个linux 执行程序，将签名数据作为输入文件方式，按Update_data 结构，给pack.zip 插入前4 个字节和128+4 个签名校验字节，命令为updata.bin。

（3）将updata.bin 放到服务器并播发。

（4）主应用APP 检测到有升级信息，开始后台下载数据，下载完成，进行简单的数据签名校验，写升级数据到数据分区，根据Update_trigger 结构体设置升级标志，重启。

（5）在boot 阶段，检测到升级标志u8_Updateflag=0x47，从升级数据分区读取升级数据，校验签名，解压zip 包；根据update_cfg.json，与机顶盒固化数据比较，检测数据是否合法；解析update_part.json 内容，将分区文件写到相应的分区，再解析update_cfg.json 内容，并更新软件版本号，清除升级标志，进入到主应用app。

4 前台升级与后台升级探讨

从原始数据打包方式上相比较：在后台升级方式中，将升级分区文件用json 的数据格式配置，再用Linux 命令zip 打包，签名校验的执行程序，在编译脚本中增加打包和校验的执行脚本。与前台升级方式相比，减少了打包工具的开发，直接用开源的Linux 系统命令，增加编译脚本即可。这样达到了编译版本和升级版本的一致性，方便各个升级版本问题追溯，也减少了打包工具的开发，减小了工作量。

从实现升级的系统上相比较：前台升级方式的数据下载，用了单独一个升级APP。后台升级的数据下载，仍然在主应用APP。前台升级就需要多维护一套升级APP 系统，因为对于升级系统，一般不需要像主应用那么多功能，就还需要对系统做裁剪工作，否者就要占用更多的flash 空间。而后台升级只是需要多划分一个备份的flash 空间用于存放下载的升级数据。而升级应用APP 本身也是需要占用空间的，而下载数据是做了压缩处理的，所以两种方式中，占用的flash 是一样的，而前台升级还需要多维护一套系统，由此后台升级更节省工作量。

从数据下载用户体验上相比较：前台升级是升级APP 中进行下载升级的，用户是可以直接看到下载进度的，而运营商为了最大实现带宽价值，一般会多放节目，而压缩升级带宽，特别是卫星带宽，一般只有几百K 的带宽，而对于要升级相对大的数据，下载就会非常的缓慢，使得用户体验不太好。而且升级APP 的下载过程中断电，或者写flash 的过程中断电，都会引起下一次再进入到升级APP 升级。而后台升级，并不会影响到用户体验，当后台检测到升级，直接将数据下载到升级分区，这个过程网络不好，或者断电造成下一次升级，对于用户来说，没有任何影响。

两种方式在boot 实现上相比较：两种方式在boot 阶段都会检测是否有升级标识。当检测到有升级标识时，前台升级是进入到升级APP 去升级。后台升级是校验备份分区的数据正确后，将数据写到相应的分区。由于boot 是去读升级分区的数据，所以需要保证升级分区的地址不会更改。否者会涉及到boot 的修改，对于高安的boot，一般来说，需要到高安公司签名，一旦签名后，boot 是不可修改的。而前台升级只是涉及到检测标识和跳转，功能要少一些，一般改动的可能性较小，对于高安项目，前台升级更有优势一些。

由以上分析，我们得知，对于需要boot 签名的高安项目，最好采用前台升级方式；对于开发周期短，用户环境比较恶劣（比如数据下载带宽小，容易停电）的情况，最好采用后台升级的方式。所以，在开发前期的各种数据信息收集非常有必要，以免为后期开发，或者市场维护造成困难。

5 结束语

数字电视的升级看起来很简单，但是涉及到系统安全，用户体验，运营商成本等多种因素，需要软件从业人员花很多时间认真学习，不断摸索，掌握其中的原理，从实际应用场景考虑。从而才能设计出更高效，易用的软件，使终端用户体验达到极致。