蘭 天，周凡卉，楊培堯，張紅軍，余 晟

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

0 引言

1553B總線網(wǎng)絡由1個總線控制器(BC)與若干個RT共同構成，網(wǎng)絡中的所有通信均由BC發(fā)起[1]。自20世紀70年代末以來，由于其高可靠性，1553B總線已在航空、航天等多個領域得到了廣泛的應用。但在美軍標中只規(guī)定了1553B總線數(shù)據(jù)鏈路層接口協(xié)議，沒有對更高層通信做出規(guī)定。傳統(tǒng)航天器需針對BC與RT間的消息傳輸方式、內(nèi)容進行個性化設計，雖能滿足不同飛行任務的需求，但在協(xié)議協(xié)調(diào)、軟件設計、測試驗證上需花費大量的精力，且不利于通用化發(fā)展。

隨著航天器任務日益復雜，這種個性化設計方式花費的代價對研制流程造成的影響越來越大。為解決這一問題，歐洲空間標準化組織發(fā)展出一種時間同步1553B總線通信協(xié)議[2]，該協(xié)議在應用層與數(shù)據(jù)鏈路層之間建立了通用化的通信、同步接口，能夠有效統(tǒng)一、簡化總線接口配置。該協(xié)議將BC、RT間的數(shù)據(jù)通信抽象提煉成5種服務，并用原語方式說明了信息交換格式與時序安排，給出了RT子地址分配、使用的建議。該協(xié)議實現(xiàn)了BC、RT總線接口的通用化，通過時間同步簡化了BC、RT間握手方式，為總線上各用戶數(shù)據(jù)吞吐量和最壞服務延遲提供了有效保證，已在我國多顆智能遙感衛(wèi)星綜合電子系統(tǒng)中得到了應用[3-7]。

在時間同步1553B協(xié)議應用過程中，也遇到了一些新問題，RT并發(fā)數(shù)據(jù)傳輸控制就是其中之一。在傳統(tǒng)總線通信協(xié)議中，通常為不同數(shù)據(jù)項開辟多個子地址，按照數(shù)據(jù)項產(chǎn)生順序提服務請求，發(fā)出數(shù)據(jù)傳輸申請。而在時間同步1553B總線通信協(xié)議中，突發(fā)性數(shù)據(jù)和長周期數(shù)據(jù)需復用數(shù)據(jù)塊傳輸服務，共享同一發(fā)送通道。隨著航天器智能化水平的提升，RT產(chǎn)生的數(shù)據(jù)量大幅攀升，存在短期并發(fā)大量數(shù)據(jù)、需多次數(shù)據(jù)塊傳輸發(fā)出的場景。若按傳統(tǒng)方式進行傳輸，大數(shù)據(jù)量的遙測數(shù)據(jù)可能堵塞與程控相關的緊急消息，影響航天器程控動作實時性。因此如何合理調(diào)度RT并發(fā)數(shù)據(jù)，確保緊急消息的發(fā)送時延可控，是航天器軟件設計的重要課題。

當前國內(nèi)外針對1553B總線資源調(diào)度的研究多圍繞BC展開，少有涉及RT[8-13]。而僅靠BC的資源調(diào)度，不能完全解決RT的并發(fā)數(shù)據(jù)發(fā)送問題。因此，本文提出了一種時間同步1553B總線通信協(xié)議的RT突發(fā)數(shù)據(jù)發(fā)送控制方法。首先按照RT并發(fā)數(shù)據(jù)的時間敏感性進行優(yōu)先級劃分，然后采用兩級“生產(chǎn)者-消費者”模型[14-17]，在并發(fā)數(shù)據(jù)源與總線通道之間引入總線組幀緩存區(qū)?？偩€組幀緩沖區(qū)“消費”并發(fā)數(shù)據(jù)，“生產(chǎn)”出按優(yōu)先級組織的總線傳輸幀。本文設計的RT突發(fā)數(shù)據(jù)控制方法，能夠大幅提升單次數(shù)據(jù)塊傳輸?shù)膸捓寐剩榫o急消息的實時傳輸提供保障。

1 時間同步1553B總線協(xié)議下的RT數(shù)據(jù)發(fā)送

