基于數(shù)據(jù)分發(fā)服務的航天器軟件通信框架設(shè)計

葉曉楓 楊志剛 楊培堯 張亞航 陳琦

(北京空間飛行器總體設(shè)計部，北京 100094)

當前航天器軟件的進程間通信過程主要依靠基于星內(nèi)路由的航天器軟件通信框架實現(xiàn)。該框架中最核心的部分是“路由進程”，該進程負責所有其他進程數(shù)據(jù)的轉(zhuǎn)發(fā)。該框架具體的通信方式是：發(fā)送進程將數(shù)據(jù)發(fā)送至路由進程，路由進程再將數(shù)據(jù)轉(zhuǎn)發(fā)至接收進程。路由進程接管了所有的底層網(wǎng)絡(luò)協(xié)議，因此解決了早期應用程序開發(fā)嚴重依賴底層協(xié)議的問題。例如，某衛(wèi)星平臺利用基于星內(nèi)路由的框架進行進程間通信，在星內(nèi)軟件建立了鏈路層和網(wǎng)絡(luò)層，通信過程通過點到點的“軟總線”方式(路由方式)完成，即所有的數(shù)據(jù)包匯聚至路由進程，路由進程根據(jù)數(shù)據(jù)包的應用過程標識(APID)查找路由表，將其轉(zhuǎn)發(fā)至相應的接收進程。該通信方式使得應用程序與底層協(xié)議隔離，簡化了軟件開發(fā)過程。

在這種基于星內(nèi)路由的星務軟件分層體系結(jié)構(gòu)中，遙測鏈路、遙控鏈路和1553B總線鏈路等鏈路層協(xié)議都由網(wǎng)絡(luò)層路由接管，并以軟件構(gòu)件的形式存在[1]。所有類型的數(shù)據(jù)包均需要先發(fā)送至路由進程，路由進程再根據(jù)數(shù)據(jù)包的類型選擇相應的鏈路層協(xié)議，將數(shù)據(jù)包轉(zhuǎn)發(fā)至相應的接收進程，形成一種“沙漏式”的通信架構(gòu)。這種通信方式的優(yōu)勢在于應用程序的開發(fā)者不需要關(guān)注與數(shù)據(jù)的接收方使用何種底層協(xié)議通信，只需調(diào)用一個統(tǒng)一的發(fā)送數(shù)據(jù)的函數(shù)即可實現(xiàn)數(shù)據(jù)的發(fā)送。該方式使軟件開發(fā)過程更簡單，并減小了不同模塊之間的耦合度，同時提高了代碼的質(zhì)量和復用性，但是這種通信方式依然存在一些不足之處。

(1)目前基于星內(nèi)路由的軟件通信框架使用靜態(tài)路由表確定每種數(shù)據(jù)包的目的地，路由表需要在編碼階段固定在代碼中，程序運行期間無法更改，并且每種數(shù)據(jù)的接收進程數(shù)量不能超過一個固定值，所以通信過程缺乏靈活性；此外，路由表龐大而復雜，需要手動配置，配置過程繁瑣且容易出錯，這直接影響了軟件的開發(fā)效率和質(zhì)量。

(2)基于星內(nèi)路由的軟件通信框架僅實現(xiàn)了簡單的數(shù)據(jù)轉(zhuǎn)發(fā)功能，無法對復雜的通信過程進行配置，難以滿足未來高質(zhì)量復雜通信的需要，例如無法實現(xiàn)感知通信節(jié)點是否在線的心跳機制，以及數(shù)據(jù)的可靠傳輸?shù)取?/p>

