應用擴展幀的航天器CAN總線應用層協議設計

閆國瑞 蘇晨光 林博軒 史簡 田帥虎 李軍予

(航天東方紅衛星有限公司，北京 100094)

現代航天器信息傳輸多采用總線技術，如1553B總線[1-3]、Spacewire總線[4-5]和CAN總線[6-7]等。CAN總線因具有突出的實時性、靈活性、低成本，在航天領域的應用也越來越廣泛。采用CAN總線通信網絡可將多臺計算機連接起來，形成星上統一信息網絡，負責完成航天器的綜合信息處理工作。CAN總線包括物理層、數據鏈路層和應用層3層協議。國際標準化組織(ISO)的ISO 11898[8-9]中只包含了物理層和數據鏈路層的協議，沒有規定應用層協議。針對航天領域CAN總線應用層協議，歐洲航天標準化合作組織(ECSS)的航天CAN總線擴展協議[10]推薦應用層采用CANopen協議，但該協議不支持復雜星載組播信息流設計，且應用復雜，英國薩瑞衛星技術公司也認為CANopen協議棧占用資源較多，不適合其星載通信模式[11]。

國內航天領域，根據國內航天器信息架構及信息流需求，提出了CAN總線應用協議[6-7]。文獻[6]中提出的CAN總線應用層協議，在小衛星領域得到了廣泛應用。該協議主要針對主從通信方式設計，仲裁場中的站地址規定為：主節點發送數據時，表示目的節點地址；從節點向主節點發送數據時，表示源節點地址，從節點向從節點發送數據時，表示目的節點地址；主節點或從節點發送廣播數據時，表示目的節點地址。由于該協議數據幀中沒有設計源節點地址，源節點自主發送數據時，接收節點不能有效判別該數據幀來源，導致該協議不支持多主通信方式。隨著航天器信息融合和信息綜合利用需求的提升，航天器上設備間實時數據交互量和數據交叉應用需求也在不斷提升[7]，例如在實際應用中，針對有效載荷實時獲取連續姿態數據及全球導航衛星系統(GNSS)定位數據的需求，若采用主從方式，因主節點無法獲知姿態數據和GNSS定位數據的更新時刻，不能保證數據及時發送及連續性，導致該協議不能有效支持相關需求。文獻[7]中提出了支持多主的協議，但該協議不支持多優先級仲裁，例如不支持遙測、遙控數據優先級仲裁，不支持上述姿態、GNSS定位等數據的優先級仲裁，導致該協議雖然設計了多主，但在工程應用中具有局限性。此外，該協議支持節點和組播數量有限，僅支持5個組播地址，不適應復雜的航天器信息流設計。文獻[6-7]的協議均存在下述問題，即：①針對復雜航天器的信息流需求，通過CAN總線屏蔽碼已經不能自動過濾非相關信息，需要上層軟件編寫特殊代碼進行數據過濾，造成應用復雜且占用上層軟件機時。②僅支持自定義信息數據包傳輸，且信息數據包傳輸長度有限(須小于256 byte)，不支持CCSDS空間包[12-13]等數據包的直接傳輸，不利于信息傳輸的標準化。③多幀數據的結束幀需要上層軟件根據數據包長度進行識別，增加了應用復雜度。

本文提出航天器CAN總線應用層協議，對CAN總線擴展幀29 bit標志符進行了合理劃分，以及對數據場的信息數據包傳輸進行了設計，形成了一套完整的CAN總線應用層協議，解決了上述問題。該協議可支持多優先級、主從、多主、組播、廣播等多種通信方式，支持航天器復雜信息流設計，相對傳統協議具有功能完善、適用范圍廣、靈活性高等優點。

1 CAN總線擴展幀結構

CAN總線擴展幀結構見圖1，由幀起始(SOF)、仲裁場、控制場、數據場、循環冗余校驗場(CRC)、應答場(ACK)、幀結束(EOF)共7個不同的位場組成。

