1553B總線即插即用解決方案*

呂良慶，安軍社

(1. 中國科學院 國家空間科學中心 復雜航天系統電子信息技術重點實驗室， 北京 100190；2. 中國科學院大學， 北京 100049)

MIL-STD-1553B總線在國內外航天工程領域已經得到了廣泛的應用，適用于低速、高可靠的數據傳輸，通常用于系統管理和控制。為此各航天組織也依之制定了各自的1553B通信協議，例如歐洲空間局(European Space Agency, ESA)的ECSS-E-ST-50-13C[1]和我國的GJB 289A-97[2],以及為不同通信形式而改造的1553B總線協議[3-5]。這些通信協議及其應用情況普遍有一個特點，就是參與通信的遠程終端(Remote Terminal，RT)和傳輸的消息是事先經過協商確定好的，采用固定消息時序分配的方式通信。這種做法能夠滿足不同項目任務廣泛的用戶應用需求，但是對于開發方和系統構建過程而言，其協調、設計、驗證工作是比較煩瑣的。

空間數據系統咨詢委員會(Consultative Committee for Space Data System,CCSDS)的航天器接口業務(Spacecraft Onboard Interface Services，SOIS)[6-9]采用了即插即用的思想，系統架構底層可以接入多個異構子網，1553B總線只是其中之一。架構上層的應用和業務過程對這些子網的訪問是透明的，因此設備級的即插即用過程首先要在子網內部來解決。

1 即插即用1553B總線需要的設計基礎

1553B總線通信涉及總線控制器(Bus Controller, BC)的應用部分BCA和服務部分BCS、RT的服務部分RTS和應用部分RTA共4個角色，它們之間的通信關系見圖1。

在ECSS-E-ST-50-13C中歸結了5項1553B總線服務，即時間服務、通信同步服務、分發和獲取-置數和取數服務、數據塊傳輸服務和終端管理服務，以原語方式說明了各項服務的交換信息和時序安排。同時給出了子地址編排、方式碼消息使用建議等。

BCS和RTS的實體中包括1553B總線協議芯片作為高級通信引擎(Advanced Communication Engine，ACE)，典型的如DDC61580系列[10]。ACE實現了鏈路層協議，并且配有相應的配置寄存器和消息數據緩存區。

1553B總線通信通過編排和運行總線表實現。為適應不同消息的傳輸需求和消息時間間隔(TITV)要求，總線表編排采用消息服務請求方式，劃分為多個消息小幀，每個小幀以查詢服務請求的矢量字消息開頭，以同步消息(表示為Syn)結尾，中間為需傳輸的消息。每個小幀周期(TFRM)相等。如果某個消息不需要傳輸，則該消息不上線，但是時間仍然占用，以保證TFRM的穩定。這樣組織的總線表稱為主總線表，其中TFRM表現為總線周期(TBUS)，即二者在穩定運行期間是相等的，只在總線表重構過程中有所區別。

在主總線表運行期間，BC可通過切換總線表的方式，改變消息序列的運行。這種運行控制方式稱為插入消息方式，可作如下約定：

1)每次插入的消息只能運行一次。

2)插入消息運行完畢后，如果有新的插入消息請求，可繼續插入消息運行，如果沒有則返回主總線表斷點處繼續運行。

3)插入消息采用幀結束(End Of Frame，EOF)處理方式，先停止總線消息運行，對消息幀中的所有消息進行一次性處理，切換總線表，再重新啟動運行。因此插入消息序列中的消息時間(TMSG)可按照最小時間設置，不必留有余量。

上述各種時間概念和關系示意見圖2。

圖1 1553B總線通信順序Fig.1 1553B bus communication sequence diagram

圖2 TMSG、TITV、TFRM、TBUS概念示意Fig.2 Concepts of TMSG、TITV、TFRM、TBUS

主總線表加插入消息方式的總線運行控制示意見圖3。

圖3 主總線表和插入消息運行的轉換關系Fig.3 Switch relationship between main bus list and insert message list

工程項目中的一般做法是BC方還需要與各RT方協調，進行RT地址和子地址(消息類型)的分配，定義消息長度和數據格式，確定消息傳輸時間和時序，形成項目級的1553B總線通信協議和接口控制文件。

2 即插即用1553B總線通信協議

RT方的設計是固定而簡單的，不能因為增加了即插即用的概念而造成RT方的設計復雜，而BC方應對RT方設計的多樣性和針對性具有自適應能力，這是即插即用系統應該具有的特征。但是還是需要RT方至少將其傳輸需求告知BC方，BC才能進行通信管控。為此需要增加RT接入時的握手過程，以傳遞RT的電子數據單(Electronic Data Sheets，EDS)，供BC動態構建總線表。