針對這些不足，本文以數(shù)據(jù)分發(fā)服務(Data Distribution Service, DDS[2])為基礎(chǔ)，提出了一種基于衛(wèi)星數(shù)據(jù)分發(fā)服務(Satellite-based DDS，S-DDS)的航天器軟件通信框架。S-DDS框架利用DDS強大的數(shù)據(jù)分發(fā)能力和服務質(zhì)量(Quality of Service, QoS)策略，在使航天器軟件的通信過程滿足了航天器軟件對高質(zhì)量復雜通信業(yè)務需求的同時，更為靈活便捷。同時，S-DDS引入了動態(tài)路由表，通過動態(tài)路由算法實現(xiàn)數(shù)據(jù)的分發(fā)，各個進程可以在運行過程中隨時修改路由表內(nèi)各項關(guān)鍵數(shù)據(jù)，這優(yōu)化了軟件開發(fā)方式，提高了軟件開發(fā)效率和軟件質(zhì)量。

1 DDS技術(shù)概述

DDS是對象管理組織(Object Management Group, OMG)的有關(guān)分布式實時系統(tǒng)中數(shù)據(jù)發(fā)布的一個規(guī)范，該規(guī)范標準化了分布式實時系統(tǒng)中數(shù)據(jù)發(fā)布、傳遞和接收的接口和行為，定義了以數(shù)據(jù)為中心的發(fā)布-訂閱機制，提供了一個與平臺無關(guān)的數(shù)據(jù)模型[3]。目前DDS已廣泛應用于國防、民航、工業(yè)控制等領(lǐng)域，成為分布式實時系統(tǒng)中數(shù)據(jù)發(fā)布-訂閱的標準解決方案[4]。

DDS包含兩層：底層的數(shù)據(jù)中心發(fā)布訂閱(Data-Centric Publish-Subscribe, DCPS)層和可選的高層數(shù)據(jù)本地重構(gòu)(Data Local Reconstruction Layer, DLRL)層。其中DCPS層負責高效地將數(shù)據(jù)發(fā)送到適當?shù)慕邮照?；DLRL層將收到的數(shù)據(jù)進行簡單整合，使應用程序能夠更容易地訪問數(shù)據(jù)[5]。DDS基于“全局數(shù)據(jù)空間(Global Data Space, GDS)”的概念，所有有關(guān)該空間中數(shù)據(jù)的應用程序都可以接入[6]，其通信模型如圖1所示[7]。

圖1 DDS通信模型Fig.1 Communications model of DDS

在DDS中，所有的數(shù)據(jù)都帶有一個主題(Topic)，主題用以區(qū)分各種不同類型的數(shù)據(jù)，是實現(xiàn)發(fā)布應用和訂閱應用之間數(shù)據(jù)傳輸?shù)幕緟?shù)[8]，這些數(shù)據(jù)也稱為消息(Message)，所有消息構(gòu)成了DDS的全局數(shù)據(jù)空間；所有的數(shù)據(jù)對象(消息)都存在于此空間中，分布式節(jié)點通過簡單的讀、寫操作便可以訪問這些數(shù)據(jù)對象[9]。全局數(shù)據(jù)空間是一個邏輯概念，并非存在于某個特定的中心節(jié)點中，實際上DDS常應用于分布式場景，全局數(shù)據(jù)空間往往分散于各個分布式節(jié)點中。在通信網(wǎng)絡(luò)中，每一個通信節(jié)點都是一個參與者(Participant)，其中發(fā)送數(shù)據(jù)的節(jié)點稱為發(fā)布者(Publisher)，接收數(shù)據(jù)的節(jié)點稱為訂閱者(Subscriber)，一個節(jié)點可以既是發(fā)布者又是訂閱者。發(fā)布者(訂閱者)發(fā)布(訂閱)的消息都帶有主題，一個發(fā)布者(訂閱者)可以同時發(fā)布(訂閱)一個或多個主題的消息，一個主題的消息也可以被一個或多個發(fā)布者(訂閱者)發(fā)布(訂閱)。主題、參與者、發(fā)布者、訂閱者統(tǒng)稱為實體(Entity)。此外，DDS規(guī)范還列舉并正式定義了一整套全面的QoS策略，利用QoS可以很好地配置和利用系統(tǒng)資源，支持復雜多變的數(shù)據(jù)流要求[10]。

