錢 進，鄧 輝,，梅 盈，石聰明，衛(wèi)守林，戴 偉,3，王 鋒,,3

(1. 昆明理工大學云南省計算機技術應用重點實驗室，云南 昆明 650500；2. 廣州大學天體物理中心/物理與電子工程學院，廣東 廣州 510006；3. 中國科學院云南天文臺，云南 昆明 650011)

隨著當前天文觀測技術的不斷提升，觀測設備功能的不斷增強，對控制要求越來越高，基于人工的觀測模式變得日益困難，對觀測控制系統(tǒng)(Observation Control System, OCS)[1]的需求日顯突出。參考國外先進望遠鏡自動化與智能化的建設經(jīng)驗，研究并實現(xiàn)一套高效、具有良好擴展性的觀測控制系統(tǒng)，無疑對下一代天文望遠鏡的研制具有十分重要的意義。

通常天文望遠鏡由多個系統(tǒng)構成，如圓頂、赤道儀(機架)、光譜儀和CCD終端等。觀測控制系統(tǒng)需要同時對多種類型的設備進行協(xié)同控制，各設備間彼此保持通信。在整個觀測過程中往往需要考慮時序控制、異常恢復等通信問題，良好的底層通信架構是整個望遠鏡控制系統(tǒng)設計的核心。

目前國內外的觀測控制系統(tǒng)，無論是經(jīng)典的ALMA控制系統(tǒng)(ALMA Control System, ACS)還是開源的遠程望遠鏡系統(tǒng)第二版(Remote Telescope System 2nd Version, RTS2)[2-3]都采用分布式的控制原理。特別是運用廣泛的RTS2，使用了原生套接字(Socket)[4]編程，每個客戶端同時與多個終端維持通信關系，底層通信結構呈復雜的網(wǎng)狀，不利于系統(tǒng)的開發(fā)和實現(xiàn)。此外，在觀測過程中觀測控制系統(tǒng)時常需要同步控制多種設備，比如，CCD的組合觀測和同步曝光等[5]。RTS2只能通過循環(huán)的方式，依次向多個設備發(fā)送命令，這會產(chǎn)生很大的通信延遲，且易出現(xiàn)消息丟失等情況。因此，基于裸套接技術開發(fā)觀測控制系統(tǒng)過于復雜，不利于系統(tǒng)的設計與維護。其它觀測控制系統(tǒng)采用HTTP，CORBA，DCOM等相關協(xié)議，這些協(xié)議和技術都體現(xiàn)出不同層面的局限性[6]，不能完全滿足望遠鏡控制系統(tǒng)底層通信中多種通信模型的需求。

近年來消息中間件技術不斷涌現(xiàn)，特別是以零消息隊列(Zero Message Queue, ZeroMQ)[7]為代表的消息中間件技術，能夠為分布式環(huán)境協(xié)同控制提供良好的技術支撐。更重要的是ZeroMQ支持多種通信模式，并可通過靈活組合使用基礎模式擴展應對不同的控制場景，實現(xiàn)單點對單點(1: 1)，單點對多點(1:N)的通信，滿足觀測控制系統(tǒng)中多種通信模型的需求。是否可以在天文觀測控制系統(tǒng)的設計與實現(xiàn)中采用ZeroMQ等新技術成為一個共同關注的問題。

1 ZeroMQ可用性分析

1.1 通信模式分析

ZeroMQ有兩種重要的通信模式，即請求應答模式與發(fā)布/訂閱模式[8]。結合天文觀測控制系統(tǒng)的需要，這兩種模式在實現(xiàn)底層通信模式中，可以靈活地使用來滿足天文設備的控制需求。

1.1.1 請求應答模式

點對點控制模式是一種基于鏈路連接的模式。單個消息發(fā)送方直接與單個接收方相連，采用一問一答的方式建立通信。點對點的控制模式在觀測中運用較廣，例如圓頂?shù)拈_關控制、赤道儀的移動操作等。

請求/應答是點對點直接通信的模式。消息發(fā)送方與接受方通過(REQ-REP)套接字對，采用一問一答的方式實現(xiàn)消息的收發(fā)。主要特點有：(1)面向連接的通信。發(fā)送方先要與接收方建立直接的通信，才能完成后續(xù)的消息傳輸。(2)發(fā)送方和接收方緊密耦合。雙方必須同時處于運行狀態(tài)才能傳遞消息，在時間上是緊耦合；雙方必須事先知道彼此的地址信息，在空間上是緊耦合。該模式的最大優(yōu)點是實現(xiàn)簡單且傳輸可靠，缺點是系統(tǒng)通信靈活性受到較大限制，每當接收方發(fā)生變化，發(fā)送方的應用程序都必須做出相應改變[9]。

