基于SmartFusion2 的星載CAN 總線設計與實現

陳世淼，倪淑燕，廖育榮，劉曉輝

（1.航天工程大學研究生院，北京 101407；2.航天工程大學電子與光學工程系，北京 101407）

隨著電子科學技術的進步，衛星正在逐漸往小型化、集成化和模塊化方向發展，具有體積小、重量輕、性能高等特點的微小衛星應運而生[1-2]。隨著航天任務復雜度的增加以及人們對微小衛星性能要求的提高，微小衛星軟硬件設計的復雜性也在逐漸增加[3]，星載綜合電子系統作為微小衛星系統的核心，對微小衛星的性能有著重大的影響。星載計算機是星載綜合電子系統平臺信息處理和交互的樞紐，能夠完成衛星在軌運行段的控制計算以及全程任務管理。

針對以上問題和現狀，提出了一種基于SmartFusion2芯片的星載CAN 總線設計方案。SmartFusion2 是一種將ARM 和FPGA 結合的處理器，具有高安全性、高可靠性和低功耗的優點[4-6]，通過其FPGA 的強大功能可以完成復雜系統的設計和實現，可以極大地提高微小衛星的功能密度和適應性[7-8]。微小衛星內部總線的設計原則是可靠、穩定、高實時性。CAN 總線具有強抗干擾性、高實時性、高傳輸速率和低成本的優點，從二十一世紀初便被廣泛應用在航天領域，技術相對比較成熟。所以該文基于SmartFusion2 芯片，采用CAN 總線作為星載綜合電子系統的通信總線，針對星務姿控一體化進行了兩級總線雙冗余設計，提高了總線通信的安全性和穩定性，簡化了星務軟件中的數據處理設計，減少了衛星的功耗。

1 系統設計

微小衛星綜合電子系統一般由星務管理分系統、姿控分系統、電源分系統、測控數傳分系統、GNSS 分系統和載荷分系統組成，其中星務管理分系統和姿控分系統是微小衛星綜合電子系統中最為重要的兩個分系統[9-10]。由于衛星設計的分工和一體化設計具有很高的復雜性，傳統方法將這兩個分系統作獨立設計，其中共同點是都含有星載計算機和對應的軟件。但是這種設計不僅浪費硬件資源，增大數據傳輸量，而且增加衛星質量，加大功耗[11]。針對星務姿控一體化設計的星載綜合電子系統進行了CAN 總線通信設計，通信架構如圖1 所示。

圖1 通信架構

一級總線用于連接與星務分系統相關的載荷、GNSS、測控數傳一體機和電源分系統，傳輸的數據主要為其他分系統的遙測遙控數據；二級總線用于連接飛輪、星敏、太敏、陀螺和磁強計等姿控部組件，傳輸的數據為各個姿控部組件的遙測遙控數據，兩者的數據類型、采集數據的周期以及數據的處理均有較大差別，所以采用兩級總線設計。兩級總線的設計減少了單個總線的數據處理量，有效提高了衛星總線的在軌壽命[12]。

為了提高微小衛星綜合電子系統的穩定性和安全性，在使用兩級總線的同時進行了雙冗余總線設計。目前雙總線的仲裁機制主要分為總線切換和雙收雙發兩種?？偩€切換機制將CAN 總線分為工作總線和備用總線，當工作總線故障時自動啟動備用總線完成通信[13]；而雙收雙發機制則是利用兩條冗余CAN 總線同時傳送相同的數據[14]。采用第二種方法會增加星載綜合電子系統的數據傳輸量，所以該設計采用的是總線切換機制。

該設計選擇的M2S050TS-1FGG484 處理器是采用ACTEL 的第四代65 工藝的片上系統產品：基于flash 架構，能夠滿足工業、軍事、航空、通信和醫療領域的高安全性、高可靠性和低功耗的片上SoC 系統。處理器由FPGA 和ARM 內核——Cortex-M3 組成，處理速度塊，可擴展性強。并且SmartFusion2 片上系統芯片被廣泛應用于軍工和航空領域，歐洲空中客車公司A380 大型客機上采用了大量Smart Fusion2（每架超過1 000 只）。該產品不在美國公禁運之列，所以可采購到軍級產品，適合用于衛星。并且該處理器在國防科大微納衛星天拓三號上進行了應用，已在軌飛行2.5 年，在軌運行穩定可靠。

目前，CAN 總線節點的硬件構成主要包括兩種：一種是通過MCU 控制器連接獨立的CAN 控制器，另一種是MCU 控制器本身帶有CAN 控制器。M2S050TS-1FGG484 處理器的ARM 核帶有獨立的CAN 控制器，文中又通過FPGA 實現了3 個SJA1000的擴展[15-16]。SJA1000 的IP 核設計與實現通過Libero軟件完成。

