面向安卓平台有线电视网管系统的实现

王天琪，张文波，张 铁，周 帆

(沈阳理工大学 信息科学技术与工程学院，沈阳 110159)

随着我国三网融合政策启动执行，建设数字化和双向化的有线电视网络也成为城市化前进的重要方向。有线电视网络行业正在实现网络资源优化配置，提高其业务承载能力及其业务综合信息处理能力[1]；提高网络服务质量，优化网络结构[2]，积极整合全国各地的有线电视网络业务；具有网络运营维护能力的网络管理系统和营业支持体系也正在创建中。然而，如今市面上仍存在一些早期生产的有线电视设备，并不支持统一的SNMP协议，导致难以对所有的有线电视设备进行统一管理，为了使这些设备也能进入网络管理，需设计支持SNMP协议的代理转换器，获取设备的运行参数，将不统一的通讯协议均转为SNMP协议，然后再执行网络通信，以实现有线电视网络的统一管理。

现在有线电视网络规模处于大幅度上涨趋势，对其管理的任务也变得越发艰巨。传统有线电视网络管理系统是通过电脑客户端的方式或者是基于万维网(WEB)的方式来管理[3]，而且不能直观并统一的对有线电视设备运行情况进行监测，这使管理人员不能对有线电视网络中出现的故障做出及时的查看分析与有效的维护。而安卓(Android)平台是具有强大的程序处理能力的平台，并具有兼容性强、设计简单、操作方便的特性[4]。故此，本文面向Android平台设计并实现了更人性化、更智能化的有线电视网络管理系统。此系统可实现网络管理人员对所有网络设备实时监控和异常点定位，及时发现并解决有线电视网络故障。

1 系统整体框架设计

一般网络管理系统通常采用的设计方式是层次结构设计模式，将每个层次的功能进行封装，采用接口方式对外调用，所以当层次中的任何一层发生变化时，只要接口不改变，则这一层的上一层和下一层功能均不受影响。鉴于以上优点，本系统同样采用层次结构的设计模式，如图1所示，有线电视网络管理系统自上而下分别对展示层、服务层和代理层进行功能性设计与实现。

图1 系统架构图

1.1 展示层设计

1.1.1 展示层架构

本系统的展示层主要负责对有线电视设备运行信息、设备异常点定位等各项性能及地图进行具体化显示并实现用户与信息模块交互，对于展示层的设计模式采用MVP(实体层-视图层-表示器)模式进行设计，如图2所示。

图2 MVP架构图

在MVP模式里，V为视图层，将活动的界面逻辑抽象成V接口；M为实体层，是实体类，用来存储数据；P为表示器，主要表示程序逻辑。当V发生变化时，其先将请求数据传输到P，再从P发送到M并监听数据变化；M将结果反馈给P，P通过接口与V进行互相通信，最终V进行界面显示[5]。而M与V不能直接交互，它是通过P间接与V交互的。

1.1.2 客户端功能设计

本系统的客户端即是展示层，如图3所示，其设计根据实际需求主要分为三大功能模块。Android客户端结合移动端GIS技术向用户展示有线电视设备各项信息和服务层推送的设备异常告警信息，并且展示地图及各个设备的地理位置[6]。在用户管理方面，实现有线电视资源可视化管理，对网络资源进行数据查询、信息增添、清除用户信息和修改密码等设置；在资源管理方面，展示并解析预测设备的各项性能的运行状况；在故障管理方面，对发生故障设备进行故障等级分类、异常告警、生成故障日志、定位设备及工作人员的位置。

图3 客户端功能结构图

1.2 服务层设计

1.2.1 服务层架构

服务层采用分布式架构进行构建，具体设计架构如图4所示，服务器相当于管理者，底层信息采集进程是由多个进程组成且彼此相互独立，当其中一个进程出现异常的时候，系统的整体运行仍能正常进行。

1.2.2 服务器端功能设计

系统服务器主要解决Android客户端所发出的各类请求，把代理层所采集到的有线电视设备实时运行的性能参数及其发出的异常告警消息存储进系统数据库，最后把数据库中的数据上传给Android客户端展示。

图4 服务层架构图

