張亞航 楊培堯 楊志剛

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

美軍標(biāo)MIL-STD-1553B(以下簡(jiǎn)稱(chēng)1553B)是一種數(shù)字式時(shí)分制指令/響應(yīng)型多路傳輸數(shù)據(jù)總線(xiàn)，由于它具有雙向輸出特性、實(shí)時(shí)性和可靠性高，廣泛應(yīng)用在當(dāng)代的運(yùn)輸機(jī)和相當(dāng)數(shù)量的民航客機(jī)以及軍用飛機(jī)上，航天系統(tǒng)也有廣泛的應(yīng)用[1-3]。MIL-STD-1553B總線(xiàn)標(biāo)準(zhǔn)規(guī)定的物理層和鏈路層協(xié)議能夠滿(mǎn)足構(gòu)造最大64 Byte的消息交互能力的星載數(shù)據(jù)總線(xiàn)系統(tǒng)。但是，現(xiàn)有MIL-STD-1553B標(biāo)準(zhǔn)[4-5]沒(méi)有規(guī)定更大數(shù)據(jù)結(jié)構(gòu)的處理方法和復(fù)雜數(shù)據(jù)流控制方法來(lái)支持更高層的通信和同步服務(wù)。一般衛(wèi)星的1553B總線(xiàn)系統(tǒng)[6-8]，星載軟件應(yīng)用程序一般直接操作總線(xiàn)控制芯片61580，每次通信發(fā)起后，處理器都需等待，直到本次總線(xiàn)通信結(jié)束[9-10]。這種方式雖然解決了總線(xiàn)同時(shí)訪(fǎng)問(wèn)沖突問(wèn)題，但是嚴(yán)重制約了對(duì)1553B總線(xiàn)的帶寬利用；另一方面由于不同衛(wèi)星不同長(zhǎng)度的數(shù)據(jù)通信時(shí)間差異大，難以提供高可靠的時(shí)間服務(wù)，難以同時(shí)滿(mǎn)足高性能和高可靠性要求[11]，無(wú)法滿(mǎn)足新一代衛(wèi)星對(duì)總線(xiàn)帶寬的需求。

本文在對(duì)傳統(tǒng)遙感星載數(shù)據(jù)總線(xiàn)系統(tǒng)和星上通信設(shè)備的分析基礎(chǔ)上，開(kāi)發(fā)了一種基于時(shí)間同步的1553B總線(xiàn)通信協(xié)議。在這種基于通信幀時(shí)間同步的總線(xiàn)通信框架中，將一個(gè)時(shí)間同步周期劃分成多個(gè)通信幀，每個(gè)通信幀占用固定時(shí)隙/帶寬。在這個(gè)基礎(chǔ)上，通過(guò)對(duì)通信幀時(shí)隙多種利用，設(shè)計(jì)了固定幀時(shí)隙、固定數(shù)據(jù)傳輸路徑(總線(xiàn)控制端BC到遠(yuǎn)置終端RT或RT到BC)的無(wú)連接靜態(tài)通信服務(wù)；以及基于通信雙方握手，面向連接的動(dòng)態(tài)通信服務(wù)。以滿(mǎn)足1553B總線(xiàn)鏈路上層多種通信需求。在這種通信協(xié)議設(shè)計(jì)方法中，BC端軟件根據(jù)時(shí)間同步信號(hào)統(tǒng)一根據(jù)上層應(yīng)用對(duì)總線(xiàn)通信的需求組織1553B總線(xiàn)消息，并操作61580控制芯片啟動(dòng)總線(xiàn)發(fā)送，隨后本進(jìn)程掛起，CPU可以執(zhí)行其他進(jìn)程任務(wù)。當(dāng)通信結(jié)束時(shí)，獲得總線(xiàn)芯片幀結(jié)束中斷信號(hào)，再啟動(dòng)程序完成總線(xiàn)芯片數(shù)據(jù)拷貝、校對(duì)處理和分發(fā)。這種協(xié)議設(shè)計(jì)，解決了多用戶(hù)通信沖突問(wèn)題，大幅度提高總線(xiàn)帶寬利用率；采用時(shí)間同步的方式標(biāo)準(zhǔn)化了各種服務(wù)通信，從而能夠?qū)崿F(xiàn)0.1 ms精度的時(shí)間同步服務(wù)；使得總線(xiàn)通信與具體的通信數(shù)據(jù)內(nèi)容無(wú)關(guān)，便于實(shí)現(xiàn)軟件的構(gòu)件化和通用化[4]。