時間同步1553B總線通信協(xié)議在總線通信中的作用方式如圖1所示。從圖1中可見，協(xié)議將應用層與數(shù)據(jù)鏈路層間的接口抽象為5種服務，分別為：時間同步、通信同步、置數(shù)/取數(shù)、數(shù)據(jù)塊傳輸、終端管理等。這些服務可滿足航天器使用的所有情況，如單消息傳輸、循環(huán)緩存?zhèn)鬏敗⒎照埱?、廣播等。5種服務間存在依存關系，通信同步服務是整個時間同步1553B總線通信協(xié)議的基礎。

圖1 時間同步1553B總線通信協(xié)議中各服務的位置和服務間關系示意

時間同步協(xié)議以時間同步周期為單位對總線帶寬進行量化，并以通信幀為單位對每個時間同步周期內(nèi)的帶寬資源進一步細分，如圖2所示。通信幀是一段時間內(nèi)總線上允許傳輸?shù)南⒓?，一個時間同步周期內(nèi)含有多個規(guī)劃內(nèi)容不同的通信幀，通信幀與星上時間、BC軟件周期同步。在每個通信幀開始，BC首先通過總線以廣播方式向各RT終端發(fā)送幀同步。幀同步后的帶寬資源分為預分配帶寬和自由帶寬，預分配帶寬排在幀同步之后，自由帶寬排在預分配帶寬之后。預分配帶寬內(nèi)的總線通信必然發(fā)生，自由帶寬內(nèi)的總線通信可能發(fā)生。

圖2 時間同步1553B總線通信協(xié)議中典型通信幀分解示意

時間同步1553B協(xié)議提供的5種服務中，通信同步、時間同步、置數(shù)/取數(shù)、終端管理等4種服務在預分配帶寬內(nèi)傳輸；數(shù)據(jù)塊傳輸服務在自由帶寬內(nèi)傳輸。對預分配帶寬內(nèi)的數(shù)據(jù)傳輸，可通過基于通信同步服務的錯幀操作避免BC、RT間的讀寫沖突，不需要傳統(tǒng)總線協(xié)議中的握手消息和相應的中斷觸發(fā)配置；對自由帶寬內(nèi)的數(shù)據(jù)傳輸，需要額外的握手消息。

RT通過數(shù)據(jù)塊傳輸服務向外發(fā)送數(shù)據(jù)塊的過程為：

1)RT檢測確認發(fā)送通道為“空閑”狀態(tài)時，將待發(fā)數(shù)據(jù)塊寫入數(shù)據(jù)塊發(fā)送子地址；

2)RT向數(shù)據(jù)塊獲取服務握手發(fā)送子地址(SA 28T)寫入獲取傳輸申請(ATR)。同時，RT將發(fā)送通道狀態(tài)設為“占用”，并啟動數(shù)據(jù)塊獲取超時檢測；

3)BC通過查詢方式查得ATR，在自由帶寬內(nèi)完成獲取數(shù)據(jù)塊動作。完成數(shù)據(jù)塊獲取后，BC根據(jù)獲取結果向RT的數(shù)據(jù)塊獲取服務握手接收子地址(SA 28R)中寫入獲取傳輸確認(ATC)；

4)RT接收到ATC或等待超時后，清除ATR，并將發(fā)送通道標識設為“空閑”。

從上述數(shù)據(jù)發(fā)送過程可見，在發(fā)起一次數(shù)據(jù)傳輸后，為避免讀寫沖突導致的通信失敗，RT在傳輸過程中無法追加數(shù)據(jù)。在RT軟件出現(xiàn)突發(fā)性數(shù)據(jù)、長周期數(shù)據(jù)的并發(fā)工況時，數(shù)據(jù)項之間存在對數(shù)據(jù)發(fā)送通道的競爭。

傳統(tǒng)1553B協(xié)議的處理方法是為不同的數(shù)據(jù)項設計不同的發(fā)送子地址，通過提服務請求的順序控制數(shù)據(jù)項發(fā)送順序。雖能保證突發(fā)數(shù)據(jù)的傳輸實時性，但所花費的軟件代價更大、總線帶寬利用率也較低。且當待發(fā)數(shù)據(jù)項種類增長到一定水平時，受限于總線芯片發(fā)送子地址數(shù)量約束，該方法會出現(xiàn)功能瓶頸。