2.1 RT子地址的使用約定

為了建立初步的握手關系，需要對子地址的分配進行一些固定的約定。RT的子地址在ECSS-E-ST-50-13C基礎上約定見表1。

表1中RT可自行配置的子地址允許繼承使用已有的配置，并事先與BC方約定。如果不約定，則BC根據RT的EDS動態編排總線表，以主動適應不同RT的不同傳輸需求實現即插即用的特征。

表1 RT子地址使用約定

矢量字消息用于標識RT方的消息傳輸服務請求，消息中數據字16 bit中的某1位置1表示有某種消息需要傳輸，BCS將據此安排相應消息傳輸。該數據字定義如下：

1)D0～D14：RT可個性化定義對應所需消息。

2)D15：固定用于請求發送EDS消息。

2.2 RT EDS的設計

RT的EDS內容分為2層：1553B總線通信層EDS(簡稱RT EDS)和應用EDS。

RT EDS目的是描述RT方所需的傳輸消息、子地址定義以及矢量字服務請求關系[11]，見表2。

表2 1553B通信層EDS格式[12]

1)矢量字定義通過矢量字mask和數據域建立16 bit請求位與子地址的對應關系。

2)T/R子地址mask定義了哪些子地址被使用或未使用。

3)T/R子地址定義規定了被使用的子地址的消息類型、數據字個數和消息間隔TITV要求。

4)消息間隔TITV要求：16 bit，單位ms。

? 全1表示65.535 s，全0表示沒有周期要求，屬于根據條件、請求、需要而傳輸的消息。

? 劃分時間(TDIV)的取值用于判定消息是直接安排在主總線表中(TITV

應用EDS用于描述系統上層應用，是RT對本設備的功能、性能、接口、工作方式的EDS描述，傳遞給BCA以供構建系統上層的服務關系。這部分是遵從可擴展標識語言(eXtensive Markup Language, XML)語法語義規定[13-14]描述的對象，經過翻譯后的解釋數據。

EDS傳輸格式采用CCSDS空間包格式[15]。包中的應用過程標識符(Application Process IDentifier，APID)指明了內容對應到BC或RT端內部的不同層次的應用過程，內容的區分通過包副導頭定義。

2.3 即插即用的建立過程協議

RT接入步驟如下：

Step1：以30個RT矢量字消息組成查詢幀，周期輪詢RT的服務請求，直到發現有RT接入(消息不超時)。

Step2：BCS對查詢幀只進行矢量字中EDS請求位的判讀。

Step3：當1個RT接入后，首先向BC提出發送EDS的服務請求。

Step4：BCS響應RT EDS服務請求，以插入消息的方式將RT EDS安排傳輸并接收。

Step5：BC根據RT EDS構建總線表。

Step6：總線表建立并啟動運行后，調整插入查詢幀運行的時間間隔(TLOP)，并按照TLOP插入查詢幀查詢剩余RT。

Step7：重復Step 3～6步，實現RT逐個加入的過程。

Step8：當所有(30個)RT加入總線表運行后，不再插入查詢幀。

Step9：每當有1個新的RT接入時，BC還需要解決新RT通信數據的收發控制，通過BCA和BCS之間的標準數據結構和統一服務機制來解決。

Step10：在某個RT總線通信建立后，如果RT有應用EDS需要傳遞，可繼續通過EDS請求向BC傳輸。

RT撤出步驟如下：

Step1：當某個RT連續1 min出現超時響應，且通過切換總線不能恢復通信(再加1 min)，則可判定此RT下線。

Step2：判定RT下線后，BC對總線表進行重構，刪除下線RT的所有消息，在查詢幀中增加對下線RT的矢量字消息，并調整TLOP。

Step3：該RT退出引發的應用功能上的影響和反應由BCA進行處理和系統重構。

3 即插即用1553B總線通信設計

3.1 標準數據結構設計

總線管理設計需要的標準數據結構是為了在BCA、BCS、ACE之間建立起統一的控制服務和數據傳遞服務。

標準數據結構按照位置分為ACE內存和CPU內存兩部分。ACE內存部分主要包括總線表(BUS LIST)和相關的配置寄存器[3]，是ACE定義好的數據結構，只能按照芯片使用手冊的要求進行配置和設計。

CPU部分又分為兩部分：

一部分處于BCS與ACE之間，主要包括消息表(MSGTAB)、消息號表(MSGNUMTAB)、消息塊表(MSGBLKTAB)。

MSGTAB通過消息號對主總線表和插入消息表中所有消息建立索引，目的是把消息內容的分析過程提前到初始化時進行，在運行過程中只對該表進行查詢，就能獲得諸如消息類型、數據區地址等信息，避免對總線運行產生干擾。消息類型還可以起到與應用建立聯系的作用。

MSGNUMTAB是針對主總線表中的每個小幀建立的消息號索引，目的是供BCS查詢該表，以確定某個小幀中是否有需要的消息存在，實現主總線表中消息的上線和下線操作。

MSGBLKTAB建立了消息塊的地址索引，目的是供切換冗余總線使用，而不干擾總線運行。

另一部分處于BCS與BCA之間，主要包括插入消息請求表(INSMSGFLAG)、數據區及其控制標志。為適應即插即用的隨機性，數據區及其標志可采用請求隊列加緩存的統一方式組織。

3.2 BC總線管理設計

總線管理設計分為總線初始化、總線控制和總線應用。

總線初始化包括總線表構建和對ACE總線表、寄存器的設置，以及根據總線表分析生成上述數據結構。在即插即用背景下，隨著RT的增減，總線表會動態構建，每次都要重復上述過程。

總線運行控制方式包括對主總線表和插入消息表操作兩種方式。主總線表的運行控制采用消息結束(End Of Message，EOM)處理(包括中斷和查詢)，安排消息上線和消息下線。插入消息表運行控制采用EOF處理，并進行總線表切換。

總線應用是指BCA與BCS之間在取數和置數以及控制方面的交互問題。

BC管理的基礎功能模塊共有13個，見表3。

表3 1553B基礎功能模塊

3.3 總線表的構建算法

3.3.1 總線表構建的前提約定

總線表的構建算法就是根據RT EDS生成新的總線表。即插即用的總線通信使用的主總線表可以只有固定的30個RT矢量字消息加1條同步消息，而所有其他有效消息均采用插入消息的方式。這種方式能保證所有RT的所有消息得到傳輸，但消息的周期性難以保證。因此有必要采用主總線表加插入消息的方式來平衡這一問題，而主總線表的構建算法就成為主要內容。為保證構建的總線表時間特性，需要對各種消息TMSG進行約定，約定的原則如下：

1)1553B總線碼速率為1 Mbit/s，1個數據字在總線傳輸時為20 bit(3 bit同步+16 bit數據+1 bit校驗)，1 bit傳輸需1 μs，加上狀態字響應時間4～12 μs[16]，因此最大32字的消息可以計算為：指令字20 μs +數據字(32×20 μs)+響應時間(4～12 μs)+狀態字20 μs +間隙(>4 μs)。為方便使用，32字消息的最小TMSG取值800 μs。