1 時(shí)間同步總線(xiàn)通信協(xié)議設(shè)計(jì)

1.1 通信幀總體方案設(shè)計(jì)

通信同步服務(wù)支持總線(xiàn)消息時(shí)間同步以及消息序列的確定性，使得消息在總線(xiàn)上傳送之前確定。數(shù)據(jù)總線(xiàn)通信發(fā)生的時(shí)間段稱(chēng)之為通信幀。數(shù)據(jù)總線(xiàn)上的每個(gè)通信幀以同步消息開(kāi)始，該同步消息采用帶數(shù)據(jù)字的方式命令進(jìn)行同步，數(shù)據(jù)字表示傳輸幀序號(hào)。

BC端的宿主計(jì)算機(jī)負(fù)責(zé)準(zhǔn)備需要傳輸?shù)臄?shù)據(jù)、觸發(fā)序列的開(kāi)始及在序列末尾(通常以中斷的方式通知序列末尾)獲取返回的數(shù)據(jù)或處理錯(cuò)誤信息。BC設(shè)備根據(jù)預(yù)先編排的序列(見(jiàn)圖1)自動(dòng)執(zhí)行底層的1553B總線(xiàn)基本消息的發(fā)送或接收操作。按照這種方式，通過(guò)在初始化時(shí)對(duì)BC端消息序列編程從而有效實(shí)現(xiàn)總線(xiàn)規(guī)劃；在運(yùn)行時(shí)設(shè)置并接收傳輸?shù)臄?shù)據(jù)從而有效管理總線(xiàn)規(guī)劃。如此一來(lái)，每一位掛接在總線(xiàn)上的用戶(hù)的數(shù)據(jù)吞吐量和最壞延遲都能夠得到保證——而無(wú)需擔(dān)心其他遠(yuǎn)程終端的正?；蚍钦Ｐ袨?。

圖1 時(shí)間同步協(xié)議分層結(jié)構(gòu)示例Fig.1 Muti-layer Struct of Time Synchronize Communication Protocol

1.2 無(wú)連接的數(shù)據(jù)傳輸設(shè)計(jì)

多路數(shù)據(jù)在單條數(shù)據(jù)總線(xiàn)上傳輸，必然導(dǎo)致每次數(shù)據(jù)傳輸都有一定的延時(shí)。根據(jù)不同的時(shí)間延遲及頻率等要求，對(duì)于無(wú)連接的數(shù)據(jù)傳輸來(lái)說(shuō)，分為預(yù)定義內(nèi)容的帶寬分配傳輸和未定義內(nèi)容的帶寬分配傳輸。本次設(shè)計(jì)中，未定義內(nèi)容的帶寬分配方案，主要用于協(xié)議內(nèi)部的管理，不對(duì)應(yīng)用程序開(kāi)發(fā)。

而預(yù)定于內(nèi)容的帶寬分配傳輸方案，用于低延遲或高頻率的數(shù)據(jù)傳輸需求，(例如關(guān)鍵指令分發(fā)，周期性?xún)?nèi)務(wù)數(shù)據(jù)采集)：通信幀時(shí)間軸上的每個(gè)1553消息總是保留給具備給定屬性(如，RT地址、最大數(shù)據(jù)長(zhǎng)度)的既定服務(wù)。在這種方式下延遲時(shí)間是由調(diào)度策略本身決定的(見(jiàn)圖2的例子)。

圖2 同步訪(fǎng)問(wèn)示例(預(yù)分配，已占用)Fig.2 Example of synchronous bus access (pre-allocated, populated)

1.3 面向連接的握手傳輸設(shè)計(jì)

面向連接的數(shù)據(jù)傳輸，稱(chēng)為數(shù)據(jù)塊傳輸服務(wù)。該服務(wù)在發(fā)送者的請(qǐng)求下提供傳輸數(shù)據(jù)塊的能力，并在傳輸完畢后提供確認(rèn)。該傳輸方案提供限定長(zhǎng)度數(shù)據(jù)的同步傳輸，限定的長(zhǎng)度在1 Byte到1024 Byte。在發(fā)送端數(shù)據(jù)塊的長(zhǎng)度按照1553消息的需求切成數(shù)據(jù)段，在接收端又被拼接起來(lái)。數(shù)據(jù)塊傳輸服務(wù)不對(duì)數(shù)據(jù)結(jié)構(gòu)長(zhǎng)度超出最大數(shù)據(jù)塊長(zhǎng)度的用戶(hù)數(shù)據(jù)提供封裝和解封轉(zhuǎn)服務(wù)。如果要處理更大的數(shù)據(jù)塊，相關(guān)的服務(wù)特性將由更高層的協(xié)議層，例如包應(yīng)用標(biāo)準(zhǔn)(PUS)[4]保證，利用這些高層服務(wù)的控制結(jié)構(gòu)。BC根據(jù)地址進(jìn)行區(qū)分，以對(duì)31個(gè)RT的數(shù)據(jù)塊傳輸多路復(fù)用或解多路復(fù)用。