在時間同步1553B總線通信協(xié)議中，RT外發(fā)數(shù)據(jù)有兩種方式：取數(shù)服務和數(shù)據(jù)塊傳輸服務。取數(shù)服務使用預分配帶寬，擁有可預期的最大傳輸時延；數(shù)據(jù)塊服務使用自由帶寬，傳輸時延不確定，但可通過系統(tǒng)級總線規(guī)劃在一個時間同步周期內(nèi)為某RT分配確定的數(shù)據(jù)塊傳輸機會。數(shù)據(jù)塊傳輸服務對發(fā)送子地址進行了通用化設計，不再將子地址跟特定數(shù)據(jù)項綁定在一起。在總線芯片中，通過為數(shù)據(jù)塊獲取服務分配多個平鋪的發(fā)送子地址或為單個發(fā)送子地址開辟大循環(huán)緩存的方式，能夠獲得比傳統(tǒng)1553B總線通信協(xié)議更大的單次數(shù)據(jù)傳輸能力。在每次發(fā)送總線消息前，向發(fā)送緩存中依次填入多個數(shù)據(jù)項，并通過ATR對這些數(shù)據(jù)項的總長度進行描述。這種處理方法提升了單次數(shù)據(jù)的傳輸效率，但沒有給出確保需多次數(shù)據(jù)塊傳輸?shù)牟l(fā)數(shù)據(jù)中緊急消息發(fā)送時延的方法。

隨著衛(wèi)星綜合電子系統(tǒng)智能化水平的提升，RT設備更強的計算能力使其承擔了更多的功能，造成RT需外發(fā)的數(shù)據(jù)量大幅上升。RT方發(fā)出的數(shù)據(jù)項可分為周期與突發(fā)兩類，突發(fā)數(shù)據(jù)項采用數(shù)據(jù)塊傳輸服務，周期數(shù)據(jù)項需進一步考慮周期長短。數(shù)據(jù)項周期若小于或略大于時間同步周期，應在預分配帶寬內(nèi)以取數(shù)服務進行傳輸；若遠大于時間同步周期，應在自由帶寬內(nèi)以數(shù)據(jù)塊傳輸服務傳輸。按照數(shù)據(jù)特點，可將采用數(shù)據(jù)塊傳輸服務的數(shù)據(jù)分為三類。

1)數(shù)據(jù)突發(fā)產(chǎn)生、數(shù)據(jù)量小、對時間很敏感，如星箭分離等會觸發(fā)程控的緊急消息；

2)數(shù)據(jù)周期產(chǎn)生、周期長、數(shù)據(jù)量大，對時間較敏感，如衛(wèi)星溫度統(tǒng)計數(shù)據(jù)；

3)數(shù)據(jù)突發(fā)產(chǎn)生、對時間不敏感，如軟件自主處置故障后產(chǎn)生的健康事件報告。

針對上述并發(fā)數(shù)據(jù)量大、產(chǎn)生周期多種多樣、對時延敏感度不同的特點，在時間同步1553B總線通信協(xié)議基礎上進行了改進：

1)數(shù)據(jù)集中調(diào)度，提升對單次數(shù)據(jù)塊傳輸服務的帶寬利用率；

2)按優(yōu)先級發(fā)送，將時間敏感的緊急消息設為高優(yōu)先級，實時遙測判讀數(shù)據(jù)設為中等優(yōu)先級，延時遙測回查數(shù)據(jù)設為低優(yōu)先級。在發(fā)送時，按照優(yōu)先級從高到低發(fā)送數(shù)據(jù)。

2 基于兩級“生產(chǎn)者-消費者”模型的RT突發(fā)數(shù)據(jù)發(fā)送控制方法

2.1 基于映射關系的數(shù)據(jù)集中調(diào)度

按照“數(shù)據(jù)集中調(diào)度”的設計思路，本文采用“生產(chǎn)者-消費者”模型進行RT并發(fā)數(shù)據(jù)調(diào)度設計。以某RT軟件為例，為其數(shù)據(jù)傳輸需求建立“生產(chǎn)者-消費者”模型，如圖3所示。

圖3 兩級“生產(chǎn)者-消費者”模型示意圖

解決RT端數(shù)據(jù)發(fā)送問題的關鍵在于如何協(xié)調(diào)產(chǎn)生周期性數(shù)據(jù)的進程、產(chǎn)生突發(fā)性數(shù)據(jù)的進程與總線發(fā)送進程之間的關系，通過合理調(diào)度發(fā)送順序、組織單次發(fā)送內(nèi)容，實現(xiàn)對BC分配給本RT通信帶寬的充分利用，快速、高效完成數(shù)據(jù)傳輸。

