基于ZeroMQ的观测控制系统底层通信架构分析与测试*

钱 进，邓 辉,，梅 盈，石聪明，卫守林，戴 伟,3，王 锋,,3

(1. 昆明理工大学云南省计算机技术应用重点实验室，云南 昆明 650500；2. 广州大学天体物理中心/物理与电子工程学院，广东 广州 510006；3. 中国科学院云南天文台，云南 昆明 650011)

随着当前天文观测技术的不断提升，观测设备功能的不断增强，对控制要求越来越高，基于人工的观测模式变得日益困难，对观测控制系统(Observation Control System, OCS)[1]的需求日显突出。参考国外先进望远镜自动化与智能化的建设经验，研究并实现一套高效、具有良好扩展性的观测控制系统，无疑对下一代天文望远镜的研制具有十分重要的意义。

通常天文望远镜由多个系统构成，如圆顶、赤道仪(机架)、光谱仪和CCD终端等。观测控制系统需要同时对多种类型的设备进行协同控制，各设备间彼此保持通信。在整个观测过程中往往需要考虑时序控制、异常恢复等通信问题，良好的底层通信架构是整个望远镜控制系统设计的核心。

目前国内外的观测控制系统，无论是经典的ALMA控制系统(ALMA Control System, ACS)还是开源的远程望远镜系统第二版(Remote Telescope System 2nd Version, RTS2)[2-3]都采用分布式的控制原理。特别是运用广泛的RTS2，使用了原生套接字(Socket)[4]编程，每个客户端同时与多个终端维持通信关系，底层通信结构呈复杂的网状，不利于系统的开发和实现。此外，在观测过程中观测控制系统时常需要同步控制多种设备，比如，CCD的组合观测和同步曝光等[5]。RTS2只能通过循环的方式，依次向多个设备发送命令，这会产生很大的通信延迟，且易出现消息丢失等情况。因此，基于裸套接技术开发观测控制系统过于复杂，不利于系统的设计与维护。其它观测控制系统采用HTTP，CORBA，DCOM等相关协议，这些协议和技术都体现出不同层面的局限性[6]，不能完全满足望远镜控制系统底层通信中多种通信模型的需求。

近年来消息中间件技术不断涌现，特别是以零消息队列(Zero Message Queue, ZeroMQ)[7]为代表的消息中间件技术，能够为分布式环境协同控制提供良好的技术支撑。更重要的是ZeroMQ支持多种通信模式，并可通过灵活组合使用基础模式扩展应对不同的控制场景，实现单点对单点(1: 1)，单点对多点(1:N)的通信，满足观测控制系统中多种通信模型的需求。是否可以在天文观测控制系统的设计与实现中采用ZeroMQ等新技术成为一个共同关注的问题。

1 ZeroMQ可用性分析

1.1 通信模式分析

ZeroMQ有两种重要的通信模式，即请求应答模式与发布/订阅模式[8]。结合天文观测控制系统的需要，这两种模式在实现底层通信模式中，可以灵活地使用来满足天文设备的控制需求。

1.1.1 请求应答模式

点对点控制模式是一种基于链路连接的模式。单个消息发送方直接与单个接收方相连，采用一问一答的方式建立通信。点对点的控制模式在观测中运用较广，例如圆顶的开关控制、赤道仪的移动操作等。

请求/应答是点对点直接通信的模式。消息发送方与接受方通过(REQ-REP)套接字对，采用一问一答的方式实现消息的收发。主要特点有：(1)面向连接的通信。发送方先要与接收方建立直接的通信，才能完成后续的消息传输。(2)发送方和接收方紧密耦合。双方必须同时处于运行状态才能传递消息，在时间上是紧耦合；双方必须事先知道彼此的地址信息，在空间上是紧耦合。该模式的最大优点是实现简单且传输可靠，缺点是系统通信灵活性受到较大限制，每当接收方发生变化，发送方的应用程序都必须做出相应改变[9]。

1.1.2 发布/订阅模式

单点对多点控制模式是一种广播或多播的通信模式。消息发送方与多个接收方建立通讯，单个发送方可以同时控制多个接收方。ZeroMQ中的发布/订阅是一对多的消息广播模式，适合望远镜观测中多台CCD同时曝光或组合观测的单点对多点的控制场合。

该模式采用(PUB-SUB)套接字对实现，发布方只需要将消息封装到主题中发布，订阅方根据预约主题获取发布的内容。主要特点：(1)发布方和订阅方通过共同主题进行通信，双方不需要建立直接的链接通道。(2)发布方与订阅方松耦合。双方不需要知道彼此的地址，所以在空间上是独立的；双方不需要都处于运行状态，因而在时间上是独立的；消息产生与消耗不发生阻塞，因此在流程上也是独立的。(3)能够支持点对点、单点对多点和多点对多点的通信方式。该模式的主要优点是实现了发布端和订阅端之间的松耦合，致命的缺陷是发布端单向分发数据，且不关心是否把全部信息发送给订阅端，消息容易丢失。