1.1.2 發(fā)布/訂閱模式

單點對多點控制模式是一種廣播或多播的通信模式。消息發(fā)送方與多個接收方建立通訊，單個發(fā)送方可以同時控制多個接收方。ZeroMQ中的發(fā)布/訂閱是一對多的消息廣播模式，適合望遠鏡觀測中多臺CCD同時曝光或組合觀測的單點對多點的控制場合。

該模式采用(PUB-SUB)套接字對實現(xiàn)，發(fā)布方只需要將消息封裝到主題中發(fā)布，訂閱方根據(jù)預約主題獲取發(fā)布的內容。主要特點：(1)發(fā)布方和訂閱方通過共同主題進行通信，雙方不需要建立直接的鏈接通道。(2)發(fā)布方與訂閱方松耦合。雙方不需要知道彼此的地址，所以在空間上是獨立的；雙方不需要都處于運行狀態(tài)，因而在時間上是獨立的；消息產(chǎn)生與消耗不發(fā)生阻塞，因此在流程上也是獨立的。(3)能夠支持點對點、單點對多點和多點對多點的通信方式。該模式的主要優(yōu)點是實現(xiàn)了發(fā)布端和訂閱端之間的松耦合，致命的缺陷是發(fā)布端單向分發(fā)數(shù)據(jù)，且不關心是否把全部信息發(fā)送給訂閱端，消息容易丟失。

1.2 可靠性分析

在復雜多變的天文觀測控制環(huán)境中，發(fā)送方與接收方的狀態(tài)和行為是不可預測的。觀測控制系統(tǒng)在實際的運行過程中可能因網(wǎng)絡中斷或軟硬件故障等問題，導致消息丟失，直接影響天文觀測。為了進一步提高觀測控制系統(tǒng)消息傳輸?shù)目煽啃?，需要從消息的發(fā)送方和接收方兩方面共同保障程序發(fā)生故障后仍能順利運行。

針對可靠性問題進行了大量的實驗，ZeroMQ為避免消息端發(fā)生單點故障，套接字設計采用ZeroMQ雙子星模式[7]，任一時刻，某個節(jié)點充當主機，接收所有客戶端和設備端的連接請求，另一個節(jié)點則作為一種備用機存在。兩個節(jié)點互相維持心跳機制監(jiān)測彼此，主機通過PUB套接字定時將設備的連接信息發(fā)送到備用機，當主機從網(wǎng)絡中消失，備用機立刻頂替主機的位置。望遠鏡系統(tǒng)中設備終端是接收消息的核心部件，當設備出現(xiàn)通信異常中斷或通信延遲超過最大峰值時，設備端首先采用ZeroMQ超時重傳，逐條輪詢的方式再次判讀每個設備的在線情況。為了使消息不致丟失，設備端經(jīng)短暫恢復后實現(xiàn)斷點續(xù)傳功能[10]。斷點續(xù)傳是當設備在消息傳遞過程中出現(xiàn)中斷，待設備在短時間內恢復連接后能夠繼續(xù)完成傳輸任務，保障消息不丟失的模式[11]。該功能主要通過ZeroMQ克隆模式實現(xiàn)，使用PUB-SUB套接字作為核心消息模式。當系統(tǒng)收到設備反饋的連接異常狀態(tài)消息后，調用ZeroMQ多幀消息類，將消息前加上時間戳標記暫存，設備從故障中恢復通信并立刻通過REQ套接字獲取當前狀態(tài)，根據(jù)暫存消息時間戳與當前狀態(tài)比較，獲取狀態(tài)之前的所有消息，保障故障恢復后消息傳輸?shù)目煽啃浴?/p>

1.3 效率分析

在網(wǎng)絡通信時，帶寬資源是面臨的一個問題，在低帶寬情況下實現(xiàn)可靠通信是可能遇到的局面。在觀測控制系統(tǒng)設計中，消息傳輸?shù)拈_銷與延遲將直接影響系統(tǒng)的整體性能，而消息的長度又是影響通信效率的一個重要因素，特別是觀測產(chǎn)生的圖像數(shù)據(jù)，往往具有實時性強、數(shù)據(jù)量大的特點。從這方面看，ZeroMQ支持實時的數(shù)據(jù)壓縮技術，采用LZ4無損壓縮算法，發(fā)送前對數(shù)據(jù)進行高速壓縮，在接收端進行高速解壓，最大程度無損失地使傳輸?shù)南⒏虞p量化，減少帶寬需求，這對天文觀測是非常有益的。