“生產(chǎn)者-消費者”模型是解決有限緩存約束下多進程同步問題的經(jīng)典模型，該模型描述了共享緩沖區(qū)的進程間，即“生產(chǎn)者”和“消費者”，在運行時的讀寫沖突問題。該模型有兩個設計重點：一是協(xié)調(diào)“生產(chǎn)者”、“消費者”間對緩存的互斥操作，以保證數(shù)據(jù)完整性；二是緩存區(qū)滿時“生產(chǎn)者”不應繼續(xù)添加數(shù)據(jù)。

從圖3中可見，在第1級“生產(chǎn)者-消費者”模型中，軟件各進程作為“生產(chǎn)者”，以CCSDS標準空間包格式生成待發(fā)數(shù)據(jù)項，并緩存在本進程的內(nèi)部緩存中；總線組幀緩存作為“消費者”，將不同進程緩存中的數(shù)據(jù)項組織成幀，組幀緩存大小與單次數(shù)據(jù)塊傳輸能力相匹配。總線組幀緩存按照固定優(yōu)先級順序組織，序號越小、優(yōu)先級越高。

將RT待發(fā)數(shù)據(jù)分為高、中、低3個優(yōu)先級，不同優(yōu)先級的數(shù)據(jù)源對應固定范圍的組幀緩存區(qū)。高優(yōu)先級緩存對應初始化、程控A、程控B、程控C等進程，這幾個進程的數(shù)據(jù)特點是突發(fā)性產(chǎn)生數(shù)據(jù)、數(shù)據(jù)量小、時間敏感度高，且部分數(shù)據(jù)有分多次發(fā)送的約束。中等優(yōu)先級緩存對應溫度統(tǒng)計、占空比統(tǒng)計等進程，這兩個進程的數(shù)據(jù)特點是周期性產(chǎn)生數(shù)據(jù)、周期長、數(shù)據(jù)量大、時間敏感度較高，地面希望在數(shù)據(jù)產(chǎn)生時能通過實時遙測完成監(jiān)視。低優(yōu)先級緩存對應事件報告、自主健康、內(nèi)存讀出等進程。這些進程的數(shù)據(jù)特點是突發(fā)性產(chǎn)生數(shù)據(jù)、數(shù)據(jù)量不固定、時間敏感度低，地面不需要實時判讀相關數(shù)據(jù)項，但要求可通過延時遙測進行數(shù)據(jù)回查。

在應用層，對部分數(shù)據(jù)發(fā)送方式有特殊約束，如程控A、B、C進程產(chǎn)生的事件包能夠觸發(fā)BC后續(xù)程控操作，為確?？煽坑|發(fā)BC相關程控，要求每個關鍵事件要傳輸三次事件報告，且三次事件報告需分別發(fā)送。針對這種個性化發(fā)送約束，在進程緩存與組幀緩存之間，按照優(yōu)先級建立映射關系。軟件更新一個組幀緩存內(nèi)容時，按照映射關系遍歷與之對應的進程緩存區(qū)，將其中所有待發(fā)數(shù)據(jù)項組織成一個總線傳輸數(shù)據(jù)項，提升單次數(shù)據(jù)塊傳輸帶寬利用率。例如：針對高優(yōu)先級數(shù)據(jù)，組幀緩存2映射了程控進程A的事件A1、程控進程B的事件B1和程控進程C的事件C1等3個數(shù)據(jù)項。在這3個關鍵事件同時發(fā)生時，通過本文設計的方法能夠?qū)㈥P鍵事件的緊急消息分別組織進緩存2、3、4中，并按照順序通過三次數(shù)據(jù)塊傳輸發(fā)送給BC。

2.2 基于優(yōu)先級的數(shù)據(jù)發(fā)送控制

在第1級“生產(chǎn)者-消費者”模型中完成對待發(fā)數(shù)據(jù)項基于映射關系的集中調(diào)度后，第2級模型以總線發(fā)送控制模塊為“消費者”，采用基于優(yōu)先級的發(fā)送策略，將總線組幀緩存內(nèi)的數(shù)據(jù)幀逐次發(fā)送出去。發(fā)送控制流程如圖4所示：

圖4 RT方數(shù)據(jù)發(fā)送控制流程

1)RT首先檢測數(shù)據(jù)發(fā)送通道是否可用，若通道為占用態(tài)，結束本次控制；若通道可用，繼續(xù)后續(xù)檢測；

2)順序輪詢按照優(yōu)先級排序的總線組幀緩存，將輪詢到的第一項待發(fā)數(shù)據(jù)拷貝到總線芯片數(shù)據(jù)塊發(fā)送子地址中，并釋放該總線組幀緩存；