2)同樣的消息在主總線表中和插入消息表中的TMSG是不同的，主要是因為主總線表中的消息采用EOM方式處理，需要為BCS的響應和處理留出時間余量，而插入消息表采用EOF方式處理，處理時總線表處于停止狀態，因此消息TMSG可以不留余量。

根據這2條原則，對各種消息TMSG作如下約定：

1)RT矢量字消息在主總線表中每條3 ms，在查詢幀中100 μs。

2)同步消息100 μs。

3)主總線表中的TMSG：帶1個數據字的消息為1380 μs，每增加1個數據字，時間增加20 μs，32個數據字的消息為2 ms。

4)插入消息表中的TMSG：帶1個數據字的消息為180 μs，每增加1個數據字，時間增加20 μs，32個數據字的消息為800 μs。

3.3.2 初始主總線表的建立

收到第1個RT EDS后，主總線表的構建步驟如下：

Step1：找出RT EDS中期望的非0、小于TDIV的最大TITV，作為初始TBUS。

Step2：主總線表先安排1條RT矢量字消息+1條同步消息。

Step3：將RT EDS中的消息按順序排列在主總線表RT矢量字和同步消息之間。

Step4：RT EDS中TITV為0或超長(≥TDIV)的消息按照插入消息安排，不編入主總線表中。

Step5：全部安排完畢后，累加主總線表所有消息時間TMSG作為TFRM，若TFRM≥初始TBUS，則設置完成，并以TFRM為TBUS；若TFRM<初始TBUS，則將同步消息前的最后1條消息的TMSG加長，使TFRM=初始TBUS。

Step6：將生成的總線表作為1個小幀，復制為8個。

3.3.3 第n個RT加入主總線表

收到第n個RT的RT EDS后操作步驟：