2 S-DDS框架設(shè)計

DDS本身只是解決分布式系統(tǒng)中通信實時性問題的標準，它并沒有指明具體如何實現(xiàn)。實際上，實現(xiàn)DDS標準的各種DDS產(chǎn)品中，既有分布式結(jié)構(gòu)的產(chǎn)品，也有聯(lián)邦式和集中式結(jié)構(gòu)的產(chǎn)品[11]?？紤]到集中式結(jié)構(gòu)能夠方便地對通信過程進行管理控制，且可以保證數(shù)據(jù)分發(fā)的正確性，同時能夠兼容目前的航天器軟件架構(gòu)，本文將S-DDS設(shè)計為集中式結(jié)構(gòu)，包括服務端和客戶端兩部分。其中服務端為S-DDS服務器進程，它負責數(shù)據(jù)的分發(fā)，并對通信過程進行管控；各個參與通信的應用進程為客戶端，客戶端使用S-DDS中間件(以構(gòu)件形式存在)參與通信。

本文依據(jù)DDS標準設(shè)計的S-DDS架構(gòu)如圖2所示，整體架構(gòu)采用集中式的客戶-服務器模式設(shè)計。在S-DDS中，每個應用進程都是一個參加者，參與者可以創(chuàng)建發(fā)布者或訂閱者，用以發(fā)布或訂閱消息；每種類型的消息都使用APID作為其主題，消息經(jīng)發(fā)布者發(fā)布后先傳輸至服務端，服務端再根據(jù)消息的主題和相關(guān)的QoS策略分發(fā)至相應的訂閱者。

注：IO為輸入輸出。

在S-DDS框架中，S-DDS服務器取代了之前基于星內(nèi)路由架構(gòu)的路由進程，作為消息傳遞的中心節(jié)點，發(fā)布者發(fā)布的所有消息都需要先發(fā)送至S-DDS服務器，再由S-DDS服務器分發(fā)至相應的訂閱者。采用這種集中式結(jié)構(gòu)可以兼容當前航天器的星載軟件架構(gòu)，對數(shù)據(jù)進行方便地管理。在這種方式下，對于全局信息(例如參與者、主題等)由于只有一份拷貝，因此不存在數(shù)據(jù)一致性問題[12]。同時集中式結(jié)構(gòu)也便于維護通信網(wǎng)絡(luò)的拓撲結(jié)構(gòu)，因為在集中式結(jié)構(gòu)中，只有服務端需要維護一個表示通信網(wǎng)絡(luò)拓撲結(jié)構(gòu)的數(shù)據(jù)結(jié)構(gòu)(例如路由表)，而客戶端則無需關(guān)心和維護網(wǎng)絡(luò)的拓撲結(jié)構(gòu)，這大幅降低了開發(fā)難度。

此外，S-DDS各種實體的創(chuàng)建和刪除均由服務端負責，客戶端只需調(diào)用相關(guān)接口，向服務端發(fā)送創(chuàng)建或刪除實體的數(shù)據(jù)包，服務端便在遠端創(chuàng)建或刪除相應的實體，并向客戶端返回操作結(jié)果。這樣設(shè)計的目的是方便對通信網(wǎng)絡(luò)中所有的實體進行統(tǒng)一地管理，同時客戶端只需進行接口調(diào)用、無需在本地創(chuàng)建實體，所以S-DDS可以運行在性能極低的嵌入式設(shè)備上。

2.1 服務端設(shè)計

服務端是S-DDS通信的核心，所有消息均需經(jīng)服務端分發(fā)。服務端在收到不同的消息時，需要根據(jù)消息的類型采取不同的處理方式；在數(shù)據(jù)分發(fā)的過程中，服務端還需要保證數(shù)據(jù)分發(fā)的正確性和高效性，這是服務端設(shè)計的重點。

