刘鹏 周永辉 颜灵伟 韩洪波 李强

（北京空间飞行器总体设计部，北京 100094）

1 引言

由于航天器遥测参数具有类型多、数据量大和变化复杂等特点，利用计算机技术实现对航天器在轨运行情况的实时自动监测报警，能够避免仅依靠人工监测带来的效率低、漏检多、及时性和准确性差等诸多问题，具有十分重要的应用价值［1］。

随着Web技术的流行，越来越多的实时监测报警系统从客户机／服务器（C／S）模式转变为浏览器／服务器（B／S）模式，具有跨平台、免客户端维护、扩展性好等优势。现有B／S 模式下实时交互的解决方案主要包括：基于Ajax的轮询［2］、基于浏览器插件技术的服务器推送［3］和无插件的服务器推送［4］。其中：基于Ajax的轮询方式以异步方式传送数据，通过页面局部刷新，消除因网络延迟带来的视觉差异，但是轮询的时间间隔难以合理设置，间隔太长会导致更新不够及时，间隔太短又会导致交互频繁，增加网络和服务器的负荷；基于浏览器插件技术的服务器推送方式，通过在浏览器中安装插件来模拟C／S模式，实现服务器主动推送数据，但这无疑失去了B／S模式的跨平台、免客户端维护等优点，加大了系统升级和维护成本；无插件的服务器推送方式既不需要客户端周期性的轮询，也不需要在浏览器里安装任何插件，而是在服务器端以事件驱动方式主动向客户端推送数据［5］，实现数据的实时刷新。Pushlet［6］是无插件服务器推送方式的一种典型实现架构，主要应用于实时监测动态数据的领域，包括股票、天气、航班信息等，著名的Google Map 就采用了这种架构，实现地图数据到客户端的推送［4］。

国内航天器在轨实时监测报警系统主要采用了基于Ajax的轮询方式，为了保证实时性，客户端轮询的时间间隔通常设置为1s。实际应用表明，航天器实时监测报警信息具有突发性、间断性和频率低的特点，系统正常运行时平均每天的报警信息可能只有几条，但却需要客户端频繁轮询以获知是否有报警，在较长时间运行后，服务器端资源消耗较大，尤其是在突然出现大量遥测参数同时报警时，系统会出现刷新慢甚至无反应的现象。本文基于Pushlet架构，设计了一个B／S模式的航天器在轨实时监测报警系统。该系统具有实时性强、效率高和稳定性好的优点［7］，可解决现有系统中存在的上述问题。

2 系统架构设计

在航天器在轨运行管理业务中，要求对航天器下传的遥测数据进行实时监视，对遥测数据所反映的航天器运行状态进行实时判读。当在轨异常发生时，要求监测人员迅速作出响应，对异常信息进行查询、分析和处理，以提高航天器在轨运行稳定性，减小对用户使用的影响。针对以上需求，航天器在轨实时监测报警系统应具有实时监测，并能显示报警信息、查询历史报警信息和相应的报警管理功能，其系统架构设计如图1所示。

为了使不同终端可以获取不同的事件信息，系统采用了“发布／订阅”模式［8］。客户端需要首先订阅在服务器端的某个主题（Subject），而服务器端则接收订阅并进行注册，当服务器端有关于该主题的新事件产生时，会主动将其推送到订阅了该主题的客户端。如图1所示，在服务器端由命令控制器统一接收来自客户端的请求，包括来自管理端的管理报警主题、来自监测端的订阅报警主题和来自查询端的查询历史报警3种请求，并分配给相应的管理器进行处理，具体内容如下。

（1）管理员对报警的主题进行创建、更改或删除等操作，命令控制器将这些管理命令交由主题管理器，由后者根据命令维护报警主题与航天器之间的关系；

（2）主题创建之后，用户可通过订阅报警主题来监控相应的航天器，命令控制器将订阅命令交由订阅会话管理器，由订阅会话管理器在会话池中创建一个新的订阅者会话，并注册相关信息；

（3）当用户查询历史报警信息时，命令控制器将查询命令交由报警查询管理器，由报警查询管理器检索报警信息数据库，并返回查询结果。

报警判读模块负责对实时遥测数据进行判读，产生报警信息并发送给报警事件源，同时将报警信息存储至报警信息数据库中，以供事后查询。报警事件源根据主题管理器提供的报警主题与航天器对应关系，将报警信息转换为报警事件，并由事件派发器通过订阅会话管理器派发给相应的订阅者会话，最终由每一个订阅者会话分别向对应的订阅客户端推送实时报警事件。

图1 系统架构Fig．1 System structure

3 实时监测报警的实现

3．1 创建主题

系统中的主题是按照结构化的“主题树”方式组织的，假设需要按照所属领域来分类监测航天器，则“主题树”的结构如图2所示。

图2 主题树结构Fig．2 Subject tree structure

图2中的每一个层次都唯一对应一个主题，在系统中表示为字符串的形式，分别为：“／所有航天器”、“／所有航天器／导航领域”、“／所有航天器／遥感领域”、“／所有航天器／通信领域”、“／所有航天器／深空探测领域”和“／所有航天器／其他领域”。