同時，具有一個高效的消息通信模式也是提高傳輸效率的重要保障，圖像數(shù)據(jù)經(jīng)ZeroMQ請求應答套接字實現(xiàn)單點高效的傳輸，控制指令可采用單獨端口的廣播套接字實現(xiàn)對多個設備的有效控制，節(jié)點上可采用多線程技術，提高了消息傳輸與處理的并發(fā)度，降低了因點對點依次向不同設備轉發(fā)控制命令產(chǎn)生的傳輸延遲，基于以上方法能夠有效保障觀測控制系統(tǒng)底層通信消息傳輸?shù)母咝浴?/p>

2 觀測控制系統(tǒng)的控制模式與實測

2.1 觀測控制系統(tǒng)的基本架構

圖1是開發(fā)新一代觀測控制系統(tǒng)時采用的體系架構，觀測控制系統(tǒng)處于控制的最頂層，由調度子系統(tǒng)、管理子系統(tǒng)、用戶交互子系統(tǒng)以及狀態(tài)記錄系統(tǒng)4部分組成。觀測控制系統(tǒng)與其他所有系統(tǒng)都采用接口調用的方式進行交互，通過指揮望遠鏡控制系統(tǒng)、設備控制系統(tǒng)和實時數(shù)據(jù)處理系統(tǒng)對下一級各終端設備進行控制。顯然，要實現(xiàn)一套可靠的觀測控制系統(tǒng)，底層通信的可用性以及可靠性是成功的關鍵。

圖1 觀測控制系統(tǒng)體系架構圖
Fig.1 The architecture diagram of observation control system

從底層通信模式看，點對點和單點對多點的模式已經(jīng)可以滿足觀測控制系統(tǒng)的設計要求。關鍵的問題是，這兩種模式在通信過程中的可靠性、傳輸時延、多任務傳輸性能否適用實際通信的要求。

2.2 ZeroMQ在控制中的可用性測試

2.2.1 環(huán) 境

實驗環(huán)境使用5臺服務器，每臺服務器的配置相同，都配置了千兆網(wǎng)卡，其中一臺服務器作為發(fā)送端，其他服務器作為接收端，服務器主要配置如表1，以下測試實驗均在該環(huán)境下進行。

2.2.2 時延測試

各設備接收命令的通信時延是衡量系統(tǒng)通信性能的重要指標。因此，對ZeroMQ在相同環(huán)境下傳輸不同長度消息的通信時延進行了對比測試。測試一：模擬觀測控制系統(tǒng)實現(xiàn)點對點的控制場景，發(fā)送方運行于一臺服務器，接收方運行于另一臺服務器。測試方法是使用REQ-REP套接字，發(fā)送一個特定大小的消息從一臺服務器到另一臺服務器。分別測試了一萬條大小分別為256 B與1 024 B的控制消息，比較了每一條消息發(fā)送與接收的時間差，測試結果如圖2。由測試結果可見，連接初期傳輸延遲較高，而后趨于穩(wěn)

表1 實驗環(huán)境Table 1 Experimental hardware environment

定，偶爾出現(xiàn)峰值的情況，且均在合理范圍內。當數(shù)據(jù)大小由256 B增加到1 024 B時，延遲也相應增加，但通信延遲總體表現(xiàn)較小，能夠適用于觀測控制系統(tǒng)控制圓頂或望遠鏡等設備點對點的控制環(huán)境。

圖2 REQ-REP模式消息傳輸延遲對比圖
Fig.2 Request-Reply mode message transmission delay comparison chart

2.2.3 多點同步控制性能測試

模擬觀測控制系統(tǒng)實現(xiàn)單點對多點的控制場景，發(fā)送方運行于一臺服務器，接收方運行于另外5臺服務器。測試方法是發(fā)布端使用PUB-SUB套接字發(fā)送一萬條特定大小為256 B的控制消息，5個接收端根據(jù)主題訂閱接收消息。分別測試了5個訂閱端接收消息的延遲情況，測試產(chǎn)生最底層的通信時延結果如圖3。因每條消息的通信延遲為離散數(shù)據(jù)，為了更好地掌握各設備的接收性能，分別從數(shù)據(jù)的集中趨勢和離散程度兩方面分析各設備接收消息的同步性，表2中Sub1-Sub5分別表示5個設備端，對比分析各組數(shù)據(jù)，可以得出各設備接收消息平均延遲在10 μs以下，延遲波動程度相當，平均延遲遠小于標準差。實驗結果表明，做觀測控制系統(tǒng)高層開發(fā)與設計時，參考最底層的通信時延數(shù)據(jù)，需要考慮限制控制指令發(fā)送頻率，進一步提高控制同步精度。在實際控制中，只要在平均延遲加3倍標準差的時間范圍內考慮控制設計，時延水平符合控制精度要求，就會滿足觀測控制系統(tǒng)對多臺CCD等設備實現(xiàn)單點對多點的控制場景。