注：N為字節數；ID為標志符；DLC為數據幀長度。

對于擴展幀，替代遠程請求(SRR)以及擴展標志符(IDE)均為隱性，遠程發送請求(RTR)用于區分數據幀和遠程幀，RB1～RB0為保留。上述幀結構中，仲裁場中的標志符、控制場中的數據長度碼及數據場應用軟件可以進行訪問，CRC等其余部分由CAN總線專用芯片生成。航天器CAN總線應用層協議的設計，基于航天數據交互需求，進行協議要素設計，然后對標志符、數據場進行劃分與定義，形成適合航天器的通信機制。

2 應用層協議設計

針對文獻[6-7]中CAN總線協議存在的不足，以及航天器數據實時交互等信息融合和信息綜合應用的需求，本文對CAN總線擴展幀29 bit標志符進行合理劃分，設計了一套完整的CAN總線應用層協議。與文獻[6-7]的協議要素比對，如表1所示。文獻[6]的協議要素包括優先級、站地址、幀類型，該協議主要針對主從通信方式設計，不支持多主通信，在主從通信時因所有數據均按固定時序進行輪詢，無數據搶權發生，通常優先級是非必要的；而文獻[7]的協議要素包括源節點地址、目的節點地址、幀類型，該協議引入源節點地址的目的是支持多主通信，在多主通信中不同類型的數據進行優先級仲裁通常是所需的，但該協議未設置優先級，導致不支持不同類型的數據進行優先級仲裁。本文協議引入數據優先級標志、源節點地址、目的節點地址，以支持航天器不同類型數據的多優先級、多主通信需求。

表1 協議要素比對

文獻[6-7]的協議均設置了幀類型，用來區分單幀數據及多幀數據，但無法識別多幀數據的結束幀，需要上層軟件根據數據包長度進行計算識別，或設計特殊幀以表示數據發送結束，增加了應用復雜度。本文協議引入幀序號標志，結合幀序號及數據場中的長度、校驗等信息定義，支持CCSDS空間包及其他格式數據包的可靠傳輸。

本文協議特別引入了組播標志，基于組播標志給出了組播、廣播地址分配及屏蔽策略，以滿足航天器日益復雜的信息交互需求。點對點通信與組播通信分離設計，能夠規避傳統CAN應用協議[6-7]信息流設計需要對節點地址、組播地址、驗收碼、屏蔽碼進行不斷試探及驗證以滿足復雜航天器信息交互的需求，以及組播地址不足的問題，簡化了航天器信息流設計，并能夠通過屏蔽字直接屏蔽不相關信息數據包,降低上層應用軟件的復雜度，節省機時。

2.1 標志符典型分配與設計

擴展幀標志符由29 bit的ID28～ID0[8]組成，本文提出的應用層協議標志符典型分配如圖2所示，包括數據優先級、源節點地址、組播標志、目的節點地址、幀序號標志、幀序號、幀數據類型。

字節0字節1字節2字節3高5bitID28～ID27ID26～ID21ID20～ID19ID18～ID13ID12～ID11ID10～ID5ID4～ID02bit6bit2bit6bit2bit7bit5bit數據優先級源節點地址組播標志目的節點地址幀序號標志幀序號幀數據類型

(1)數據優先級由ID28～ID27組成，和節點地址一起決定了數據總線仲裁的優先級，根據實時性要求，不同數據包選擇不同的優先級，數值越小，優先級越高。在實際應用中，GNSS對時廣播可以設置成高優先級，遙控設置成次高優先級，遙測設置成低優先級。

(2)源節點地址由ID26～ID21組成，表示發起數據傳輸的節點地址，最大支持64個節點。

(3)組播標志由ID20～ID19組成，用于數據廣播或組播設計。

(4)目的節點地址由ID18～ID13組成，表示發送目標節點的地址。