3)更新數(shù)據(jù)塊發(fā)送握手消息ATR，設置發(fā)送通道為占用態(tài)。

從上述步驟可見，該方法能在發(fā)送通道為空閑時將總線組幀緩沖區(qū)中優(yōu)先級最高的數(shù)據(jù)幀發(fā)出。在緊急消息產(chǎn)生時，若RT方發(fā)送通道為空閑狀態(tài)，相應緊急消息能馬上發(fā)出；若RT方發(fā)送通道為占用態(tài)，相應緊急消息能在發(fā)送通道恢復空閑后馬上發(fā)出。采用本方法發(fā)送涉及程控的關鍵事件時，最大傳輸延遲為本RT對應的兩次相鄰數(shù)據(jù)塊傳輸?shù)拈g隔。

在本文設計的發(fā)送控制方法中，臨近資源有兩類：1)總線組幀緩存區(qū)；2)總線芯片數(shù)據(jù)塊發(fā)送用RAM區(qū)。對總線組幀緩存區(qū)，通過總線組幀邏輯與總線發(fā)送控制邏輯的順序運行，避免讀寫沖突；對總線芯片數(shù)據(jù)塊發(fā)送用RAM區(qū)，通過發(fā)送通道“占用”標志避免讀寫沖突。

3 試驗結果及分析

在智能化敏捷遙感衛(wèi)星的綜合電子系統(tǒng)上，對本文提出的RT突發(fā)數(shù)據(jù)發(fā)送控制方法進行了驗證試驗[18-21]。將總線消息組織、傳輸耗時與消息間隔等考慮在內(nèi)，一條32字消息在1 Mbps速率的1553B總線上傳輸耗時約為1 ms?？紤]現(xiàn)有RT常用總線芯片的堆棧大小(64條消息)，設定協(xié)議中通信幀長度為50 ms，時間同步周期為1 s，每個時間同步周期含20個通信幀。RT方設置由幀同步觸發(fā)1553B總線中斷，即使一個通信幀內(nèi)只與一個RT通信，亦不會發(fā)生堆棧溢出。BC采用最高效服務質(zhì)量(Qos)數(shù)據(jù)獲取方式，在該方式的獲取時序下每3幀完成從RT采集一個數(shù)據(jù)塊的動作。總線上只有本RT產(chǎn)生數(shù)據(jù)塊獲取申請，RT端單次數(shù)據(jù)塊傳輸最大發(fā)送能力1 024字節(jié)。

試驗中測試了3個工況：工況1中多個程控事件同時發(fā)生；工況2中多個程控事件按照一定時間順序發(fā)生，一個程控事件先發(fā)生，另外兩個程控事件在第一個程控事件的第1條消息寫入總線芯片時發(fā)生；工況3中一個程控事件在統(tǒng)計數(shù)據(jù)發(fā)送過程中發(fā)生。其中，每個程控事件分別產(chǎn)生3個事件包，每個包長度8字節(jié)，對3個包有分次發(fā)送要求。工況3中的統(tǒng)計數(shù)據(jù)一次性產(chǎn)生6個統(tǒng)計包，每個包長1 000字節(jié)，關鍵事件在統(tǒng)計包產(chǎn)生50 ms后產(chǎn)生。由于通過外部測試設備難以穩(wěn)定觸發(fā)3個測試工況的時序，為各工況分別開發(fā)了測試版本軟件，通過軟件內(nèi)部定時器觸發(fā)相應的時序。

在3個工況下，將本文設計的發(fā)送控制方法與傳統(tǒng)發(fā)送方法進行比較。在傳統(tǒng)發(fā)送方法中，按照數(shù)據(jù)項產(chǎn)生順序發(fā)送數(shù)據(jù)，不對數(shù)據(jù)項進行拼幀操作，每次發(fā)送一個獨立的數(shù)據(jù)項。通過1553B總線監(jiān)視設備判讀消息發(fā)送情況。針對各工況進行多次測試，對比了在兩種方法控制下各程控事件對應的第一個數(shù)據(jù)項發(fā)出時間、各程控事件對應的最后一個數(shù)據(jù)項發(fā)出的時間及所有程控事件完成傳輸?shù)目倐鬏敶螖?shù)，結果如表1所示。