2 通信原理協議

根據OSI網絡模型，CAN 現場總線定義了物理層和數據鏈路層。在實際設計中，這兩層完全由硬件來實現，設計人員無需為此開發相關軟件或固件。而在應用中，CAN 總線是以報文為單位進行數據傳送的，故只需規定一個高層協議來定義CAN報文中的11/29位（具有11位標識符的幀稱為標準幀，具有29位標識符的幀稱為擴展幀）標識符以及8B 數據的使用即可，這些信息均包含在CAN的報文幀內。目前，應用較多的是CAN2.0A規范，CAN報文采用的是標準幀。但是隨著星務管理的復雜化，信息傳輸量越來越大，僅含有11位標識符的標準幀將難以滿足需求，所以該設計數據幀采用的是CAN2.0B 規范中的擴展幀格式。擴展幀的仲裁域含有29個二進制位，包括設備識別協議和數據傳輸協議兩種類型。仲裁域的定義方式如圖2所示。對該設計CAN通信中主要用到的設備識別協議、數據傳輸協議和網絡傳輸協議介紹如下。

圖2 仲裁域格式

2.1 設備識別協議

設備識別過程中用到的是設備識別廣播幀、設備識別申請幀和設備識別允許幀，如圖3 所示。設備的oID 是設備唯一識別碼，包括生產方編號、設備類型號、出廠序號和保留部分，主要用于服務器對下位機的識別。每個設備有且僅有一個設備唯一識別碼，且不同設備的設備唯一識別碼不得相同。nID 是設備的網絡通信識別碼，在設備的識別過程中由服務器分配給下位機，用于之后信息傳輸的設備識別。nID 長度為一個字節，并且數值越小優先級越高。

圖3 設備識別幀格式

CAN 總線的設備識別過程有兩種，一種是由服務器發起的設備識別過程，另一種是由被識別節點所申請的設備識別過程。第一種識別過程應用在設備識別服務器（上位機）上電或復位后，首先，由服務器向總線上發送設備識別廣播幀，未被識別的設備接收到設備識別廣播幀后將發送設備識別申請幀，服務器接收到設備識別申請幀后，通用設備識別允許幀分配相應的nID，完成設備識別。第二種識別過程應用在被識別設備上電或復位后，首先，由待識別設備每秒定時發送設備識別申請幀，服務器接收到設備識別申請幀后，通過設備識別允許幀分配nID，完成設備識別。

2.2 數據傳輸協議

數據傳輸過程中主要用到數據傳輸首幀、數據傳輸中間幀、數據傳輸尾幀和數據接收確認幀，其幀格式如圖4 所示。協議控制碼為00B 時，表示數據幀發送時需要回復確認幀，01B 表示數據幀發送時，不需要回復，10B 表示數據接收確認幀標識。接收地址為FFH 時，為廣播傳輸數據。當數據進行多幀數據傳輸時，必須按照幀序號依次發送，設置首幀的幀序號為00H，中間幀的幀序號依次遞增，尾幀幀序號為FFH。數據區按照順序填寫根據網絡傳輸協議制定的數據，數據不足8 字節時填充AAH。如果需要回復確認幀，則事件接收方在接收到每一幀數據后都需要回復一幀數據確認幀。

圖4 數據傳輸幀格式

2.3 網絡傳輸協議

網絡傳輸協議提供統一通用數據傳輸包格式，首部格式固定，包括傳輸協議、包長度、源地址和目標地址等。CAN 總線進行數據傳輸時每8 個字節為一組，與仲裁域共同構成一幀，進行數據傳輸，不足8 字節時用AAH 進行填充。網絡傳輸首部字節分配如圖5 所示。

圖5 網絡首部字節分配

根據傳輸數據首部中傳輸協議的不同，可以實現信息傳遞服務、時間傳輸服務、在軌快速測試服務、文件傳輸服務、設備驅動服務、遙測傳輸協議、遙控傳輸協議等功能。

3 應用層軟件

CAN 總線函數通過主控制器Cortex-M3 設置的C 語言編寫，基于μC/OSⅡ操作系統，在Keil uVision4集成開發環境中完成。

3.1 基本函數