(5)幀序號標志為ID12～ID11，用來標志該幀中的用戶數據屬于信息數據包中的哪一部分，該標志含義如表2所示。

表2 幀序號標志定義

(6)幀序號由ID10～ID5組成，范圍0～63，表示數據幀的序號，用于多幀數據的幀連續性判斷，可循環計數。當幀序號標志為11b時，幀序號應為0，代表單幀數據。

(7)幀數據類型即功能碼，由ID4～ID0組成，表示CAN幀的數據類型，如輪詢控制序列、應答控制序列、數據應答、遙控數據等，功能碼的定義有利于協議的標準化，定義如表3所示。

表3 幀數據類型定義

2.2 數據場設計

數據場字節編號從0開始，其設計如下。①對于單幀數據，數據場信息數據包數據和單字節校驗碼。②對于多幀數據起始幀，Byte0～Byte1為信息數據包的長度(即不包含校驗字節)，其他為信息數據包數據。③對于多幀數據的中間幀，均為信息數據包數據。④對于多幀數據的結束幀，內容為信息數據包數據和校驗碼。

信息數據包可以是CCSDS空間包，也可以是其他格式或自定義包格式，用包版本號進行區分。以數據場最多包含8 byte為例，多幀數據的起始幀、中間幀、結束幀分別如圖3～5所示。

組成數據位序76543210幀信息1RTR為000DLC為8標志符數據優先級ID28～ID27源節點地址ID26～ID21組播標志ID20～ID19目的節點地址ID18～ID13幀序號標志ID12～ID11為01b幀序號ID10～ID5為0幀數據類型ID4～ID0000數據場信息數據包數據長度L的高8bit信息數據包數據長度L的低8bit信息數據包數據Byte0信息數據包數據Byte1信息數據包數據Byte2信息數據包數據Byte3信息數據包數據Byte4信息數據包數據Byte5

2.3 利用組播標志進行信息流設計

傳統CAN應用協議[6-7]信息流設計需要對節點地址、組播地址、驗收碼、屏蔽碼進行試探及驗證，以滿足復雜航天器的信息流需求，當濾波設計不能有效過濾時，還需要上層應用軟件進行特殊處理。本文設計組播標志用于數據廣播或組播等信息流，表4給出了組播標志(Gid)、組播地址(Gaddr)、目的節點地址驗收碼、屏蔽碼等設置說明，通過組播標志能夠適應航天器復雜信息交互需求，并簡化航天器信息流設計。

組成數據位序76543210幀信息1RTR為000DLC為8標志符數據優先級ID28～ID27源節點地址ID26～ID21組播標志ID20～ID19目的節點地址ID18～ID13幀序號標志ID12～ID11為00b幀序號ID10～ID5為1,2,3,…幀數據類型ID4～ID0000數據場信息數據包數據Bytem信息數據包數據Bytem+1信息數據包數據Bytem+2信息數據包數據Bytem+3信息數據包數據Bytem+4信息數據包數據Bytem+3信息數據包數據Bytem+6信息數據包數據Bytem+7

組成數據位序76543210幀信息1RTR為000DLC不大于8標志符數據優先級ID28～ID27源節點地址ID26～ID21組播標志ID20～ID19目的節點地址ID18～ID13幀序號標志ID12～ID11為10b幀序號ID10～ID5幀數據類型ID4～ID0000數據場信息數據包數據ByteL-6信息數據包數據ByteL-5信息數據包數據ByteL-4信息數據包數據ByteL-3信息數據包數據ByteL-2信息數據包數據ByteL-1校驗字節

2.3.1 組播地址設計

如表4所示，通過組播標志可以將組播分為3類，每類可以進一步設計多個組播地址，因此本文協議支持復雜信息流需求。其中：0x7F和0xBF為典型的組播地址；0xFF一般用作廣播地址。表4所列地址可以滿足一般信息流設計的通用需求，此外，每類的組播地址可按式(1)或式(2)進一步分組。其中：x,y為集合約束變量；M,N∈{0,1,2,3,4,5}，分別為第M個和第N個比特；“?”代表按位左移，“|”代表位或，“∧”代表位異或。式(1)可用于接收廣播節點的分組組播地址設置；式(2)用于不接收廣播節點的分組組播地址設置。

