基于ZeroMQ的觀測控制系統(tǒng)底層通信架構(gòu)分析與測試*

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

(1. 昆明理工大學(xué)云南省計(jì)算機(jī)技術(shù)應(yīng)用重點(diǎn)實(shí)驗(yàn)室，云南 昆明 650500；2. 廣州大學(xué)天體物理中心/物理與電子工程學(xué)院，廣東 廣州 510006；3. 中國科學(xué)院云南天文臺(tái)，云南 昆明 650011)

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

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

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

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

1 ZeroMQ可用性分析

1.1 通信模式分析

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

1.1.1 請求應(yīng)答模式

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

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

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

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

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

1.2 可靠性分析

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

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

1.3 效率分析

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

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

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

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

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

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

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

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

2.2.1 環(huán) 境

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

2.2.2 時(shí)延測試

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

表1 實(shí)驗(yàn)環(huán)境Table 1 Experimental hardware environment

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

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

2.2.3 多點(diǎn)同步控制性能測試

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

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

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

2.2.4 多通道傳輸可用性測試

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

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

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

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

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

3 討論與結(jié)論

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

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