Step1：記錄當前TFRM，將8個小幀中同步消息前最后1條消息的TMSG恢復缺省值。

Step2：在當前8個小幀中加入該RT矢量字消息，TFRM加上3 ms。

Step3：根據該RT EDS將其RT消息加入8個小幀。加入消息時需要考慮TITV和位置問題。

1)加入的消息TITV是當前TFRM的n倍。

?n<2：將其加入8個小幀，每個小幀1個。

? 2≤n<3：將其加入4個小幀，從TFRM最短的小幀開始，每間隔1個小幀1個。

? 3≤n<5：將其加入2個小幀，從TFRM最短的小幀開始，每間隔3個小幀1個。

? 5≤n≤8：將其加入1個TFRM最短的小幀。

?n>8，但TITV

? 消息TITV≥TDIV：將其作為插入消息，不編入主總線表。

2)加入時的位置按照同類消息放在一起，同類消息按RT加入順序排列。如果是新類型消息，則加在所有已有消息之后、同步消息之前。

3)1條消息加入完畢后，將該消息的TMSG加入TFRM，作為新的TFRM。

Step4：繼續加入該RT的下一條消息，重復Step 3，直到RT EDS要求的所有消息加入完畢。

Step5：該RT的所有消息加入完畢后，檢查在Step 3中暫時作為插入消息的TITV與剛生成的TFRM的倍數關系n，如果n≤8，則將該消息從插入消息表中刪除，按照Step 3將其加入主總線表小幀中。

Step6：求出所有小幀的新TFRM，取其中最大的TFRM。若RT EDS中的消息最大TITV>最大TFRM，加長該小幀中同步消息前的最后1條消息的TMSG，使TFRM=該RT消息的最大TITV。

Step7：若該RT EDS中的消息最大TITV≤最大TFRM，將其余小幀的TFRM均調整為與最大TFRM相同(即所有TFRM相等)，方法同上。

Step8：若新TFRM<調整前的TFRM，則將每個小幀的TFRM繼續加長到調整前TFRM。

3.3.4 有RT撤出

在運行過程中，有RT撤出時操作步驟：

Step1：將撤出RT的消息從總線表中刪除。

Step2：刪除后，重新計算各TFRM，取其大者作為TBUS。

Step3：在剩余所有的RT EDS中找到消息最大TITV，若消息最大TITV≤新TBUS，則調整完成，否則所有TFRM均延長(方法同上)，作為新的TBUS。

Step4：查詢幀增加RT矢量字消息。

Step5：調整TLOP，并按照TLOP插入查詢幀。

Step6：RT的撤出次序與RT號的大小無關。

3.4 總線表構建適應性評估

總線表構建效果評估包括時間效果和適用場景兩方面。

3.4.1 時間效果的評估

查詢握手協議過程的時間主要是指TFRM對TLOP的影響，以及查詢幀的消息時間。影響這一關系的主要有2個值，即TDIV和TLOP。TDIV的取值由主總線表中8個小幀周期之和最大值確定。TLOP需要考察主總線表和插入消息之間的時間關系。為分析確定這2個取值，作如下約定：

1)主總線表最大512條消息；

2)主總線表平均分為8個小幀，每個小幀中最多64條消息；

3)單消息按照32字來計算。

以小幀為單位，根據上述前提進行時間效果分析，計算公式如下：

TBUS=TFRM=矢量字消息數×3+消息數×2+0.1

在穩定運行期間，沒有插入消息，小幀滿64條消息(矢量字消息數最多30個，消息數為33個)時，TFRM最大，達到30×3+33×2+0.1=156.1 ms，8個小幀時間為156.1×8=1248.8 ms。因此TDIV取值1.25 s比較合適。

由于TFRM的計算公式是線性的，因此其最大值隨著RT個數的增加而線性增加。實際運行情況比這復雜，但都包絡在最大值范圍內，因此TFRM效果是可以接受的。

TLOP與插入查詢幀有關，還需要考慮插入消息時間的影響。此時至少有1條是插入矢量字消息，因此時間最長的插入消息時間是其余511條消息的總和。按每條消息800 μs計算，511條消息時間總和為408.8 ms。在主總線表和插入消息全部運行的情況下，TFRM最大為29×3+34×2+0.1=155.1 ms，最大總線周期TBUS=155.1+408.8=563.9 ms。在主總線表只有1個RT矢量字且沒有查詢到消息請求時，TBUS最小為3.1 ms。因此插入消息的運行方式加上BCS干預和處理的時間開銷會導致TBUS產生波動。