{Gaddr，MN(x,y)=(Gid?6)|[0x3F∧((x?M)|(y?N))]：x,y∈{0,1}}

(1)

{Gaddr，MN(x,y)=(Gid?6)|[(x?M)|(y?N)]：x,y∈{0,1}}

(2)

根據分組組內的數量需求，式(1)和式(2)可以設置多于或者少于2 bit，在2 bit情況下，對于x,y∈{0,1}，每組可以包含4個子地址，即{Gaddr，MN(0,0),Gaddr，MN(0,1),Gaddr，MN(1,0),Gaddr，MN(1,1)}。

2.3.2 驗收碼和屏蔽碼設計

驗收碼和屏蔽碼的設置方式有多種，可按照表4方式設計，以將第M個比特和第N個比特設計為1組為例，設置為Gaddr，MN(0,0)和(1?M)|(1?N)，其中，Gaddr，MN按照式(1)或式(2)計算。設置時也可使用更通用的過濾方式，即直接按組播分類進行驗收碼和屏蔽碼設計，方法如下。①接收單類組播驗收碼可設置為(Gid?6)，屏蔽碼設置為0x3F。②同時接收組播1類和組播3類驗收碼可設置為0xC0(11b?6)，屏蔽碼設置為0xBF。③同時接收組播2類和組播3類驗收碼可設置為0xC0(11b?6)，屏蔽碼設置為0x7F。

表4 組播標志應用說明

3 驗證與分析

3.1 信息數據包傳輸應用

本文協議支持CCSDS空間包[13]、CCSDS封裝包[14]等信息數據包傳輸，可通過版本號識別信息數據包的數據結構，信息數據包數據首字節Byte0的b7～b5用于版本號定義，如表5所示。其中：版本號“000”為CCSDS空間包，空間包主導頭為6 byte(含版本號)，空間包可用于組播數據、遙測數據和遙控數據傳輸。版本號“111”為CCSDS封裝包，封裝包包頭長度1～8 byte可選(含版本號)，對于實時性較高的CAN總線單幀數據，如4 byte間接指令，采用包頭長度為2 byte的CCSDS封裝包。

表5 信息數據包數據結構

3.2 信息流需求滿足驗證

圖6給出了航天器CAN總線的典型節點及其信息流需求，主要需求說明如下。①時間數據由星務中心計算機或GNSS接收機發出，高精度溫控單元、姿態控制計算機、有效載荷1等設備接收時間數據，優先級最高。②GNSS定位數據由GNSS接收機發出，姿態控制計算機、有效載荷1、有效載荷2接收該組播，有數據連續性及實時性需求。③姿態數據由姿態控制計算機發出，有效載荷1及有效載荷2接收該組播，有數據連續性及實時性需求。④控制數據由姿態控制計算機發出，有效載荷2接收該組播，優先級高于GNSS定位數據和姿態數據。

圖6 信息流示意

上述4種數據的組播接收及數據優先級說明，如表6所示。根據本文協議GNSS定位數據和姿態數據可設計為組播3類，GNSS定位數據地址可設計為0xCF，記為組播3A，姿態數據地址可設計為0xDF，記為組播3B；控制數據設計為組播2類，地址為0xBF，記為組播2A；時間數據設計為組播1類，地址為0x7F，記為組播1A。因實時性要求，通信方式設計為有限多主通信，4種數據均設計為自主發送，其他的下行遙測數據等采用主從通信。

表6 組播接收及數據優先級說明