數(shù)據(jù)塊傳輸服務(wù)在數(shù)據(jù)發(fā)送端和接收端通信鏈路間使用握手來(lái)進(jìn)行流量控制、接收端的接收確認(rèn)及防止重復(fù)傳輸。協(xié)議層面無(wú)流量控制，傳輸數(shù)據(jù)塊控制域所攜帶的信息能夠用于上層用戶(hù)的流量控制機(jī)制。本服務(wù)支持以下兩層服務(wù)質(zhì)量：①最大效率模式，此方式傳輸數(shù)據(jù)，對(duì)數(shù)據(jù)不進(jìn)行任何正確性檢查；②長(zhǎng)度確認(rèn)模式，此方式下傳輸數(shù)據(jù)，接收端檢查正確接收到的數(shù)據(jù)的長(zhǎng)度。

雖然面向連接的數(shù)據(jù)塊傳輸服務(wù)能夠提供BC和RT兩端的邏輯對(duì)等通信，即任意一方都可以作為通信的發(fā)起方。但是，由于1553B總線(xiàn)的主從結(jié)構(gòu)，總線(xiàn)控制權(quán)在BC端。因此，在這種服務(wù)中，BC到RT方向握手連接和RT到BC方向握手連接在本協(xié)議層的處理流程是不同的，需要分開(kāi)設(shè)計(jì)。

1.3.1 BC到RT方向握手連接設(shè)計(jì)

BC到RT的傳輸稱(chēng)為數(shù)據(jù)分發(fā)傳輸，當(dāng)有BC到RT的數(shù)據(jù)傳輸需求時(shí)，協(xié)議要求BC端向RT端發(fā)送分發(fā)傳輸描述請(qǐng)求(Distribute Transfer Description，DTD)，該請(qǐng)求應(yīng)包含終端地址、用戶(hù)數(shù)據(jù)、用戶(hù)數(shù)據(jù)長(zhǎng)度以及請(qǐng)求的服務(wù)質(zhì)量(QoS)，該請(qǐng)求導(dǎo)致BC服務(wù)提供者將數(shù)據(jù)塊及分發(fā)傳輸描述符發(fā)送至被請(qǐng)求RT，發(fā)送通過(guò)將分發(fā)數(shù)據(jù)塊和分發(fā)傳輸描述符寫(xiě)入子地址緩沖區(qū)實(shí)現(xiàn)，這些信息對(duì)于數(shù)據(jù)是可預(yù)見(jiàn)的。

對(duì)于RT而言，任何時(shí)刻都有可能收到新的分發(fā)數(shù)據(jù)塊，RT應(yīng)該在收到新的DTD(表明有新數(shù)據(jù)到來(lái))時(shí)持續(xù)檢查數(shù)據(jù)塊到來(lái)。RT應(yīng)在分發(fā)傳輸描述符所在通信幀之后的通信幀結(jié)束前處理新的命令數(shù)據(jù)塊，這樣的話(huà)，用于分發(fā)數(shù)據(jù)塊的緩沖區(qū)可被釋放用于存儲(chǔ)下一幀中的下一個(gè)數(shù)據(jù)塊。若DTD中要求的Qos為1，則還應(yīng)對(duì)接收到的數(shù)據(jù)進(jìn)行長(zhǎng)度和正確性確認(rèn)，并將結(jié)果通過(guò)數(shù)據(jù)分發(fā)傳輸確認(rèn)(Distribute Transfer Conform，DTC)返回。

為了能夠維護(hù)BC到各RT的數(shù)據(jù)分發(fā)信道，針對(duì)每個(gè)RT，BC端各維護(hù)一個(gè)數(shù)據(jù)分發(fā)會(huì)話(huà)(Session)，并采用控制程序依據(jù)會(huì)話(huà)進(jìn)行操作。為了能夠有序管理數(shù)據(jù)分發(fā)信道，本文將Session分為3類(lèi)狀態(tài)。