CAN 通信的基本函數主要包括初始化函數、組幀函數、發送函數、中斷函數、接收函數。初始化函數主要用于設置CAN 通信的波特率、工作模式和濾波器等，主要應用于軟件的初始化階段。組幀函數用于將要發送的數據組成數據幀，數據幀包括29 位的仲裁域和8 個字節的數據域。發送函數用于將組幀函數產生的數據幀發送到CAN 總線上的目標下位機。中斷函數在檢測到總線上的數據后進入中斷模式，然后調用CAN 總線的數據接收函數，最后完成數據接收后清除中斷。接收函數用于接收CAN總線上下位機發送的數據，并且根據數據的仲裁域和首部將數據儲存在相應的數據緩沖區中。由于該設計中的CAN 總線由處理器自帶的CAN 控制器和SJA1000 擴展的CAN 控制器組成，所以要進行兩種CAN 控制器的函數設計。

3.2 nID分配

星載計算機開機后，首先進行系統初始化，然后調用發送函數發送設備識別廣播幀。下位機在收到設備識別廣播幀后會發送設備識別申請幀，從而觸發中斷函數，最終調用接收函數對幀類型進行判斷和處理。若接收幀為設備識別廣播幀，則發送信號量來觸發主函數中的nID 發送任務。nID 發送任務根據設備識別廣播幀中的oID 來發送相應的設備識別允許幀，從而完成nID 的分配。此外下位機斷電重啟后也會進行nID 的分配。

3.3 應答數據處理

nID 識別完成后，軟件內部的計時器模塊以1 s為周期發送信號量，觸發輪詢指令發送任務，星載計算機通過CAN 總線向各部組件發送輪詢指令。在星載計算機接收到部組件的應答數據后，進入CAN 總線中斷函數，根據數據的nID 將數據存儲在相應的數據緩沖區中。在接收到數據的尾幀后，發送信號量觸發數據處理任務，星載計算機根據部組件的協議從應答數據中提取有效數據，用于后續處理，軟件主流程如圖6 所示。該設計設置了故障標志位，根據數據接收過程中出現的故障來設置不同的標志，實現了故障判別功能。故障類型包括首部校驗和未通過、數據接收未完成和數據幀不連續。

圖6 軟件主流程

4 通信測試

該設計將星載計算機和實時仿真機連接，搭建半實物仿真系統。實時仿真機能夠模擬部組件的真實通信狀況，適用于驗證該設計的合理性。在測試的過程中，實時仿真機模擬4 個飛輪、兩個太敏、一個太敏和一個磁強計的在軌運行狀態，通過CANTest 軟件、串口調試助手和Keil進行調試和驗證。

當星載計算機和實時仿真機通電后，實時仿真機發送nID 申請幀，星載計算機收到nID 申請幀之后發送nID 確認幀；星載計算機以1 s 為周期發送部組件輪詢指令，實時仿真機接收到輪詢指令后回復應答數據；星載計算機接收到應答數據后進行數據幀的nID 識別，將不同的部組件數據儲存在相應的數據緩沖區，進行數據的處理，數據處理成功通過地測口打印數據處理成功標識。從CANTest 軟件可以看出，CAN 總線上的數據與軟件設計預期一致，nID 的識別過程如圖7 所示。輪詢幀和應答幀數目較多，不在文中進行展示，星載計算機在接收到部組件應答幀數據后通過地測口打印數據處理成功標識，由圖8 可以看出星載計算機成功接收并處理了部組件數據。通過Keil 軟件監測部組件數據存儲區可以看出，星載計算機接收到應答數據后成功進行了解析，此時故障標志位（InvalidFlag）為0x00，表示數據處理成功?？刂茖崟r仿真機發送錯誤的應答數據幀后，此時故障標志位變為0x01，表示數據接收未完成，實時反饋了錯誤類型，測試結果如圖9 和圖10 所示。

圖7 nID識別過程

圖8 串口助手接收數據

圖9 數據接收正常

圖10 數據接收故障

測試結果表明，文中設計的CAN 總線通信系統可以準確地進行nID 的識別、輪詢指令的傳輸和部組件數據的接收和處理，具有定期輪詢、故障判斷功能，實現了星載計算機與部組件通信的目的，滿足了設計需求。

5 結論

在綜合考慮星載綜合電子系統相關因素的基礎上，基于SmartFusion2 芯片進行了CAN 控制器的硬件和架構設計，完成了CAN 通信協議的制訂，并進行了通信軟件的開發，實現了星務姿控一體化的星載CAN 通信設計。該設計通過SmartFusion2 芯片的FPGA 模塊實現了CAN 總線的擴展，在ARM 內核上運行星務軟件，提升了衛星運算處理能力，提高了衛星功能密度；兩級雙冗余總線架構的設計在提高衛星總線壽命的同時提升了系統的穩定性和安全性。測試結果驗證了該設計中總線的硬件、軟件和協議設計的合理性和有效性，滿足星務姿控一體化衛星的通信任務需求，具有較強的工程應用價值。