服務端采用動態(tài)路由的方式確定每種數(shù)據(jù)的目的地，其內(nèi)部維護了一張動態(tài)路由表，用以表示主題與訂閱者之間的邏輯關(guān)系。服務端在收到客戶端發(fā)送的消息之后，會根據(jù)消息的類型進行相應的處理，服務端處理一次消息的流程如圖3所示。服務端在接收到消息之后，先解析消息的主題和發(fā)布者，判斷消息的類型，根據(jù)不同的類型采取不同的操作。

(1)如果是創(chuàng)建實體類型的消息，則在服務端創(chuàng)建相應的實體(例如創(chuàng)建參與者)，如果創(chuàng)建成功則向發(fā)布者返回創(chuàng)建成功的信息，否則返回創(chuàng)建失敗的信息(例如參與者數(shù)量達到上限會導致創(chuàng)建失敗)。

(2)如果是刪除實體類型的消息，服務端則刪除相應的實體(例如刪除參與者)，如果刪除成功則向發(fā)布者返回刪除成功的信息，否則返回刪除失敗的信息(例如待刪除的實體未被創(chuàng)建則會導致刪除失敗)。

(3)如果是普通類型的消息，服務端先查找路由表，判斷主題是否在路由表中(即主題是否已經(jīng)注冊)，如果已經(jīng)注冊則根據(jù)路由表將消息分發(fā)至相應的訂閱者，否則向發(fā)布者返回主題未注冊的錯誤信息。

圖3 服務端處理消息的流程圖Fig.3 Flow chart of messages handling process of the server

在上述服務的處理消息流程中，最關(guān)鍵的是查找訂閱了某個主題的訂閱者的信息，如何根據(jù)消息主題快速查找相應的訂閱者是本文的研究重點之一。本文設(shè)計了一種動態(tài)路由算法，它能夠快速地確定每個數(shù)據(jù)包的目的地，適應嵌入式設(shè)備低性能的特點，該算法描述如下。

S-DDS服務器創(chuàng)建一個索引表IndexTable，其中的每一項對應一個主題(即消息的APID)，例如0x64的主題對應于IndexTable[100]；同時創(chuàng)建一個主題表TopicTable，用于存儲已發(fā)布的主題和訂閱了該主題的訂閱者的信息，如圖4所示。初始時將IndexTable和TopicTable的每一項均設(shè)置為默認值，表示無該主題的消息發(fā)布，也沒有相關(guān)的訂閱者。當創(chuàng)建某個主題時，先在TopicTable中添加該主題(即APID)至一個值為默認值的數(shù)組位置中，并在該位置創(chuàng)建一個空鏈表(鏈表用于存儲訂閱該主題的訂閱者的信息，包括服務類型、進程號、QoS策略等)，然后將IndexTable的對應項設(shè)置為TopicTable中存儲該主題的項的索引；例如當創(chuàng)建APID為0x64的主題時，假設(shè)此時已有10個主題發(fā)布，則將Router Table的第11項，即TopicTable[10]設(shè)置為0x64，并創(chuàng)建一個空鏈表，同時設(shè)置Index￣Table[100]為10。

圖4 動態(tài)路由表示意圖Fig.4 Diagram of dynamic routing table

當某一主題的消息到來時，該算法可以以O(shè)(1)的時間復雜度確定有哪些訂閱者訂閱了該主題的消息。例如，服務端在收到主題為0x12的消息時，先查找IndexTable[0x12]的值，發(fā)現(xiàn)其值為8，則直接查找TopicTable[8]即可獲取訂閱了0x12主題的消息的訂閱者，然后將消息分發(fā)至相應的訂閱者即可。此外，動態(tài)路由表可以在程序運行期間動態(tài)地進行修改，使得通信過程十分靈活；例如在程序運行期間，如果某個訂閱者訂閱了某一主題的消息，則只需在主題表中相應主題的訂閱者鏈表增加該訂閱者節(jié)點即可。與之前的靜態(tài)路由方式相比，動態(tài)路由方式無需在編碼階段對主題與其訂閱者進行硬編碼，可以很好地支持通信節(jié)點的增加和刪除，為各個應用程序提供了動態(tài)加入和退出通信網(wǎng)絡(luò)的能力。

