基于epg的服务器计算中的代码升级.docxVIP

基于epg的服务器计算中的代码升级 屋顶的功能基本上是软件实现的。很多盒子都是用完的。大多数问题都是由软件引起的。要解决这些问题，必须修改山顶的应用。在这种情况下，代码更新功能应该发挥重要作用。特别是当出现新功能或新应用需求时，软件必须依赖代码更新功能来完成。因此，代码更新是山顶设备中常用的功能之一。 但是,代码升级不是机顶盒厂家软件来了就可以升级,它有时并不那么简单,不同的系统可能会遭遇到不同的问题。笔者就经历了一次比较艰难的代码升级过程。 1 系统的实现方法 数字电视的前端采用同密方案,由中视联Chinacrypt和爱迪德Pisys完成同密。前端建设时,尽管有机顶盒厂家和第三方竭力推荐各自的EPG,但是为了平衡机顶盒厂家之间的关系,同时减少由于EPG供应商要求机顶盒集成自己的EPG而造成机顶盒的成本提高,运营商没有购置机顶盒厂家或者第三方的EPG,而是由同密CA的双方来“合成”一个完整的EPG,具体的做法是:由爱迪德Pisys的SIG模块来生成NIT及SDT/BAT,由中视联的EPG生成所有的EIT(EIT p/f,EIT Schedule)及TDT,PSI表则由复用器生成。 各厂家在代码升级的消息发送方式上不一样,中视联CA的代码升级是通过NIT表中linkage_descriptor来“通知”机顶盒当前有代码升级要求的,而爱迪德则是通过BAT表中的bouquet 13858来“通知”机顶盒的。所以,为了保证中视联CA的代码升级功能的实现,爱迪德根据中视联Chinacrypt的loader规范要求,在SIG中增加了中视联CA的代码下载功能,能够生成中视联CA代码下载所需的linkage_descriptor。 2 下载代码流的排除 某厂家为运营商提供了两款机顶盒,分别集成中视联和爱迪德的CA,因业务的需要,急需对该两款机顶盒进行代码升级。 首先升级的是中视联CA的机顶盒。该机顶盒的升级有两种方式:一种是在正常使用中通过NIT/BAT表中的信息来自动引导到升级流,使机顶盒接收升级代码,称之为SI引导升级;另一种是在打开电源的同时按下特定的功能键,使机顶盒直接进入代码升级程序,通过交互界面,输入代码下载流所在频点和符号率,使机顶盒接收升级代码,称之为手动或强制升级。 由于是在较长的时间跨度内向运营商提供的机顶盒,集成中视联CA的机顶盒尽管使用的都是中视联的loader,但loader的版本不一样,有V.27和V.271,而当前使用的是V.274的loader,所以,首要任务是统一机顶盒的loader平台,即通过代码下载功能升级机顶盒中V.27及V.271的loader为V.274。 为了提高代码下载的速率,方便调试,使用了一个独立的流来承载代码。在EPG完成后,曾经做过代码升级的测试,在SI的发送上应该没有问题,所以,在前端上配置完相关的数据后,很有信心地用机顶盒接收,机顶盒很快就检测到了网络上有升级信息,并也弹出了升级提示窗口,但是当按下确认去下载代码流时,机顶盒却很快弹出提示窗口:无法检测到升级流。 为了解决问题,采取了逐步排除的方式: (1)应用程序不对?通过机顶盒的串口,直接向机顶盒内写入升级程序,机顶盒升级成功,说明应用程序没有问题。 (2)程序打包成TS流的时候出了问题?将从loader服务器出来的TS流直接送入QAM调制器,采用强制升级方式,机顶盒能够升级成功,说明程序的打包也没有问题。 (3)代码流没有通过复用器,或者通过复用器时出错?将从loader服务器出来的TS流送入复用器,并透传TS流中的PSI/SI表,采用强制升级方式,机顶盒也能够升级成功。 (4)在步骤3的基础上,用Pisys生成的NIT表替换loader播放服务器出来的TS流的NIT表,采用强制升级方式,发现机顶盒无法检测到下载流。 通过步骤3和4的比较,找到了原因,即NIT表提供了不正确的数据。比较两个NIT表,发现两张表的linkage_descriptor不一样。Loader服务器播出来的NIT表的linkage_descriptor为: 显然,在linkage_descriptor中,不仅private_data_byte不一样,descriptor_length所指示的长度也不一样,这样机顶盒找不到升级流也就不难理解了。 经向厂家询问,Chinacrypt自己的打包程序生成的private_data_byte中,后面连续的16进制字符“0”是保留的,暂未定义其作用。尽管如此,实验表明,如果private_data_byte中省略这些“0”,机顶盒也不能升级。 在Pisys的中视联代码下载配置中,提供了“用户定义数据”栏,可以在private_data_byte后面附加数据。但经过反复试验,Pisys会认为“用户定义数据”栏中输入的是