1.2 可靠性分析

在复杂多变的天文观测控制环境中，发送方与接收方的状态和行为是不可预测的。观测控制系统在实际的运行过程中可能因网络中断或软硬件故障等问题，导致消息丢失，直接影响天文观测。为了进一步提高观测控制系统消息传输的可靠性，需要从消息的发送方和接收方两方面共同保障程序发生故障后仍能顺利运行。

针对可靠性问题进行了大量的实验，ZeroMQ为避免消息端发生单点故障，套接字设计采用ZeroMQ双子星模式[7]，任一时刻，某个节点充当主机，接收所有客户端和设备端的连接请求，另一个节点则作为一种备用机存在。两个节点互相维持心跳机制监测彼此，主机通过PUB套接字定时将设备的连接信息发送到备用机，当主机从网络中消失，备用机立刻顶替主机的位置。望远镜系统中设备终端是接收消息的核心部件，当设备出现通信异常中断或通信延迟超过最大峰值时，设备端首先采用ZeroMQ超时重传，逐条轮询的方式再次判读每个设备的在线情况。为了使消息不致丢失，设备端经短暂恢复后实现断点续传功能[10]。断点续传是当设备在消息传递过程中出现中断，待设备在短时间内恢复连接后能够继续完成传输任务，保障消息不丢失的模式[11]。该功能主要通过ZeroMQ克隆模式实现，使用PUB-SUB套接字作为核心消息模式。当系统收到设备反馈的连接异常状态消息后，调用ZeroMQ多帧消息类，将消息前加上时间戳标记暂存，设备从故障中恢复通信并立刻通过REQ套接字获取当前状态，根据暂存消息时间戳与当前状态比较，获取状态之前的所有消息，保障故障恢复后消息传输的可靠性。

1.3 效率分析

在网络通信时，带宽资源是面临的一个问题，在低带宽情况下实现可靠通信是可能遇到的局面。在观测控制系统设计中，消息传输的开销与延迟将直接影响系统的整体性能，而消息的长度又是影响通信效率的一个重要因素，特别是观测产生的图像数据，往往具有实时性强、数据量大的特点。从这方面看，ZeroMQ支持实时的数据压缩技术，采用LZ4无损压缩算法，发送前对数据进行高速压缩，在接收端进行高速解压，最大程度无损失地使传输的消息更加轻量化，减少带宽需求，这对天文观测是非常有益的。

同时，具有一个高效的消息通信模式也是提高传输效率的重要保障，图像数据经ZeroMQ请求应答套接字实现单点高效的传输，控制指令可采用单独端口的广播套接字实现对多个设备的有效控制，节点上可采用多线程技术，提高了消息传输与处理的并发度，降低了因点对点依次向不同设备转发控制命令产生的传输延迟，基于以上方法能够有效保障观测控制系统底层通信消息传输的高效性。

2 观测控制系统的控制模式与实测

2.1 观测控制系统的基本架构

图1是开发新一代观测控制系统时采用的体系架构，观测控制系统处于控制的最顶层，由调度子系统、管理子系统、用户交互子系统以及状态记录系统4部分组成。观测控制系统与其他所有系统都采用接口调用的方式进行交互，通过指挥望远镜控制系统、设备控制系统和实时数据处理系统对下一级各终端设备进行控制。显然，要实现一套可靠的观测控制系统，底层通信的可用性以及可靠性是成功的关键。

图1 观测控制系统体系架构图
Fig.1 The architecture diagram of observation control system

从底层通信模式看，点对点和单点对多点的模式已经可以满足观测控制系统的设计要求。关键的问题是，这两种模式在通信过程中的可靠性、传输时延、多任务传输性能否适用实际通信的要求。

2.2 ZeroMQ在控制中的可用性测试

2.2.1 环 境

实验环境使用5台服务器，每台服务器的配置相同，都配置了千兆网卡，其中一台服务器作为发送端，其他服务器作为接收端，服务器主要配置如表1，以下测试实验均在该环境下进行。

2.2.2 时延测试

各设备接收命令的通信时延是衡量系统通信性能的重要指标。因此，对ZeroMQ在相同环境下传输不同长度消息的通信时延进行了对比测试。测试一：模拟观测控制系统实现点对点的控制场景，发送方运行于一台服务器，接收方运行于另一台服务器。测试方法是使用REQ-REP套接字，发送一个特定大小的消息从一台服务器到另一台服务器。分别测试了一万条大小分别为256 B与1 024 B的控制消息，比较了每一条消息发送与接收的时间差，测试结果如图2。由测试结果可见，连接初期传输延迟较高，而后趋于稳