2.2 客戶端設(shè)計

在S-DDS中，客戶端是實際參與通信的進程，客戶端使用S-DDS中間件進行通信，其中客戶端在調(diào)用創(chuàng)建實體的方法時，并不是在本地創(chuàng)建相應的實體，而是向服務端發(fā)送創(chuàng)建實體的請求，實體由服務端創(chuàng)建，服務端在創(chuàng)建完成后向客戶端發(fā)送創(chuàng)建是否成功的響應。這樣設(shè)計的目的是：①便于對通信過程進行管理；②減小客戶端的內(nèi)存開銷，可以兼容低性能的設(shè)備。

S-DDS中間件以構(gòu)件化的方式設(shè)計，即將S-DDS的各種實體封裝為各種“類”，并將各種“類”統(tǒng)一在一個頭文件中供外部使用。S-DDS涉及的實體有參與者、主題、發(fā)布者、訂閱者等，這些實體的屬性、方法以及它們之間的關(guān)系如圖5所示。

注：圖中的線段表示實體間的關(guān)系，箭頭表示組合關(guān)系，箭頭旁的數(shù)字表示數(shù)量，例如Participant和ParticipantType的箭頭表示一個參與者包含一個參與者類型，Participant和Publisher的箭頭表示一個參與者能夠創(chuàng)建多個發(fā)布者(*號表示多個)。

客戶端使用S-DDS中間件進行通信的步驟如下。

(1)創(chuàng)建參與者，并設(shè)置參與者的類型(ParticipantType)和QoS。

(2)參與者調(diào)用CreatePublisher()方法創(chuàng)建發(fā)布者，或調(diào)用CreateSubscriber()方法創(chuàng)建訂閱者，同時將發(fā)布者或訂閱者與主題綁定。

(3)發(fā)布者調(diào)用SendData()方法發(fā)送數(shù)據(jù)。

(4)訂閱者調(diào)用ListenOn()方法監(jiān)聽(接收)數(shù)據(jù)。

以上接口簡單易用，適合于航天器的軟件開發(fā)，并能滿足航天器軟件進程間通信的需要，方便應用程序開發(fā)者學習使用。

2.3 QoS設(shè)計

S-DDS依照DDS標準，設(shè)計了QoS策略，各個實體通過QoS策略的設(shè)置能夠滿足復雜的通信需要，從而解決當前進程間通信過程過于簡單的問題。QoS策略的設(shè)計并不是嚴格地從屬于服務端設(shè)計或客戶端設(shè)計，而是需要客戶端與服務端共同實現(xiàn)，以下是S-DDS提供的QoS策略。

(1)心跳機制。該QoS針對參與者，有兩種選擇，即使用心跳機制和不使用心跳機制。參與者如果選擇了使用心跳機制，則在實體被創(chuàng)建之后，便開始周期性地向服務端發(fā)送心跳數(shù)據(jù)包，服務端維護參與者的心跳計數(shù)，在收到心跳數(shù)據(jù)包后會根據(jù)其來源重置對應參與者的心跳計數(shù)。一旦心跳計數(shù)為零則認為該參與者已經(jīng)掉線，此時服務端會清空對應參與者的所有信息，客戶端必須重新連線并創(chuàng)建參與者等實體才能繼續(xù)通信。

(2)可靠傳輸。該QoS針對主題，有兩種選擇，即不可靠傳輸與可靠傳輸。如果某一主題選擇了不可靠傳輸方式，則該主題的訂閱者在收到消息后不發(fā)送確認數(shù)據(jù)包；而如果該主題選擇了可靠傳輸方式，則相應的訂閱者在收到消息后需要發(fā)送確認數(shù)據(jù)包；發(fā)布者如果在規(guī)定時間內(nèi)未收到確認數(shù)據(jù)包，則認為訂閱者未成功接收消息，需要重新發(fā)送消息。

