CMMB标准紧急广播m务的研究与应用

2．2 EBP客户端的处理流程

(1)关键消息

①需要CMMB协议栈通知的消息：MSG_EBP_COME。当CMMB协议栈发现有紧急广播消息时，给EBP客户端发送预先定义好的MSG_EBP_COME消息。
  　  ②EBP客户端核心给UI发送的消息：a．EBP_RECEIVE_OK，客户端成功接收到新的紧急广播消息，需要UI展现层做相应的展现；b．EBP_RECEIVE_TIMEOUT，客户端接收紧急广播消息超时失败。

(2)关键数据结构

①EBP_Index：紧急广播索引，图3所示的本地管理层通过该数据结构来管理本地保存的紧急广播消息。
   　 ②EBP_Table：紧急广播表，对应图2所示的表标识为0x10的控制信息表的格式，图3的解析层中第1次初步解析出的数据用该结构保存。
　    ③EBP_MessageInfo：非触发消息，图3的解析层中解析出的非触发消息用该结构保存。
 　   ④EBP_TriggerInfo：触发消息，图3的解析层中解析出的触发消息用该结构保存。
 　   ⑤EBF_MsgInfo：紧急广播消息，由于1个紧急广播消息只可能是触发或者非触发中的1种，为了逻辑上和流程上便于处理，该结构联合上述结构3、4，统一为1个结构。
 　   ⑥EBP：对本地管理层暴露的紧急广播消息结构，对EBP_MsgInfo的封装，加上一些上层需要用到的属性域。
 　   ⑦EBP_CURSOR：本地管理层定义的数据结构，供接口层使用，通过该结构访问响应的紧急广播消息。
 　   ⑧EBP_LangContent：存储非触发紧急广播消息中的语种相关信息。
 　   ⑨EBP_Ext：存储非触发紧急广播消息中辅助信息的相关内容。

(3)关键接口