綜上，在具體程序設計時，有兩種方法確定TLOP取值：一是TLOP=TFRM×n。n太小會因為主總線頻繁插入查詢幀和插入消息對TBUS的穩定不利，太大又會影響對RT接入的時間延遲效果。二是為簡化設計而取固定值。兩種方法可以結合使用，即根據不同條件(如總線流量的平均統計情況對TFRM的影響)在每次總線表重構時動態調整n值，而以5 s作為最大值保底。

BC總線表重構過程是在CPU內存中進行的，不影響ACE中總線表的運行。由于RT個數不同，消息需求不同，重構過程所需要的時間是不確定的，與BC方CPU處理能力有關。

總線表重構后加載到ACE中的過程時間一般為毫秒級。

由此可知，即插即用的RT識別周期和加載時間在條件確定時不會有大的差別，而總線表重構時間是影響RT識別時間長度的主要因素，在CPU處理能力確定的情況下，主要看重構算法的優化。

3.4.2 適用場景評估

主總線表重構面臨的適用場景有兩種：

1)BC第一個加電運行，然后從無到有，所有RT一一接入的過程。這種情況與地面測試、在軌飛行過程中的設備正常加電的過程一致，也是本協議的出發點。

2)有RT先加電運行，當BC加電運行時，一次可以查詢到多個RT同時接入。這種情況與系統復位(掉電)后，所有設備又同時上電工作的情況一致。

第2種情況下，BC處理與第1種情況在本質上相同，只是在構造完1個RT的總線表后，不是直接運行，而是看是否還有第2個RT接入，即多RT接入過程一次性完成。為此總線表構建過程將重復多次，看似冗余，但可以適應任意RT數量和順序的接入。

4 即插即用1553B的系統層次架構

SOIS架構中，通過設備發現服務(Device Discovery Service，DDS[17])、設備枚舉服務(Device Enumeration Service，DES[18])、設備虛擬服務(Device Virtualization Service，DVS[19])和設備訪問服務(Device Access Service，DAS[20])可以構建上層系統的設備即插即用，本文設計的1553B總線管理基礎功能模塊對它們的支持和銜接關系見圖4[21]。

圖4中上3層屬于SOIS的相關業務架構。在收到RT EDS后，從CONSTRUCTBUS開始進行總線表構建，向下初始化總線INITBC，向上將RT EDS內容(設備虛擬訪問信息和應用EDS)報告給DDS。DDS依之建立上層邏輯地址與下層物理地址之間的映射關系，將應用EDS上傳給DES，納入系統的管理信息數據庫(Management Information Base，MIB)中，提供給應用層使用。

在系統運行過程中，DVS根據應用層的使用要求和虛擬設備地址，與DES提供的物理地址進行匹配，然后交由DAS執行對設備的訪問。

DAS訪問設備時可以使用存儲訪問服務(Memory Access Service，MAS[22])和包服務(Package Service，PS[23])兩種方式。這兩種服務都需要DDS提供下層1553B總線的具體訪問方式(地址和數據)，使用取數(READDATA和READBC)和置數(WRITEDATA和WRITEBC)服務實現與BCS之間的數據傳遞。

DAS通過SETINSFLAG和ARRANGEMSG向BCS提出消息請求。BCS使用ARRANGEMSG服務和SKIPMSG服務安排主總線表消息上線和下線，使用插入消息INSMSG服務切換總線表，使用STOPBC和RUNBC服務來停止和啟動總線的運行。

圖4的系統架構只有1553B總線一個子網。如果還有其他子網，則系統需增加匯聚層協議，而圖4中BCS的數據發送和接收緩沖區，READDATA、WRITEDATA和SETINSFLAG服務都將劃歸匯聚層協議。

5 結論

本文的1553B總線即插即用解決方案試圖從由傳統的接入設備通過標準化接口適應系統的設計思路，轉變為由系統對異構和未知設備進行自動識別和配置，并構建形成新的能力的思路。因此本方案在兼容已有的1553B總線通信協議(主要是ECSS-E-ST-50-13C)基礎上，只增加了初始握手部分的協議內容，后續的正常通信過程和內容交由通信雙方通過EDS交流的方式，建立起適應性的通信關系。從效果評估看，時間特性可接受，能夠適應實際使用場景，而且即插即用對RT方編程的改變僅在于要求其能夠一次性編輯形成自身的EDS，并按照握手協議將EDS傳遞給BC，其余可保持原有設計不變。

圖4 1553B總線BC與SOIS的服務銜接層次關系[21]Fig.4 Services of 1553B bus controller in SOIS architecture[21]