(1)初始化態(tài)：系統(tǒng)啟動(dòng)，或接收到上層用戶(hù)發(fā)過(guò)來(lái)的本Session會(huì)話(huà)重置指令，一律進(jìn)入初始化態(tài)，根據(jù)圖3描述的時(shí)序(圖3中上方表示BC端程序的行為，中間表示總線(xiàn)實(shí)際傳輸行為，下方表示RT端應(yīng)用程序行為，每個(gè)時(shí)刻代表一個(gè)幀同步周期，后續(xù)時(shí)序圖類(lèi)同，不再詳細(xì)說(shuō)明)，BC和RT一起握手完成信道初始化，為此，將初始化態(tài)分為未初始化，初始化1、初始化2，初始化3和初始化4等子狀態(tài)。

圖3 BC端BC到RT方向握手協(xié)議初始化時(shí)序圖Fig.3 Init sequence diagram of BC to RT hand-shake protocol on BC

(2)空閑態(tài)(Free)：僅當(dāng)本信道Session處于空閑態(tài)時(shí)，上層數(shù)據(jù)可以使用該信道發(fā)送數(shù)據(jù)。

(3)發(fā)送態(tài)(Sending)：表示當(dāng)前信道忙碌，正處于跟RT端數(shù)據(jù)發(fā)送狀態(tài)。本文對(duì)BC到RT發(fā)送傳輸提供兩種Qos服務(wù)質(zhì)量，高效傳輸模式和可靠傳輸模式。前者接收端(RT)無(wú)需對(duì)接收的數(shù)據(jù)進(jìn)行確認(rèn)，從而能夠減少握手次數(shù)提高傳輸效率。后者接收端(RT)需向發(fā)送端(BC)返回接收的數(shù)據(jù)確認(rèn)，握手次數(shù)增加但傳輸可靠性高。本文對(duì)兩種服務(wù)質(zhì)量設(shè)計(jì)了高效傳輸模式(圖4)或可靠傳輸模式(圖5)兩種時(shí)序，為此，將發(fā)送態(tài)再細(xì)分為發(fā)送態(tài)1、發(fā)送態(tài)2，發(fā)送態(tài)3，發(fā)送態(tài)4和發(fā)送態(tài)5等子狀態(tài)。

圖4 連續(xù)兩次BC端BC到RT方向握手協(xié)議高效模式發(fā)送序圖Fig.4 Double efficient mode sending data sequence diagram of BC to RT hand-shake protocol on BC

圖5 BC端BC到RT方向握手協(xié)議可靠模式發(fā)送序圖Fig.5 Reliable mode sending data sequence diagram of BC to RT hand-shake protocol on BC

由于1553B總線(xiàn)的主從式方式，協(xié)議握手過(guò)程由BC端應(yīng)用程序控制。對(duì)于BC端RT到BC端握手協(xié)議有限狀態(tài)機(jī)轉(zhuǎn)換圖如圖6所示。

圖6 BC端BC到RT方向握手協(xié)議有限狀態(tài)機(jī)轉(zhuǎn)換圖Fig.6 FSM of BC to RT hand-shake protocol on BC

1.3.2 RT到BC方向握手連接設(shè)計(jì)

RT到BC稱(chēng)之為數(shù)據(jù)獲取傳輸(Acquire Transfer)，RT端的服務(wù)用戶(hù)表明新數(shù)據(jù)已準(zhǔn)備好以及開(kāi)始向BC傳輸數(shù)據(jù)。BC端的服務(wù)用戶(hù)讀取該新數(shù)據(jù)到來(lái)的標(biāo)識(shí)并在下一個(gè)通信幀開(kāi)始從RT發(fā)送子地址緩沖區(qū)傳送數(shù)據(jù)。該服務(wù)在給定時(shí)間從每個(gè)RT僅支持一次獲取傳輸，若有多次獲取傳輸數(shù)據(jù)需要發(fā)送，則RT應(yīng)用程序應(yīng)對(duì)在其內(nèi)部緩沖區(qū)的獲取數(shù)據(jù)塊進(jìn)行排序。