表1 实验环境Table 1 Experimental hardware environment

定，偶尔出现峰值的情况，且均在合理范围内。当数据大小由256 B增加到1 024 B时，延迟也相应增加，但通信延迟总体表现较小，能够适用于观测控制系统控制圆顶或望远镜等设备点对点的控制环境。

图2 REQ-REP模式消息传输延迟对比图
Fig.2 Request-Reply mode message transmission delay comparison chart

2.2.3 多点同步控制性能测试

模拟观测控制系统实现单点对多点的控制场景，发送方运行于一台服务器，接收方运行于另外5台服务器。测试方法是发布端使用PUB-SUB套接字发送一万条特定大小为256 B的控制消息，5个接收端根据主题订阅接收消息。分别测试了5个订阅端接收消息的延迟情况，测试产生最底层的通信时延结果如图3。因每条消息的通信延迟为离散数据，为了更好地掌握各设备的接收性能，分别从数据的集中趋势和离散程度两方面分析各设备接收消息的同步性，表2中Sub1-Sub5分别表示5个设备端，对比分析各组数据，可以得出各设备接收消息平均延迟在10 μs以下，延迟波动程度相当，平均延迟远小于标准差。实验结果表明，做观测控制系统高层开发与设计时，参考最底层的通信时延数据，需要考虑限制控制指令发送频率，进一步提高控制同步精度。在实际控制中，只要在平均延迟加3倍标准差的时间范围内考虑控制设计，时延水平符合控制精度要求，就会满足观测控制系统对多台CCD等设备实现单点对多点的控制场景。

图3 PUB-SUB模式消息传输延迟对比图
Fig.3 Publish-Subscribe mode message transmission delay comparison chart

表2 实验数据分析Table 2 Experimental data analysis

2.2.4 多通道传输可用性测试

在天文观测中观测控制系统经常出现与实时数据处理系统之间的交互，数据处理系统会将观测数据实时处理结果反馈给观测控制系统做观测调度决策，观测控制系统将控制命令高速传递给数据处理系统或其他子系统。

设计一个实验进一步探究观测控制系统在密集数据通信环境下，实现点对点和单点对多点控制的可用性。发送方将生成的单个图像大小为4 MB的数据，先转换为二进制的数据流，再以消息的形式封装，通过请求应答模式传递400 MB大小的数据到接收端服务器，模拟观测控制系统与数据处理系统之间传输大量图像数据的密集通信环境。

测试方法如下：(1)与传输图像程序同时运行，新建通信端口分别采用REQ-REP和PUB-SUB套接字对将生成的单个控制消息大小为256 B的数据包持续不断地从一台服务器向其他服务器发送消息。(2)当400 M图像数据传输完成时，记录图像传输所需时间，并将传输控制消息的程序立即停止。(3)记录在图像传输时间内两种不同模式下，控制消息的通信时延、发送消息数与接收消息数。测试结果如表3。

表3 多通道传输测试数据Table 3 Multi-channel transmission test data

由表3可知，400 MB大小的图像数据可以在7.3 s完成传输任务，55 MB/s的传输速率也满足大量图像数据的高速传输。同时，分别采用ZeroMQ中REQ-REP和PUB-SUB套接字对实现控制命令实时同传。结果表明，采用以上两种模式均能实现消息发送与接收的不丢包，能够保证控制命令传输的可靠性。对比单独发送传输控制命令的场景，两种模式虽受密集数据通信下网络带宽与通信延迟等影响，总体传输速率有所降低，但传输性能较采用传统套接字(Socket)通信更高效稳定，能够满足控制命令实时稳定地传输。通过多次反复的测试，结果表明，采用ZeroMQ实现多任务、多通道传输是可行的，其数据传输方式、传输速率、传输稳定性等都能满足观测控制系统底层通信相关指标要求。不仅能够实现数据在观测控制系统与数据处理系统之间的传输，还能够实现各终端之间信息交互和各子系统之间的互联互控，解决当前天文望远镜各终端与各子系统彼此独立、无法协调工作的关键问题。

3 讨论与结论

本文讨论了ZeroMQ现有通信模式的优缺点，分析了观测控制系统主要天文控制模式，提出了基于ZeroMQ的不同通信控制架构，为解决通信延迟、异常恢复等通信问题提供了相关参考方法。经测试结果分析，使用ZeroMQ技术构建观测控制系统底层通信架构是可行的，能够满足点对点、单点对多点通信控制的需求，解决底层通信中普遍存在的开销大、延迟高等问题，非常适合天文望远镜观测控制这种分布式、低延迟要求的场合。在后续工作中将以设计一套基于混合通信模式的观测控制系统为目标，进一步实现对望远镜终端设备的通信与分布控制。

致谢：衷心感谢中国科学院国家天文台-阿里云天文大数据联合研究中心对本文工作的支持。