圖3 PUB-SUB模式消息傳輸延遲對比圖
Fig.3 Publish-Subscribe mode message transmission delay comparison chart

表2 實驗數(shù)據(jù)分析Table 2 Experimental data analysis

2.2.4 多通道傳輸可用性測試

在天文觀測中觀測控制系統(tǒng)經(jīng)常出現(xiàn)與實時數(shù)據(jù)處理系統(tǒng)之間的交互，數(shù)據(jù)處理系統(tǒng)會將觀測數(shù)據(jù)實時處理結果反饋給觀測控制系統(tǒng)做觀測調度決策，觀測控制系統(tǒng)將控制命令高速傳遞給數(shù)據(jù)處理系統(tǒng)或其他子系統(tǒng)。

設計一個實驗進一步探究觀測控制系統(tǒng)在密集數(shù)據(jù)通信環(huán)境下，實現(xiàn)點對點和單點對多點控制的可用性。發(fā)送方將生成的單個圖像大小為4 MB的數(shù)據(jù)，先轉換為二進制的數(shù)據(jù)流，再以消息的形式封裝，通過請求應答模式傳遞400 MB大小的數(shù)據(jù)到接收端服務器，模擬觀測控制系統(tǒng)與數(shù)據(jù)處理系統(tǒng)之間傳輸大量圖像數(shù)據(jù)的密集通信環(huán)境。

測試方法如下：(1)與傳輸圖像程序同時運行，新建通信端口分別采用REQ-REP和PUB-SUB套接字對將生成的單個控制消息大小為256 B的數(shù)據(jù)包持續(xù)不斷地從一臺服務器向其他服務器發(fā)送消息。(2)當400 M圖像數(shù)據(jù)傳輸完成時，記錄圖像傳輸所需時間，并將傳輸控制消息的程序立即停止。(3)記錄在圖像傳輸時間內兩種不同模式下，控制消息的通信時延、發(fā)送消息數(shù)與接收消息數(shù)。測試結果如表3。

表3 多通道傳輸測試數(shù)據(jù)Table 3 Multi-channel transmission test data

由表3可知，400 MB大小的圖像數(shù)據(jù)可以在7.3 s完成傳輸任務，55 MB/s的傳輸速率也滿足大量圖像數(shù)據(jù)的高速傳輸。同時，分別采用ZeroMQ中REQ-REP和PUB-SUB套接字對實現(xiàn)控制命令實時同傳。結果表明，采用以上兩種模式均能實現(xiàn)消息發(fā)送與接收的不丟包，能夠保證控制命令傳輸?shù)目煽啃?。對比單獨發(fā)送傳輸控制命令的場景，兩種模式雖受密集數(shù)據(jù)通信下網(wǎng)絡帶寬與通信延遲等影響，總體傳輸速率有所降低，但傳輸性能較采用傳統(tǒng)套接字(Socket)通信更高效穩(wěn)定，能夠滿足控制命令實時穩(wěn)定地傳輸。通過多次反復的測試，結果表明，采用ZeroMQ實現(xiàn)多任務、多通道傳輸是可行的，其數(shù)據(jù)傳輸方式、傳輸速率、傳輸穩(wěn)定性等都能滿足觀測控制系統(tǒng)底層通信相關指標要求。不僅能夠實現(xiàn)數(shù)據(jù)在觀測控制系統(tǒng)與數(shù)據(jù)處理系統(tǒng)之間的傳輸，還能夠實現(xiàn)各終端之間信息交互和各子系統(tǒng)之間的互聯(lián)互控，解決當前天文望遠鏡各終端與各子系統(tǒng)彼此獨立、無法協(xié)調工作的關鍵問題。

3 討論與結論

本文討論了ZeroMQ現(xiàn)有通信模式的優(yōu)缺點，分析了觀測控制系統(tǒng)主要天文控制模式，提出了基于ZeroMQ的不同通信控制架構，為解決通信延遲、異?；謴偷韧ㄐ艈栴}提供了相關參考方法。經(jīng)測試結果分析，使用ZeroMQ技術構建觀測控制系統(tǒng)底層通信架構是可行的，能夠滿足點對點、單點對多點通信控制的需求，解決底層通信中普遍存在的開銷大、延遲高等問題，非常適合天文望遠鏡觀測控制這種分布式、低延遲要求的場合。在后續(xù)工作中將以設計一套基于混合通信模式的觀測控制系統(tǒng)為目標，進一步實現(xiàn)對望遠鏡終端設備的通信與分布控制。

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