RT端的發(fā)送者提出獲取服務(wù)請(qǐng)求(Acquire Transfer Requires，ATR)，協(xié)議要求1553B總線(xiàn)控制器BC端定期(一般是1～2個(gè)協(xié)議要求的通信幀周期內(nèi))輪詢(xún)所有RT的ATR。依照RT端請(qǐng)求的服務(wù)質(zhì)量(Qos)，BC端服務(wù)提供者應(yīng)檢查數(shù)據(jù)是否完整及正確，BC端服務(wù)提供者向RT發(fā)送者返回一個(gè)獲取傳輸確認(rèn)字(Acquire Transfer Confirm，ATC)表明數(shù)據(jù)已經(jīng)傳輸。如果RT端的服務(wù)用戶(hù)請(qǐng)求一個(gè)傳輸檢查，那么該獲取傳輸確認(rèn)應(yīng)表明傳輸是否成功，RT服務(wù)用戶(hù)應(yīng)用程序根據(jù)應(yīng)用規(guī)范的需求決定傳輸一個(gè)新的數(shù)據(jù)還是重傳數(shù)據(jù)。

與本文1.3.1節(jié)類(lèi)似，為了能夠維護(hù)各RT到BC的數(shù)據(jù)獲取信道，針對(duì)每個(gè)RT，BC端各維護(hù)一個(gè)數(shù)據(jù)獲取會(huì)話(huà)Session，并采用控制程序依據(jù)會(huì)話(huà)進(jìn)行操作。為了能夠有序管理數(shù)據(jù)獲取信道，本文將數(shù)據(jù)獲取Session分為3類(lèi)狀態(tài)。

(1)初始化態(tài)：系統(tǒng)啟動(dòng)，或接收到上層用戶(hù)發(fā)過(guò)來(lái)的本Session會(huì)話(huà)重置指令，進(jìn)入初始化態(tài)，BC和RT一起握手完成信道初始化，為此，將初始化態(tài)分為未初始化，初始化1、初始化2，初始化3和初始化4等子狀態(tài)。

(2)空閑態(tài)：僅當(dāng)本信道Session處于空閑態(tài)時(shí)，上層數(shù)據(jù)可以使用該信道發(fā)送數(shù)據(jù)。

(3)接收態(tài)：表示當(dāng)前信道忙碌，正處于跟RT端數(shù)據(jù)發(fā)送狀態(tài)，同樣的，本文對(duì)RT到BC接收傳輸提供兩種Qos服務(wù)質(zhì)量，即高效模式和可靠模式。前者接收端(BC)無(wú)需對(duì)接收的數(shù)據(jù)進(jìn)行確認(rèn)，從而能夠減少握手次數(shù)提高傳輸效率。后者接收端(BC)需向發(fā)送端(RT)返回接收的數(shù)據(jù)確認(rèn)，握手次數(shù)增加但傳輸可靠性高。進(jìn)一步的，本文對(duì)兩種服務(wù)質(zhì)量設(shè)計(jì)了高效傳輸模式和可靠傳輸模式兩種時(shí)序，由于篇幅限制，本節(jié)不再描述數(shù)據(jù)獲取初始化時(shí)序、高效模式數(shù)據(jù)獲取時(shí)序和可靠模式數(shù)據(jù)獲取時(shí)序，感興趣的讀者，可以根據(jù)本文的描述和圖6推導(dǎo)出以上3種時(shí)序。為此，將接收態(tài)再細(xì)分為接收態(tài)1、接收態(tài)2，接收態(tài)3，接收態(tài)4，接收態(tài)5，接收態(tài)6，接收態(tài)7等子狀態(tài)。

本文的時(shí)序設(shè)計(jì)方法，可以在維持信道通信效率的同時(shí)，減少對(duì)中斷信號(hào)的使用，簡(jiǎn)化程序設(shè)計(jì)：BC端程序僅需監(jiān)聽(tīng)?zhēng)叫盘?hào)中斷和幀結(jié)束中斷信號(hào)；RT端程序僅需監(jiān)聽(tīng)?zhēng)街袛嘈盘?hào)。

由于1553B總線(xiàn)的主從式方式，協(xié)議握手過(guò)程由BC端應(yīng)用程序控制。對(duì)于BC端RT到BC端握手協(xié)議有限狀態(tài)機(jī)轉(zhuǎn)換圖如圖7所示。

圖7 BC端RT到BC方向握手協(xié)議有限狀態(tài)機(jī)轉(zhuǎn)換圖Fig.7 FSM of RT to BC hand-shake protocol on BC

2 試驗(yàn)結(jié)果及分析

