基于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技術構建觀測控制系統底層通信架構是可行的，能夠滿足點對點、單點對多點通信控制的需求，解決底層通信中普遍存在的開銷大、延遲高等問題，非常適合天文望遠鏡觀測控制這種分布式、低延遲要求的場合。在后續工作中將以設計一套基于混合通信模式的觀測控制系統為目標，進一步實現對望遠鏡終端設備的通信與分布控制。

致謝：衷心感謝中國科學院國家天文臺-阿里云天文大數據聯合研究中心對本文工作的支持。