在资源管理方面：当客户端对资源管理模块发送请求时，资源管理进程会按相应的请求调用SNMP配置报文，并将报文传送至代理层的SNMP网管代理，再进行剖析报文并协议转换，与底层有线电视设备经由串口通讯进行交互并获取相应的数据，最终返回呈现给用户；在性能管理方面：由系统服务器定时对网络管理系统中所管的设备进行轮询，将获取每一台有线电视设备的性能参数，存储至系统数据库。并在解析处理有线电视设备的性能参数后，为每个参数设置临界值，这样可以明显而清楚地观测到有线电视设备各项参数与临界值的差偏程度，预知设备可能的异常情况。

推送服务器负责故障检测并向Android客户端主动上传陷阱告警信息，在故障管理监测到有线电视设备发生异常时，先对故障进行等级划分，对于简单的故障可自动解决，无法直接处理的故障采用推送方式将故障消息上传给客户端展示[7]。推送功能采用的是基于Android平台的消息推送技术中的Android推送通知(AndroidPN)技术[8]。此技术在开发过程中只需利用AndroidPN框架中的云服务，这可以减少搭建新服务器的负担，同时可以提高移动设备的续航力，并降低流量的损耗。

底层设备信息采集进程通过串口通信进程与光纤传输平台之间进行通讯，获得设备性能数据并存入数据库中。把管理信息库(MIB)中读取出设备参数封装成SNMP请求报文，然后传送到SNMP网管代理层。当系统服务器收到反馈的响应报文后，将对报文进行解析，并将数据存入系统数据库库中，以便系统服务器向客户端提供数据查询服务。

本系统有线电视设备的运行参数以及用户数据都存储于系统数据库，客户端采用Android开发平台自带的数据库来进行数据缓存，在系统数据库设计上采用MySQL数据库。根据所采集底层数据的不同属性，对数据库中的信息进行详细设计，包括共有属性信息表、机房信息表、设备参数表和Trap告警信息表。

1.3 代理层设计

1.3.1 代理层架构

代理层主要的功能是收集有线电视设备的运行数据及异常告警信息，再将响应请求反馈给上一层，使上层及时并准确的接收有线电视设备性能数据。如图5所示，SNMP网管代理接收和响应系统服务器发送的SNMP报文请求并分析报文类型，然后主动向管理站传送告警信号；为拥有自定义通信协议[9]的有线电视设备配置对应的协议转换策略，这样代理层便可以分析处理各种型号的有线电视设备的通讯策略，使所有的有线电视设备都通过SNMP协议与互联网进行交互，实现多种有线电视设备的统一管理。

图5 代理层设计结构

1.3.2 协议转换器的设计

GI公司的OmniStar设备可以同时管理多台不同型号的有线电视设备，但其只支持串口通信，且每台个人计算机只能一对一的对设备进行监控，针对以上缺点设计了基于S3C2416的15路串口的协议转换设备，如图6所示。网管代理协议转换器的内部构造分为四大模块，分别为Power、CPU CoreBoard、Mother Board和Front Panel。其背面设计有15路串口，最多可串联管理75台OmniStar设备，不但能满足对设备统一管理的要求，同时解决了串口通信的局限性问题。

2 系统的实现

2.1 系统开发环境

为方便有线电视网管系统的客户端与服务器端同时开发，所以客户端程序与服务器端程序都在Windows 7操作系统环境下实现的，客户端程序在Eclipse开发工具上实现，MyEclipse开发工具用于服务器端功能实现。

图6 协议转换器设计

2.2 客户端功能实现

有线电视网管系统的开发也遵循Android程序安装启动的流程，如图7所示，在进入欢迎界面、系统引导和用户注册登录等流程之后，便进入具有四个不同功能的页面：“消息”、“资源管理”、“故障维护”和“我”共四个导航按钮，系统主界面使用碎片(Fragement)实现。

图7 系统启动流程图

资源管理功能模块主要实现两个性能，一个是机房信息的查看；另一个是监测有线电视设备实时运行的状态，通过机房号、设备名字、设备端口号或者代理设备的IP地址来确定查看某一台设备，点击查看设备按钮，便会跳转到设备运行状态的界面，如图8所示。

图8 机房信息图

故障管理功能模块需要实现如下三个性能，一个是收集故障信息并发送提醒，通过在AndroidPN源码里增加闹钟提醒功能来实现；另一个是对于维护人员的定位实现，在Android客户端程序导入百度地图Android版开发包，设置GPS的定位方式以实现定位[10]，如图9所示；最后是生成故障日志，按照每个故障的告警说明、告警发出的时间、告警设备的识别码、故障设备的端口号、告警的严重级别以及异常的所属类别的顺序进行记录。

图9 定位展示界面

2.3 服务器端功能实现