對(duì)基于時(shí)間同步的1553B總線(xiàn)通信協(xié)議的應(yīng)用情況進(jìn)行試驗(yàn)，并對(duì)比傳統(tǒng)衛(wèi)星總線(xiàn)通信的CPU占用率。選取主流航天器星載信息系統(tǒng)硬件運(yùn)行環(huán)境，采用中央處理單元主頻為10 MHz，1 Mbit帶寬的MIL-STD-1553B總線(xiàn)，61580控制芯片。試驗(yàn)數(shù)據(jù)如表1所示，其對(duì)比如圖8所示。。

表1 總線(xiàn)通信量與CPU占用率數(shù)據(jù)表Table 1 CPUconsume table of different bus traffic

圖8 1553B傳統(tǒng)總線(xiàn)協(xié)議和時(shí)間同步通信協(xié)議下的CPU占用率對(duì)比Fig.8 Compare of CPU consume between traditional protocol and time syn protocol

在這個(gè)硬件環(huán)境下，由圖8可以看出相對(duì)傳統(tǒng)遙感衛(wèi)星總線(xiàn)通信協(xié)議，基于時(shí)間同步總線(xiàn)通信協(xié)議的總線(xiàn)傳輸對(duì)處理器機(jī)時(shí)的占用率降低了五倍左右。

事實(shí)上，基于時(shí)間同步總線(xiàn)通信協(xié)議，其CPU占用率主要取決于處理器對(duì)總線(xiàn)控制器RAM的讀寫(xiě)速度。當(dāng)處理器對(duì)總線(xiàn)控制器RAM的讀寫(xiě)速度進(jìn)一步提高的情況下，有效總線(xiàn)帶寬可以不斷接近理論值819.2 Kbit/s(1553B總線(xiàn)帶寬為1 Mbit/s，但每16 bit有4 bit校驗(yàn))。

3 結(jié)論與后續(xù)工作

基于時(shí)間同步的1553B總線(xiàn)通信協(xié)議設(shè)計(jì)，其通信量和通信方式等需求根據(jù)具體衛(wèi)星任務(wù)預(yù)先規(guī)劃。根據(jù)試驗(yàn)分析認(rèn)為，相對(duì)傳統(tǒng)衛(wèi)星的1553B通信協(xié)議，主要帶來(lái)以下好處。

(1)大幅度提高帶寬利用率：經(jīng)過(guò)測(cè)試，大約能到600 Kbit/s，相對(duì)一般衛(wèi)星的150～200 Kbit/s，提高了2到3倍。

(2)多種標(biāo)準(zhǔn)化通信服務(wù)：總線(xiàn)通信方式和使用與具體的通信數(shù)據(jù)內(nèi)容無(wú)關(guān)，通過(guò)軟件的構(gòu)件化設(shè)計(jì)之后，提高多個(gè)衛(wèi)星任務(wù)間，總線(xiàn)處理代碼復(fù)用程度。

(3)提高數(shù)據(jù)傳輸確定性：通過(guò)時(shí)間同步和總線(xiàn)帶寬預(yù)分配的方式，讓數(shù)據(jù)傳輸頻率提高到20 Hz(相對(duì)傳統(tǒng)衛(wèi)星的最高8～10 Hz)，而數(shù)據(jù)傳輸時(shí)間確定性到達(dá)毫秒級(jí)，(相對(duì)傳統(tǒng)衛(wèi)星精度為±20 ms級(jí))。

目前該協(xié)議已經(jīng)完成星載系統(tǒng)開(kāi)發(fā)和測(cè)試，在高分辨率多模式成像衛(wèi)星等多顆衛(wèi)星中完成在軌驗(yàn)證，取得了良好的應(yīng)用效果。后續(xù)工作建議重點(diǎn)關(guān)注兩方面：一是該協(xié)議已經(jīng)完成在軌驗(yàn)證，且同時(shí)在十余個(gè)航天器中開(kāi)始應(yīng)用，但主要集中在遙感和返回領(lǐng)域，將考慮推廣至深空探測(cè)和載人航天領(lǐng)域；另一方面是由于該協(xié)議采用時(shí)間同步，劃分出預(yù)分配的帶寬，在此基礎(chǔ)上，可以進(jìn)一步研究整星數(shù)據(jù)流時(shí)隙分配方法，以降低整星數(shù)據(jù)傳輸時(shí)延，提升數(shù)據(jù)傳輸均勻度。