管理员通过管理端界面将各个航天器添加到其所属的主题中，建立主题与航天器的对应关系，由服务器端的主题管理器进行维护管理。主题创建完成后，以Web链接的方式在页面中呈现，用户在客户端的Web浏览器中访问监测系统时，通过点击各主题链接来订阅主题。

3．2 订阅主题

客户端在发出订阅主题的请求之后，服务器端通过订阅会话管理器在会话池中创建一个订阅者会话，并进行注册，由该会话负责维护与客户端之间的连接。在每一个订阅者会话中，主要包含会话标识、订阅事件的主题、与客户端的连接状态、一个用于缓存事件的事件队列以及接收事件所采用的格式，默认为JavaScript软件调用，此外还有XML 或者Java序列化对象。当有相应主题的事件发生时，服务器会根据注册的订阅者信息，将事件发送回客户端进行更新显示。

由于客户端可能存在多个请求，因此将订阅请求的统一资源标识符（URI）加入JavaScript类库中的控制队列，由其按照先进先出的顺序将订阅请求发送至服务器端。在具体实现时，先调用join-listen（）方法，启动会话，注册并监听数据；然后调用subscribe（）方法，订阅相关主题。

当用户订阅了“主题树”中某一层次的主题时，也就订阅了属于该主题层次之下的所有层次主题事件。例如，当选择订阅“／所有航天器”这一主题时，会收到5个子层次主题的所有事件，从而实现监测所有的航天器。

3．3 报警事件的产生

在Pushlet架构中，发布给客户端的变化信息是通过事件的形式实现的，与订阅者会话一样，每一个事件也对应一个主题。因此，在本系统中，当某一个航天器的遥测参数出现异常时，需要在服务器端将相应的报警信息转换为一个报警事件，报警事件的产生流程如图3所示。

图3 报警事件的产生流程Fig．3 Generation flow of alarming event

在图3中，报警判读模块负责对实时遥测数据进行判读，当发现某一个航天器的遥测数据出现异常时，即生成报警信息，内容包括航天器型号代号、报警参数代号、报警时间、报警级别、报警值和报警原因等信息。报警判读模块一方面将报警信息存储至报警信息数据库中，供用户查询历史报警信息，同时将其加入至一个实时的报警信息队列中；报警事件源负责从报警信息队列中读取报警信息，根据主题管理器中记录的每一个航天器对应的主题类型，组合创建报警事件。报警事件在系统中以对象方式存在，内部通过hashmap数据结构，将报警信息封装为多个属性-值对，并对外提供setField（）和getField（）方法进行存取。例如，代号为“test1”的通信卫星的“para”参数，在“T0”时刻发生1次“轻度”级别的报警，报警值为“51”，原因是“超过正常值范围［0，50］”，则报警事件源中创建报警事件的代码如下所示。

在编码实现时，报警事件源对应的类需要实现EventSource接口，该类和报警判读模块均设计为“守护线程在持续运行”，两个线程之间采用生产者／消费者的设计模式实现同步机制。当报警信息出队时，如果报警信息队列为空，则事件创建线程会被挂起，直至报警信息队列中有事件时即被唤醒；反之，当报警信息入队时，如果报警信息队列已满，则报警判读线程会被挂起，直至报警信息队列有空位时即被唤醒。这种机制能够确保报警信息来临时可以及时获知，并创建报警事件。由于并不是每一帧遥测数据都会出现异常，因此报警信息的产生频率较低，报警信息队列的入队速度相比出队速度会慢很多，这样，报警信息队列永远不会满，也就不会存在遗漏报警信息的问题。

3．4 报警事件实时发布

报警事件产生后，报警事件源将调用事件派发器统一进行派发。事件派发器采用单例模式实现，是事件派发的唯一接口。由于订阅会话管理器维护着会话池，因此事件派发器需要通过订阅会话管理器遍历会话池中的每一个订阅者会话，当发现报警事件的主题和订阅者会话的主题匹配时，就把报警事件加入到该订阅者会话的报警事件队列中；同时，订阅者会话不断地从自身的报警事件队列中取出报警事件，然后将其转换为JavaScript格式并推送到客户端浏览器。整个报警事件实时发布的流程及各模块之间的交互关系，如图4所示。相比事件派发器直接将报警事件发送给用户，上述方式不会因为某一个客户端接收慢而被阻塞，能够提高系统性能。

图4 报警事件的发布时序Fig．4 Publish sequence of alarming event

为了能够实现“主题树”的按层次订阅，主题匹配采用了前缀匹配的算法。例如：当某通信卫星产生一个报警事件时，其对应的主题是“／所有航天器／通信领域”，而对于选择监测所有航天器报警信息的客户端，其订阅者会话中对应的主题是“／所有航天器”，当进行主题匹配时，由于“／所有航天器”是“／所有航天器／通信领域”的前缀，在“主题树”中处于更高一个层次，因此，该通信卫星的报警事件不仅会被加入到主题为“／所有航天器／通信领域”的订阅者会话的报警事件队列中，同时也会被加入到主题为“／所有航天器”的订阅者会话的报警事件队列中，对应的选择监测所有航天器报警信息的客户端也就能接收到该事件。