系统服务器针对Android客户端发送的不同类型的请求实现不同的服务，从MIB中提取与之对应的设备参数上传给客户端。服务器与数据库采用单例模式实现连接，对于上层的取值响应时间，设置定时查询机制，在定时查询的时刻设置时间戳，这样当客户端发送请求在一个时间戳内时只需连接一次数据库即可，减少了系统响应时间；另外系统服务器以轮询的方式[11]与SNMP代理进行协议通信，定时访问底层SNMP网管代理获取有线电视设备实时运行的参数，将数据存入到系统MIB中。

推送服务器是一个独立的服务器，在系统服务器开始运行之后，告警监控程序也随之启动，当服务器监听到Trap报文时，可以通过解析告警信息中的数据来查询有线电视机房的坐标定位，如若查询成功则将与其对应的坐标和信息显示在地图上，并把异常信息上传到客户端，若匹配失败则记入告警日志中。

2.4 SNMP网管代理的实现

SNMP网管代理主要调控各端口有线电视设备的通讯和数据分析，通过串口通信获取设备的各项数据，并将数据打包成SNMP报文发送给上层服务器进行统一监测和管理。针对不同串口通信协议的有线电视设备，获取其性能参数，设计与之对应的SNMP报文并在数据库中为其配置相应的性能属性，从而完成协议转换。另外，Trap告警推送通过SNMP Trap主动向监控端发送故障告警信息，并对轮询查询请求和转换成SNMP报文格式的Trap告警信息等进行处理[12]，监听流程如图10所示。

图10 Trap监听流程图

3 测试与分析

3.1 系统响应时间测试

本部分测试是指从客户端发出某种请求到客户端接收到反馈信息的时间间隔和系统弹出消息界面所用时的总和。当服务器端第一次接受到客户端用户发送的查询指令时，会经由SNMP网管代理进行信息查询，把获取的数据存入MySQL中，然后设置时间戳，若用户的查询指令在一个时间戳内，且不会多次对代理层进行查询访问，实际上直接从MySQL中获取数据即可，从而提升了系统的运行速率。

表1 查询操作响应时间

从表1中的五组数据中可以看出：第2组数据从发送请求时间到系统反馈时间结束的所用时间远超过另外4组数据。其原因是第2组发送请求信息时不在上一个时间戳内，需要重新向SNMP网管代理发送查询请求，然后再把反馈的数据存入系统数据库中，这个过程延长了查询操作的响应时间，而其它4组数据则是直接从数据库中获取数据。整个测试结果表明，客户端与服务器端交互查询系统数据库信息的响应时间基本维持在0.1s，满足了对本系统的需求。

3.2 系统故障响应时间测试

本系统的故障响应时间测试是从设备发生故障到接收故障消息的响应时间。当有线电视设备出现异常时，系统需在最快的时间里定位故障位置，并进行异常分析与修护，以保证系统的正常运行。如表2所示，从制造故障到客户端接收到故障消息的所用时间的五组数据均维持在10s范围内，测试结果表明本文设计的故障提醒功能可以满足本系统的要求。

表2 故障消息响应时间

3.3 并发测试

并发测试是模拟网络管理系统有多个客户端同时运行的情形，在保证系统正常工作的前提下，检测系统所能承受的最大登录用户数。此部分测试是在实验室的PC机上模拟，观察系统的运作情况，测试出管理系统能够承受的最大用户数。图11是对系统进行不同用户数的压力测试情况。

图11 查询操作响应时间

图11中四条折线分别表示五十个、一百个、二百个和二百五十个用户在并发执行操作网络管理系统时，网管系统反馈给客户端发出指令事务的时间。测试结果表明，当同时执行操作的用户数低于二百时，系统可以比较稳定地处理各个用户的请求；当有二百五十个用户并发操作时，事务平均响应时间显然增涨，系统的运转效率严重降低。

4 结束语

本文针对有线电视设备的网络管理需求深入的剖析与讨论后，结合当前Android系统的优势，应用移动端GIS技术以及SNMP协议，设计并实现了面向Android平台的有线电视网管系统。系统总体分为展示层、服务层以及代理层，各层分别对应Android客户端、服务器和SNMP网管代理进行了结构设计与功能设计。对本系统进行测试结果表明，本系统达到客户对响应时间和系统稳定性的需求，可以持续平稳地处理多个客户端的并发操作，系统基于Android平台开发，不仅方便设备的监控，而且便于对设备进行维护。