3 S-DDS框架仿真與分析

本文對S-DDS框架進行了仿真，模擬實際星載軟件的進程間通信過程，結(jié)果表明：在S-DDS中應用程序僅需編寫少量的代碼就能實現(xiàn)進程間通信，大幅簡化了開發(fā)過程，同時通信過程由靜態(tài)方式變?yōu)閯討B(tài)方式，更加靈活便捷。此外，S-DDS提供的QoS策略能夠滿足復雜的通信需要，提升了進程間通信的可配置性。

3.1 動態(tài)路由

本文設(shè)計了兩個示例進程(參與者)進行通信，模擬實際的數(shù)據(jù)收發(fā)過程；其中進程1發(fā)送數(shù)據(jù)(發(fā)布者)，進程2接收數(shù)據(jù)(訂閱者)；通信過程產(chǎn)生的數(shù)據(jù)包以每個字節(jié)對應兩個十六進制字符的形式輸出至屏幕上，結(jié)果如圖6所示(圖6標明了部分具有重要含義的字節(jié))。仿真結(jié)果表明：各個數(shù)據(jù)包的出現(xiàn)順序與客戶端使用S-DDS中間件進行通信的步驟相同，并且各個數(shù)據(jù)包的格式正確，發(fā)布與訂閱的數(shù)據(jù)內(nèi)容(即“AA”)一致，由此驗證了S-DDS通信過程的正確性。

在目前基于星內(nèi)路由的航天器軟件通信框架中，通信過程需要在靜態(tài)路由表中配置，靜態(tài)路由表龐大復雜，配置繁瑣且易產(chǎn)生錯誤，同時數(shù)據(jù)接收方在編碼階段即固定，不可動態(tài)地更改，通信過程不靈活。而在S-DDS中應用程序完全不需要配置路由表，僅需編寫簡單、少量的代碼即可實現(xiàn)進程間通信的功能，且數(shù)據(jù)接收方(訂閱者)可以在運行期間動態(tài)變更。因此在S-DDS中，進程間通信過程更加靈活便捷，并且S-DDS避免了繁瑣的配置路由表的過程，降低了開發(fā)過程中產(chǎn)生錯誤的可能性，并使軟件開發(fā)過程更簡單高效。

圖6 S-DDS通信過程的數(shù)據(jù)包Fig.6 Data package of S-DDS communications process

3.2 心跳機制

針對心跳機制的驗證，本文設(shè)計了2個進程使用S-DDS通信，2個進程均將QoS策略設(shè)置為使用心跳機制，定時向S-DDS服務端發(fā)送心跳數(shù)據(jù)包，同時人為地使某個進程在通信過程中掉線，模擬實際通信過程中進程出現(xiàn)故障的情況；當服務端檢測到有進程掉線時，輸出進程掉線的信息。本文抓取了與心跳機制相關(guān)的數(shù)據(jù)包，將每個數(shù)據(jù)包以十六進制字符串的形式輸出至屏幕，數(shù)據(jù)包的每個字節(jié)的含義與3.1節(jié)相同，結(jié)果如圖7所示。仿真結(jié)果表明：當將參與者的QoS設(shè)置為使用心跳機制后，參與者會定期向S-DDS服務端發(fā)送心跳數(shù)據(jù)包，表明自己在線，如果服務端長時間未收到參與者的心跳數(shù)據(jù)包，則認為其掉線，這與方案設(shè)計相吻合。

目前基于星內(nèi)路由的航天器軟件框架并不提供心跳機制策略，路由進程無法對其他參與通信的進程進行監(jiān)聽，難以感知進程是否在線，而S-DDS提供了QoS策略支持心跳監(jiān)聽的機制，當需要對參與通信的進程進行監(jiān)聽時，客戶端只需調(diào)用S-DDS中間件即可實現(xiàn)心跳監(jiān)聽的功能,因此與基于星內(nèi)路由的航天器軟件框架相比，S-DDS能對復雜的進程間通信過程進行配置，滿足復雜的進程間通信需要。