組播的濾波方式可按第2.3.2節通用方式濾波，姿態控制計算機、有效載荷1同時接收組播1類和組播3類，目的接收地址驗收碼可設置為0xC0，屏蔽碼設置為0xBF；有效載荷2同時接收組播2類和組播3類，目的接收地址驗收碼可設置為0xC0，屏蔽碼設置為0x7F，配電器等無組播需求的節點采用單濾波方式實現點對點通信。具體設置如表7所示，其中：ACR0/AMR0和ACR2/AMR2分別為濾波器1和濾波器2對源節點地址的驗收碼和屏蔽碼；ACR1/AMR1和ACR3/AMR3分別為濾波器1和濾波器2對目的節點地址的驗收碼和屏蔽碼。

表7 濾波設計示例

可見，本文協議通過組播標志能簡化航天器信息流設計，能夠通過濾波設計為接收節點有效過濾不相關信息，協議支持多優先級、多主通信，可以滿足航天器信息流實時交互需求。

3.3 性能比對及適應性分析

對上述信息流設計，針對文獻[6-7]及本文提出的CAN總線應用層協議的時延及適應性進行分析。其中：時間數據8 byte；GNSS定位數據63 byte；姿態數據56 byte；控制數據14 byte。CAN總線碼速率為500 kbit/s，CAN總線多幀數據幀尾至幀頭的間隔設為0.2 ms。時間數據傳輸時間約為0.26 ms，GNSS定位數據傳輸時間約為4.4 ms，姿態數據傳輸時間約為3.9 ms，控制數據傳輸時間約為1.2 ms，遙控指令傳輸時間約為0.26 ms，遙測數據包為205 byte，傳輸時間約為12.1 ms。

因文獻[6]不支持多主，上述所有數據均按照設定好的固定時序進行輪詢，星務中心計算機作為主節點，并不知道從節點控制數據、GNSS定位數據、姿態數據的更新時刻，星務中心計算機按照其運行周期1 s查詢從節點的上述數據是否更新，因此最大時延為運行周期1 s加上傳輸時間，并且由于主節點和從節點晶振非同源，不能保證上述數據輸出的連續性。

因文獻[7]不支持多優先級，按照其協議設計，GNSS定位數據會因遙測數據包、遙控指令的正在傳輸造成阻塞；時間數據會因遙測數據、遙控指令的正在傳輸造成阻塞；控制數據、姿態數據會因遙測數據、GNSS定位數據、時間數據、遙控指令的正在傳輸造成阻塞，并且上述時延會因遙測數據包的長度變化導致時延不同，數據自主發送的過程中不支持遙控指令的優先執行。

本文協議根據應用需求，設時間數據優先級最高，遙控指令、控制數據優先級次高，姿態數據及GNSS定位數據為較低優先級，遙測數據優先級最低。

各種數據最大時延分析如表8所示。結果表明：本文協議數據時延均明顯優于其他協議，并支持遙控指令插入。

表8 時延及適應情況分析

本文協議與文獻[6-7]的協議適應性比對，如表9所示。本文典型分配能夠覆蓋現有航天器信息流設計需求，并留有擴展空間，有助于形成統一的航天器CAN總線協議。

表9 協議適應性比對

4 結束語

本文定義了一套完整的CAN總線應用層協議及通信機制，克服了現有協議的不足。協議設置了優先級、源地址、目的地址等字段，支持多優先級、主從、多主等靈活通信方式；設置了組播標志，給出了組播、廣播地址分配及屏蔽策略，可根據信息流需求簡便的設置組播、廣播，簡化信息流設計；設置了幀序號標志、幀序號和數據場中的長度、校驗等信息定義，支持多幀數據的起始幀、結束幀和中間幀的連續性判斷，支持應用層數據包檢驗，支持CCSDS空間包及其他格式數據包可靠傳輸；設置了幀數據類型，定義了常用功能代碼，給用戶使用帶來方便。本文協議具有功能完善、適用范圍廣、靈活性高等優點，可進行推廣形成統一的航天器CAN總線協議。