(D int32_t ebp_receive_data(uint8_t*path)；功能：接收紧急广播表。
　    ②static int32_t ebp_table_decoder(uint8_t*bur，int32_t len)；
   　 功能：解析紧急广播表。
   　 ③static int32_t ebp_message_decoder(uint8_t* *buf_adr，uint32_t len)；
 　   功能：解析紧急广播具体内容。
  　  ④CMMB_EBP_CURSOR ebp_create_cursor(void_t)；
  　  功能：创建游标。
   　 ⑤CMMB_EBP_CURSOR ebp_get_nextcur(EBP_CURSOR cur)；
 　   功能：获取当前游标cur游标的下一个游标。
　    ⑥int8_t ebp_getebp(EBP_CURSOR cur，EBP_MESSAGE*msg)；
 　   功能：获取cur游标对应的紧急广播消息具体内容填充在输出参数msg中。
   　 ⑦static int32_t ebp_checkout(void_t)；
  　  功能：检查索引并删除过期EBP索引及相关文件。
 　   ⑧int8_t ebp_cancel_receive(void_t)；
  　  功能：取消紧急广播消息接收。
   　 ⑨int32_t ebp_set_curfreq_ebpupdate(uint32_t cur_freq)；
 　   功能：设置频点cur_freq的紧急广播消息更新序号。
  　  ⑩static int8_t ebp_read_sared_ebp(EBP*ebp，EBP_Index*index)
 　   功能：读取本地保存的紧急广播。
   　 ⑩int32_t ebp_suspend()；
   　 功能：阻塞紧急广播消息接收线程。
 　   ⑩int32_t ebp_active(void_t*param)；
   　 功能：激活紧急广播消息接收线程。

(4)主要流程

本EBP客户端主要流程分为以下几步：

①本客户端启动后，等待CMMB协议栈发送MSG_EBP_COME消息。收到该消息后，表明当前CMMB网络中有紧急广播消息。EBP客户端使用ebp_receive_data(uint8_t*path)接口接收紧急广播表。该接口同时设置标志位，在其进行紧急广播消息接收的过程中，暂不响应新的MSG_EBP_COME消息。

②用ebp_table_decoder接口对紧急广播表进行解析，得到1组EBP_Table数据。

③用ebp_message_decoder接口对EBP_Table数据进行进一步解析，得到1组EBP_MessageInfo或EBP_TriggerInfo数据，并检查删除已经接收过的消息，然后将新收到的紧急广播消息封装为EBP结构，并加入到已接收的EBP链上。

④EBP客户端核心层给用户UI层发送EBP_RECEIVE_OK(如前三步失败发送：EBP_RECEIVE_TIMEOUT)消息。

⑤用户UI层根据步骤4发送的消息来做相应的处理。a．如果是EBP_RECEIVE_OK消息，则使用关键接口中的4、5、6接口便可以获取各个紧急广播消息，并在界面上做响应展现。接口4内部会去判断并删除过期的紧急广播消息。

当新接收的紧急广播消息中有紧急程度为1级或者2级的紧急广播时，直接弹出图4所示的界面。新接收的紧急广播消息紧急程度都是3级或者4级时，仅需要给用户1个闪烁提示，由用户选择是否观看紧急程度不太高的广播消息。b．如果是EBP_RECEIVE_TIMEOUT消息，本客户端采用的策略是首先调用ebp_cancel_receive接口，对此次接收失败的环境进行清理，然后过10分钟再次进入步骤②。

(5)减少客户端移植工作量的探讨

嵌入式软件开发与PC软件开发很大的区别是，嵌入式软件设计中必须考虑目标机的差异性，如不同屏幕尺寸、不同分辨率、不同硬件接口、不同GUI系统，甚至不同操作系统。如果本EBP客户端软件的设计中没有考虑便于移植的因素，那么适配这些适用于CMMB技术的手机、游戏机、PDA、车载GPS、MP4，所需工作量将是非常大的。正是考虑到这个因素，所以本客户端做了以下2方面工作来简化移植工作。

①逻辑与GUI的解耦，也就是图3所展现的核心层与UI层的分离。核心层的职责是管理紧急广播消息的接收、解析、本地管理。UI层的职责是监听核心层发送的EBP_RECEIVE_OK消息，收到该消息就利用接口层提供的3个接口ebp_create_cursor、ebp_get_nextcur、ebp_getebp，像使用迭代器那样访问接收到的紧急广播数据。这样的好处之一是，在支持相同GUI系统的终端间移植该客户端时，在用户UI层不需要任何的移植工作。好处二是，该层使用EBP_CURSOR(当前版本定义是typedefvoid_t*CMMB_EBP_CURSOR；)访问顶层数据，如果以后核心层使用的数据结构改变，如"typedef int CMMB_EBP_CURSOR；"，也就是说存储紧急广播消息由链表改为数组，该层也不需要作任何改变。

②核心层中的分层。核心层之所以分为3层的原因是，接口抽象层和EBP解析层在移植的过程中可以保持不变，而本地管理层在移植的过程中可能因为文件系统不同而必须修改具体操作。所以在核心层中将该层抽取出来，在移植客户端核心层时只需要关注该层即可。将EBP解析层与接口层分离的目的是，给用户UI层仅暴露出接口层的接口以及数据结构，使其关心的内容局限于自己所需要的数据结构，不需要去关心不会直接使用且可能会因为架构上的调整而发生变化的问题。这样如果由第三方来实现用户UI层，可以简化其开发。
    在最初的原型设计中，并没有采取这种分层的结构，而是将逻辑与GUI混合在一起，在移植到不同的平台时发现增加的工作量十分大且极易出错。所以决定在移植前采取重构，重构后的结构就是本文所描述的设计架构，后来的移植工作量就很少，也很简单了。本次设计令笔者切身感受到这种逻辑与UI分离的思想带来的好处。

2．3 运行效果截图

本客户端接收过程是后台接收，运行效果如图4所示，该图是在支持CMMB的Windows Mobile5手机上运行，用SuperSnap工具截屏得到的。左边的标签表示接收紧急广播消息的时间，通过标签可以切换右侧内容，观看具体的紧急广播消息。所使用的测试数据为中国数字电视论坛上的CMMBMFS测试样本码流。

结 语

以上的设计和实现充分考虑了空间和效率这两大要素，通过和市面上其他产品进行比较，该系统能够在存储空间更小、处理速度更慢的移动设备上流畅地运行，取得了令人满意的效果。

本设计中的EBP客户端程序能够成功接收CMMB网络中多个频点发送的紧急广播消息，并且客户端具有一定的键壮性，可以通过较少的移植工作量使其工作在适用于CMMB技术的手机、游戏机、PDA、车载GPS、MP4，达到了预期目的。相信随着CMMB网络的日渐成熟，CMMB标准的紧急广播应用必然会在我国灾害预警中起到重要作用。