圖7 S-DDS心跳數(shù)據(jù)包Fig.7 Heartbeat data package of S-DDS

3.3 可靠傳輸

針對可靠傳輸機制的驗證，本文設(shè)計了兩個進程使用S-DDS進行通信，其中進程1為發(fā)布者、進程2為訂閱者，發(fā)布者(訂閱者)發(fā)布(訂閱)的主題的QoS策略設(shè)置為使用可靠傳輸機制。與3.1節(jié)類似，本文以十六進制字符串的形式在屏幕上輸出每個數(shù)據(jù)包的各個字節(jié)，且各個字節(jié)的含義與3.1節(jié)相同，其結(jié)果如圖8所示；在通信過程中，人為地使某次消息在被收到后不回復應答，模擬實際通信過程中訂閱者未收到數(shù)據(jù)的情況。由圖8可以看出，當QoS策略設(shè)置為可靠通信后，訂閱者在收到數(shù)據(jù)時會回復確認，當訂閱者未收到數(shù)據(jù)時發(fā)布者會重發(fā)數(shù)據(jù)，與設(shè)計方案相符。

注：ack指確認。

在目前的基于星內(nèi)路由的軟件框架中，路由進程僅能實現(xiàn)簡單的數(shù)據(jù)包轉(zhuǎn)發(fā)功能，并不提供對可靠通信的支持，如果需要實現(xiàn)消息的可靠傳輸，則各個相關(guān)的應用程序均需實現(xiàn)可靠傳輸?shù)耐ㄐ胚壿嫞@造成了各個應用程序出現(xiàn)重復功能的代碼，且各段代碼質(zhì)量參差不齊，難以對軟件質(zhì)量進行統(tǒng)一把控。而S-DDS通過QoS策略為可靠通信提供支持，客戶端僅需調(diào)用S-DDS中間件，編寫少量代碼設(shè)置相關(guān)的QoS策略即可實現(xiàn)可靠通信的功能，這不僅能夠滿足復雜的通信需要，也降低了軟件開發(fā)的工作量，提高了代碼的可復用性，有利于提升代碼質(zhì)量、提高軟件可靠性。

4 結(jié)論

本文針對現(xiàn)有航天器星務軟件通信框架的不足之處，利用數(shù)據(jù)分發(fā)服務DDS，提出了一種基于數(shù)據(jù)分發(fā)服務的航天器軟件通信框架S-DDS；同時對S-DDS進行了仿真驗證，分析所得具體結(jié)論如下。

(1)S-DDS采用集中式的客戶-服務器模式實現(xiàn)，各應用程序是客戶端，S-DDS服務器是服務端，客戶端使用S-DDS中間件進行通信，采用集中式結(jié)構(gòu)可以兼容當前航天器軟件通信框架，便于管理通信過程，同時能夠降低開發(fā)難度。

(2)S-DDS實現(xiàn)了航天器軟件的進程間通信功能，各進程通過數(shù)據(jù)包交互，取代傳統(tǒng)的函數(shù)調(diào)用方式通信，這減小了模塊之間的耦合度，使代碼更易于更改、升級和維護，為未來戰(zhàn)場多變的衛(wèi)星應用場景，提供更加實時的應對手段。

(3)S-DDS采用動態(tài)路由方式分發(fā)數(shù)據(jù)，與目前的靜態(tài)路由方式相比，進程間通信的過程更加靈活便捷，并且無需對路由表進行繁瑣的手工配置，減少了軟件開發(fā)的工作量，同時減小了配置出錯的可能性，提高了軟件質(zhì)量。

(4)S-DDS提供心跳機制、可靠傳輸?shù)萉oS策略，實現(xiàn)了更加強大的通信功能，應用程序可以使用QoS對通信過程進行配置，從而滿足復雜的通信需要。