從表1可見，在多次測試中，由于BC、RT軟件的時序不完全同步，觀察到的時間有一定波動。在傳統(tǒng)發(fā)送控制方法下，在工況1、2中需要9次傳輸將全部事件包發(fā)出，傳輸順序與消息生成順序一致。多個程控事件同時發(fā)生或接近同時發(fā)生時，只有首先占用發(fā)送通道的事件的發(fā)送延時能夠得到保障，后續(xù)事件包的發(fā)送延時與取得發(fā)送通道的順序有關。在工況3中，關鍵事件傳輸延時受已占用發(fā)送信道的統(tǒng)計數(shù)據(jù)影響，統(tǒng)計數(shù)據(jù)待發(fā)數(shù)據(jù)量越大，關鍵事件的傳輸延時也越大。

表1 傳統(tǒng)RT數(shù)據(jù)發(fā)送方法與本文設計的發(fā)送控制方法的比較

在本文設計的發(fā)送控制方法控制下：

1)在工況1中，共發(fā)生3次數(shù)據(jù)塊傳輸，每次傳輸包含分別屬于3個事件的各一條緊急消息。滿足各自事件對緊急消息發(fā)送方式的約束，為同時發(fā)生的關鍵事件提供了同等時延的傳輸服務，提升了對單次傳輸服務的帶寬利用率，減少了對傳輸通道的占用。

2)在工況2中，共發(fā)生4次數(shù)據(jù)塊傳輸。第1次傳輸中包含事件A的第一條緊急消息，第2次傳輸中包含事件B、C的第一條緊急消息，第3、4次傳輸中包含分別屬于3個事件的各一條總線消息。可見在發(fā)送通道處于占用狀態(tài)時，發(fā)送控制策略能夠?qū)⒑罄m(xù)發(fā)生的緊急消息組織、追加進處于待發(fā)狀態(tài)的總線組幀緩存中。

對先產(chǎn)生的關鍵事件，這會造成其后續(xù)待傳輸?shù)木o急消息時延增加。但從系統(tǒng)層面分析，每個關鍵事件發(fā)三次的目的是避免BC丟失消息導致未對相應的關鍵事件進行響應。在總線通信正常情況下，BC接收到關鍵事件對應的第一條緊急消息后，即會觸發(fā)相應的程控，并不會響應后續(xù)兩次備保的緊急消息。因此，優(yōu)先傳輸后續(xù)關鍵事件的第一條緊急消息，能夠提升整個系統(tǒng)的實時性。

3)在工況3中，通過基于優(yōu)先級的發(fā)送控制對總線發(fā)送信道的占用次數(shù)與傳統(tǒng)方法相同，但實現(xiàn)了緊急消息對正在發(fā)送中的統(tǒng)計數(shù)據(jù)的信道搶占。在當前占用發(fā)送通道的統(tǒng)計數(shù)據(jù)發(fā)出后，馬上可以開始傳輸關鍵事件。在關鍵事件發(fā)生后，在其優(yōu)先級為待發(fā)隊列最高優(yōu)先級時，最差情況下能在延遲一個數(shù)據(jù)塊傳輸周期后得到服務。

從上述測試結果可見，本文設計的發(fā)送控制方法通過組幀緩沖區(qū)實現(xiàn)事件包的合幀發(fā)送，在滿足發(fā)送約束的同時，改善了各事件的發(fā)送延時，降低了占用總線發(fā)送通道的次數(shù)。

4 結束語

本文針對采用時間同步1553B總線協(xié)議的RT并發(fā)數(shù)據(jù)發(fā)送控制問題，提出了一種基于兩級“生成者-消費者”模型的突發(fā)數(shù)據(jù)控制方法。和傳統(tǒng)發(fā)送方法比，該方法：

1)對RT負責檢測、BC負責實施的關鍵程控動作，提供了可預期的傳輸時延保障；

2)在多個事件并發(fā)時，能在滿足可靠性約束條件(分多次發(fā)送)的前提下，減少了對RT發(fā)送通道占用次數(shù)，使各事件復用發(fā)送通道；

3)在信道被數(shù)據(jù)量大、時間敏感度低的數(shù)據(jù)傳輸占用時，關鍵事件可搶占發(fā)送信道，提升系統(tǒng)對關鍵事件的響應實時性。

該方法已在多顆智能化敏捷遙感衛(wèi)星的數(shù)管RT軟件設計中得到應用，并已經(jīng)過在軌驗證，可為后續(xù)應用時間同步1553B總線通信協(xié)議的航天器提供軟件設計參考。