3．5 长连接的维持

由于在B／S模式下，客户端的Web浏览器会在每一次请求的响应正常结束或是超时后，就关闭与服务器端的HTTP连接，因此，当长时间没有报警信息产生时，服务器端需要定时发送心跳消息来维持与客户端的长连接，以避免客户端的Web浏览器认为服务器端长时间没有响应而关闭连接。

在具体实现时，客户端包括两个框架（Frame）：持久连接框架和显示框架。持久连接框架被设置为隐藏，由其保持与服务器端的HTTP 持久连接，并接收来自服务器端的JavaScript代码，然后利用这些JavaScript代码更新显示框架的内容，从而实现动态向客户端推送数据。

下面的代码给出了通过心跳信息来保持HTTP连接的一个实现示例。该循环保证了连接不被关闭，以流的方式把报警事件发送到客户端。

4 测试结果

基于Ajax的轮询方式实现一个报警原型系统，客户端轮询的时间间隔设置为1s；同样，基于Pushlet架构的推送方式实现一个报警原型系统，心跳周期设置为30s。利用1台服务器和1台监测机搭建测试环境，测试时间为1h，其中每10min产生1次报警信息。

通过Ethereal测试工具抓包分析发现：每次报警信息产生后，两种方式对应的响应时间均小于1s；但是，在没有报警信息产生时，对于基于Ajax的轮询方式，每1s发往服务器的轮询信息有效长度为77byte，对应服务器返回的应答信息有效长度为56byte，而对于基于Pushlet架构的推送方式，每30s服务器发送的心跳信息有效长度为10byte。由此可以看出，在同样满足实时性要求的情况下，基于Pushlet架构的推送方式比基于Ajax的轮询方式所造成的网络负载要小很多。

5 结束语

本文结合航天器在轨运行管理的任务需求，提出了基于Pushlet架构的航天器在轨实时监测报警系统的实现方案。测试结果表明，该系统能够将服务器端数据判读产生的报警信息实时、主动地推送至客户端浏览器，相比传统的请求-响应方式，具有实时性强、效率高和稳定性好的优点。这一系统的不足在于，要维持客户端和服务器之间的长连接，服务器所能支持的用户数量受限，一般达到300个用户连接［3］。由于目前主要是在专用内部网络中进行在轨航天器的实时监测，客户端用户的数量不会很多，因此，基于Pushlet架构的航天器在轨实时监测报警系统，具有一定的参考和应用价值。

（References）

［1］张维洲，蒋孟虎，杨平会，等．卫星遥测信息自动监视处理系统设计［J］．航天器工程，2008，17（5）：51-57

Zhang Weizhou，Jiang Menghu，Yang Pinghui，et al．System design for monitoring ＆disposalling the satellite telemetry automatically［J］．Spacecraft Engineering，2008，17（5）：51-57（in Chinese）

［2］文远保，刘峰．一种基于Ajax的Web车辆监控系统设计与实现［J］．华中科技大学学报（自然科学版），2007，35（8）：77-79

Wen Yuanbao，Liu Feng．Design and implementation of Ajax-based Web vehicle monitoring and control systems［J］．Journal of Huazhong University of Science and Technology（Nature Science），2007，35（8）：77-79（in Chinese）

［3］孙君曼，方华京，孙慧君，等．基于推技术的网络化监控报警系统［J］．计算机工程，2008，34（7）：269-271

Sun Junman，Fang Huajing，Sun Huijun，et al．Monitor and alarming system over Internet based on push technology［J］．Computer Engineering，2008，34（7）：269-271（in Chinese）

［4］金玉善，黄永平，付庆兴．Pushlet网络推技术研究及应用［J］．吉林大学学报（信息科学版），2009，27（3）：248-252

Jin Yushan，Huang Yongping，Fu Qingxing．Research and application of Pushlet network push technology［J］．Journal of Jilin University（Information Science Edition），2009，27（3）：248-252（in Chinese）

［5］孙清国，朱玮，刘华军，等．Web应用中的服务器推送技术研究综述［J］．计算机系统应用，2008，17（11）：116-120

Sun Qingguo，Zhu Wei，Liu Huajun，et al．Survey on server-push technology of Web applications［J］．Computer Systems ＆Applications，2008，17（11）：116-120（in Chinese）

［6］Just van den Broecke．Pushlet whitepaper［EB／OL］．［2011-09-07］．http：／／www．pushlets．com

［7］梁昌勇，张怡远，张俊岭．基于Pushlet的RFID 数据推送技术研究［J］．计算机技术与发展，2009，19（10）：85-88

Liang Changyong，Zhang Yiyuan，Zhang Junling．Research on RFID data push technology based on Pushlet［J］．Computer Technology and Development，2009，19（10）：85-88（in Chinese）

［8］尤淑辉，唐文彬，郭梅，等．基于Pushlet的网络性能实时监控系统［J］．计算机应用，2003，23（z2）：387-391

You Shuhui，Tang Wenbin，Guo Mei，et al．Network performance real-time monitoring system based on Pushlet［J］．Computer Applications，2003，23（z2）：387-391（in Chinese）