一種航天器綜合電子系統業務及協議體系架構設計

何熊文

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

?

一種航天器綜合電子系統業務及協議體系架構設計

何熊文

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

對航天器綜合電子系統的通用功能需求進行分析，設計了基于空間數據系統咨詢委員會(CCSDS)標準和歐洲空間標準化合作組織(ECSS)標準的綜合電子系統業務及協議體系架構。體系架構包含應用層、應用支持層、傳送層和亞網層，可通過各層的業務及協議組合實現系統功能。從標準業務及協議的選擇過程、業務及協議體系架構設計、解決的關鍵技術問題等方面進行詳細闡述。該體系架構可為航天器的智能化和網絡化提供技術支撐，實現器載接口及協議的標準化，促進航天器設備和軟件的通用化，并為航天器提供更為靈活、強大的功能。

航天器綜合電子系統；空間通信協議；器載通信協議；器載接口業務

1 引言

隨著航天技術的不斷發展，用戶對航天器的易用性提出了新的需求。單個航天器的智能化程度也將逐步得到提升，實現自主任務規劃、自主決策、自主健康管理等工作，從而簡化器地操作接口，減輕地面操作人員的運控負擔，使得航天器的應用更加便捷。不同類型的航天器之間將逐漸實現聯網通信，實現不可視軌道段信息的快速下傳，以及多器協同工作等。上述智能化及網絡化的應用需求，需要一套標準化的業務及協議提供支撐，以形成覆蓋空間鏈路與器載鏈路的統一信息網絡服務。標準化的業務可以對各種智能化應用屏蔽底層鏈路及協議的不同，使應用可以專注于智能化相關算法的具體實現。層次化的協議可以實現空間網絡、器載網絡的互聯互通，支持協議的更換和擴展，以適應技術不斷發展的需要。作為航天器的信息處理和系統管理中樞，綜合電子系統是上述需求具體實現的主要載體，其業務及協議體系架構設計非常關鍵。

空間數據系統咨詢委員會(CCSDS)長期以來一直致力于空間數據系統的標準化工作，在空間通信協議[1]、器載通信協議[2]等方面發布了許多建議書，已在全球超過800個航天器中得到應用。歐洲空間標準化合作組織(ECSS)也在空間通信方面制定了一系列協議，例如用于標準化器地操作接口的遙控和遙測包應用標準(PUS)[3]，以及在美國軍用標準1553B總線協議上制定的ECSS 1553B總線通信協議[4]。中國現有航天器已逐步應用國際標準協議，例如在空間鏈路方面應用了遙控空間鏈路協議[5]、高級在軌系統(AOS)[6]、空間包協議[7]等，在器載鏈路方面應用了ECSS 1553B總線通信協議，以及SpaceWire總線協議。不過，航天器在鏈路層以上的協議制定差異性仍然較大，應用層與底層沒有進行良好的分層，而是直接與鏈路層交互。由于中間層的缺失，應用層的功能在具體實現時須要關注太多底層的協議，這樣既不利于航天器內部不同網絡間實現互聯互通，也不利于多個航天器之間的協同工作，而且對應的設備、器載軟件、地面測試軟件等都難以通用，不利于實現航天器的智能化、網絡化。

針對上述問題，本文重點研究在中國航天器中如何根據需求有選擇性地應用CCSDS標準和ECSS標準，建立標準化的業務及協議體系架構，形成統一的信息網絡服務，為航天器的智能化、網絡化提供技術基礎。

2 綜合電子系統業務及協議體系架構設計

綜合電子系統業務及協議體系架構的總體設計思路，是對綜合電子系統的通用功能需求進行分析，分解得到基礎性的業務，再對CCSDS標準和ECSS標準進行分析和選擇，將基礎性的業務及配套協議標準化，支持通過業務及協議的組合實現各功能，為智能化和網絡化提供技術支撐。

2.1 通用功能需求分析

通過對遙感、導航、通信、載人航天、深空探測等多個領域進行需求分析，可以歸納出綜合電子系統的通用需求包括7項頂層功能，分別為遙控、遙測、時間管理、內務管理、熱控管理、電源管理、解鎖與轉動機構控制。

(1)遙控是地面控制航天器的重要途徑，包括器地通信操作、實時指令分發、延時指令分發，為其他應用過程提供數據注入通道等。

(2)遙測是地面獲取航天器各種運行狀態數據及遙控操作結果的重要途徑，包括遙測采集、遙測組織、遙測下傳等功能。

(3)時間管理用于實現器地時間的同步，以及器內各設備之間的時間同步，包括集中校時、均勻校時、GPS校時、時間發布、時間碼產生等功能。

(4)內務管理用于實現對航天器的健康管理，包括器載參數監視、事件報告、事件動作、內存管理、在軌維護、重要數據保存與恢復、自測試、系統重構等功能。

(5)熱控管理包括開環控制、閉環控制、故障檢測及處置、熱控管理參數設置等功能。

(6)電源管理包括電源調節、功率分配、電量計控制、蓄電池組過溫保護等功能。

(7)解鎖與轉動機構控制包括火工品起爆控制，以及天線和太陽翼等帶機構部件的驅動控制等功能。

除了上述通用需求外，不同領域的航天器對綜合電子系統還有一些特殊需求，例如自主任務規劃功能、自主導航功能、器間路由功能、應急返回功能和環境控制管理功能等。

對上述通用功能進行分解可知，各頂層功能大多采用器地接口協議、器內各分系統之間的接口協議與地面或其他設備進行通信。同時，各功能也需要一些共性的業務，如遙控、內務管理、熱控管理、電源管理等都要發送指令，遙測、內務管理、熱控管理、電源管理都要獲取遙測數據進行判別。對于一些與智能化相關的功能，如自主任務規劃、自主決策等，也要獲取遙測及發送指令，且不同功能之間要進行消息通信，以實現協同。這些共性的業務及協議，可以通過標準化供各頂層功能使用，從而將頂層功能與底層的業務和協議實現良好的分離，使業務和協議達到各航天器通用的目的，便于未來實現航天器內設備的互連，以及不同航天器間的互連。

2.2 CCSDS標準和ECSS標準的分析和選擇

需求分析中涉及的遙測獲取、發送指令、消息通信、時間訪問等基礎功能，可以通過CCSDS等標準業務及協議實現，涉及到的CCSDS領域主要包括航天器器載接口業務(SOIS)領域、空間鏈路業務(SLS)領域、空間互聯網業務(SIS)領域。CCSDS SOIS定義的分層體系架構能有效屏蔽底層硬件變化對上層帶來的影響，并提供一組器內的標準化業務支撐上層應用。CCSDS SLS和CCSDS SIS領域的相關業務及協議，可提供器地及器間的通信業務。但是，CCSDS的上述領域重點關注底層的業務，對于頂層應用(如遙控、遙測、內務管理、時間管理、熱控管理、電源管理)支持較少，而ECSS的PUS標準定義了16類業務，將地面和航天器應用層級別的接口進行了標準化，且其業務可以通過組合滿足頂層應用的功能，是CCSDS標準的有效補充。ECSS 1553B協議可以結合CCSDS SOIS領域的亞網層業務，共同提供鏈路相關功能。

基于上述考慮，可將CCSDS SOIS、CCSDS SLS、CCSDS SIS領域的業務及協議與ECSS PUS、ECSS 1553B進行整合。具體到各領域而言，涉及的一些業務和協議還可進一步選擇，主要的一些考慮如下。

1)CCSDS空間通信協議的選擇

CCSDS空間通信協議由SLS領域及SIS領域各工作組開發，按照CCSDS空間通信協議參考模型，包含物理層、鏈路層、網絡層、傳輸層、應用層。

(1)物理層協議根據目前的需求可選擇射頻與調制系統協議與規范。

(2)鏈路層協議一共包括4種，分別為遙測空間鏈路協議、遙控空間鏈路協議、AOS空間鏈路協議、鄰近空間鏈路協議。由于AOS空間鏈路協議定義的業務覆蓋了遙測空間鏈路協議，因此在實際應用時遙測下行可直接應用AOS空間鏈路協議。上行遙控一般應用遙控空間鏈路協議，涉及到有圖像、話音上行的航天器(如空間站)時，也可應用AOS空間鏈路協議。鄰近空間鏈路協議主要用于軌道器和著陸器等的通信，暫未在軌應用。因此，在SLS領域中優先選用的鏈路層協議為遙控空間鏈路協議和AOS空間鏈路協議。

(3)網絡層協議包含空間包協議、封裝業務、IP協議等。空間包協議的優點是簡單，開銷小；缺點是地址空間少，不太適用于多航天器通信和航天器與地面網絡直接互聯。因此，目前可優先考慮應用空間包協議，后續將IP協議納入，以支持地面網絡擴展到空間。

(4)傳輸層協議包含空間通信協議規范-傳輸協議(SCPS-TP)、利克里德傳輸協議(LTP)、傳輸控制協議(TCP)、用戶數據報協議(UDP)等，目前可暫不應用，待后續需要時擴展。

(5)應用層協議包括文件傳輸協議(CFDP)、無損壓縮、圖像壓縮、束協議(BP)、異步消息傳輸業務(AMS)等。其中：AMS既可用于空間通信中的消息傳輸，也可用于器載通信，可實現空間、器內一體化通信，應優先采用，其他協議可在后續應用。

2)CCSDS器載通信協議的選擇

CCSDS器載通信協議主要由SOIS領域各工作組開發，按照CCSDS的SOIS器載參考模型，包含亞網層、傳送層、應用支持層，各層業務根據需求的不同有不同的應用場景及應用方法[8]。

(1)亞網層包含包業務、存儲器訪問業務、同步業務、設備發現業務、測試業務。包業務主要用于在一個器載鏈路上傳輸多種類型的包，存儲器訪問業務用于訪問設備內的存儲器或寄存器，同步業務可提供本地時間，這3個業務是底層必不可少的支撐性業務，因此全部采用。設備發現業務、測試業務可用于設備的即插即用，并不是必須的業務，可暫不采用。

(2)傳送層在SOIS模型中是可選的，但考慮到要將空間通信與器載通信進行融合，同時提供在多種鏈路上進行數據路由的機制，支持不同總線終端之間的設備遠程訪問、消息傳輸及遠程存儲器訪問，因此應采用。由于空間通信協議中應用的是空間包協議，此處也應用空間包協議。

(3)應用支持層在SOIS模型中包含命令與數據獲取業務、時間訪問業務、消息傳輸業務、文件及包存儲業務、設備枚舉業務。①命令與數據獲取業務由設備訪問業務、設備虛擬化業務、設備數據池業務組成，主要用于設備的數據獲取及指令發送。②時間訪問業務用于獲取器上時間。③消息傳輸業務用于航天器內部同一設備內不同應用程序之間、不同設備的應用程序之間的消息通信，使用AMS的子集實現。④文件及包存儲業務主要用于文件及包的管理。⑤設備枚舉業務主要用于即插即用。由于前三種業務涉及設備訪問、時間獲取、消息通信等所具備的基礎功能，因此全部采用。而文件管理和即插即用功能暫不涉及，因此暫不采用后兩種業務。

3)ECSS協議的選擇

ECSS PUS協議是CCSDS協議在應用層上的補充，ECSS 1553B協議是CCSDS協議在鏈路層上的補充，因此都予以采用,同時可根據需求對PUS業務進行選擇和裁剪[9]。

2.3 業務及協議體系架構設計

根據對需求以及標準的分析結果，本文設計的綜合電子系統業務及協議體系架構如圖1所示。

(1)應用層：包含遙測、遙控、熱控管理、電源電源管理、內務管理、時間管理、解鎖與轉動機構控制等頂層功能，可使用底層的業務組合實現。

(2)應用支持層：包含SOIS定義的設備訪問業務[10]、設備虛擬化業務[11]、設備數據池業務[12]、時間訪問業務[13]、消息傳輸業務[14]等，SIS定義的AMS[15]及ECSS PUS定義的標準業務。

(3)傳送層：一般只在有多個子網且子網間的應用程序需要相互通信時才使用，包括傳輸協議和網絡協議。此處使用空間包協議進行選路，并對空間包協議進行擴展，在其副導頭增加源/目的地址信息，未來可擴展支持UDP/IP等協議。

(4)亞網層：包含空間鏈路和器載鏈路，提供一系列業務供上層的傳送層和應用支持層業務調用。空間鏈路主要由上行遙控協議和通信操作規程-1(COP-1)協議[16]、下行AOS協議提供。器載鏈路包括包業務[17]、存儲器訪問業務[18]、同步業務[19]。對于每種鏈路，可通過相應的匯聚協議及數據鏈路層協議支持亞網層標準業務，從而對上層屏蔽底層鏈路的不同。目前，亞網層支持的鏈路包括1553B總線、串口、存儲器加載接口、串行數字量接口等。

2.4 解決的關鍵技術問題

在上述業務與協議體系結構設計中，主要解決了以下3個關鍵技術問題：①PUS業務與SOIS業務之間的關系；②SOIS業務之間的關系；③SOIS業務與底層硬件之間的關系。

2.4.1 PUS業務與SOIS業務之間的關系

PUS業務可使用SOIS應用支持層業務作為支撐業務，其自身更關注于算法處理。對SOIS業務的主要用法為：①利用設備數據池業務完成數據的采集；②利用設備虛擬化業務完成設備指令的發送；③利用消息傳輸業務完成包的分發；④利用時間訪問業務完成器上時間的獲取。例如：PUS器載監視業務可使用設備數據池業務完成被監視參數的采集；PUS器載操作調度業務使用時間訪問業務完成器上時間的獲取，通過消息傳輸業務將滿足發送時間要求的遙控包發送到目的地；PUS設備指令分發業務使用設備虛擬化業務完成開關指令、存儲器加載指令的分發等。

對照組患者采用常規腦出血治療,依據患者影像診斷采用常規治療,采用醒腦注射液治療,并且作止血、防感染操作。

通過對每項PUS業務進行數據流分析，將其算法與SOIS業務的關系利用數據流的方式描述，可依次得出每個PUS業務與所需的SOIS業務之間的接口關系。

2.4.2 SOIS業務之間的關系

通過全局的命名機制可建立SOIS各業務之間的映射關系，其層次關系如圖2所示。

圖2中比較核心的命名主要包括節點ID、虛擬設備ID、物理設備ID、應用過程標識(APID)、鏈路標識、亞網地址、存儲器區域等，具體的命名方法如下。

(1)對每個應用過程可以分配一個節點ID，用于消息傳輸業務；

(2)對每個設備分配一個物理設備ID，設備的主份及備份分別有一個物理設備ID，但可通過一個虛擬設備ID進行標識；

(3)通過物理值ID或虛擬值ID區分設備中的一個參數或者發往設備的一條指令；

(4)對APID進行分段設計，使之既可以標識設備，也可以標識設備內的應用過程；

(5)對每條鏈路分配一個鏈路標識，鏈路上的每個終端分配一個亞網地址；

(6)通過存儲器區域標識存儲設備中的某一塊存儲區域。

上述命名的尋址方法為：

(1)在消息傳輸業務中可依據節點ID查表得到節點對應的APID；

(2)在設備訪問業務中可依據物理設備ID查表得到要訪問的設備APID以及底層所需業務，當對應的設備須采用底層的存儲器訪問業務時，通過物理設備ID和物理值ID查表可進一步得到對應的存儲器區域和起始地址；

(3)在空間包協議中可依據APID查表得到設備的鏈路標識和亞網地址；

(4)在包業務中通過鏈路標識可以查表得到對應的鏈路，通過亞網地址可以查表得到對應的鏈路地址；

(5)在存儲器訪問業務中，由存儲器區域可找到對應的設備名，便于通過驅動程序訪問設備。

依據上述尋址方法以及各業務的功能流程，可建立各層業務之間的關系。

2.4.3 SOIS業務與底層硬件之間的關系

通過SOIS亞網層的業務可屏蔽底層鏈路以及硬件的不同，對上層提供統一的接口，其中匯聚層及設備驅動程序起著關鍵的作用。

(1)對每個支持包業務的鏈路設計專門的匯聚協議及接口，使之支持包的傳輸，同時對鏈路的硬件接口設計配套的設備驅動程序，建立匯聚協議與驅動程序之間的聯系，從而可打通包業務、匯聚協議、驅動程序之間的接口，對上層提供包傳輸功能，達到鏈路更換不影響上層業務的效果。

(2)對于通過存儲器訪問業務訪問的本地設備，同樣設計配套的設備驅動程序，將存儲器訪問業務與設備驅動程序建立聯系，使上層通過統一的接口對設備進行訪問。

(3)對于同步業務，可將其與本地的時鐘設備驅動程序建立聯系，完成時間的獲取功能。

上述做法解決了SOIS亞網層業務與底層硬件之間的接口問題，在應用支持層可通過前面的命名與尋址方法將消息傳輸業務、設備訪問業務等與底層亞網層的業務結合，提供更高級別的設備抽象。

2.5 頂層功能與業務及協議的對應關系

各頂層功能可以通過架構中的業務及協議組合實現，對每項頂層功能進行數據流分析后，可得到頂層功能與業務及協議的對應關系如表1所示。其他擴展功能(如自主任務規劃)也可以應用本體系架構設計的業務及協議，加上應用特定的算法予以實現。

表1 頂層功能與業務及協議的對應關系Table 1 Relationship of top-level function with services and protocols

3 應用效果

為了驗證上述業務及協議體系架構設計的可行性，本文將架構中應用層以下的各業務及協議，全部采用軟件構件予以實現，并根據綜合電子系統硬件平臺的需求進行組裝以及測試驗證。多項測試用例的設計及驗證表明，應用本文設計的業務及協議體系架構，與傳統航天器相比，可提供更加豐富、實用、強大的功能，主要體現在如下幾個方面。

1)數據傳輸機制更為靈活

傳統航天器通過串行數據接口進行數據傳送時，其傳送的時間間隔、數據長度、傳送目的地大都是固定的，難以靈活變化。而在本文的體系結構中應用CCSDS的空間包協議、SOIS亞網層包業務及匯聚層，系統支持串行數據接口傳送的時間間隔由用戶按需控制，傳送的數據長度及目的地實現按需傳送。平臺和載荷設備可通過任意一個串行數據接口接入，數據可以是原始數據或者空間包格式數據。當數據為原始數據時，系統可通過預先配置，將原始數據進行打包處理，然后再進行路由。當數據為標準的空間包格式數據時，用戶可以選擇合適的長度，以及不同的目的地，系統可對數據的目的地進行自動識別，并根據系統的路由策略將數據路由到其目的地，例如其他器載設備、其他航天器或者地面。上述機制可顯著提高系統的靈活性、可擴展性。

2)支持接口更換，不影響上層應用軟件

傳統航天器通過某個接口進行數據傳送時，如果更換了接口，航天器一般須要進行軟件的修改，重新進行數據的設置。在本文的體系結構中應用CCSDS的空間包協議、SOIS亞網層包業務以及匯聚層，用戶可以通過不同的接口接入系統。即使用戶改變接入接口，例如由串行數據接口變為1553B總線接口、串口或其他接口，只要設定好目的地，系統即可根據目的地自動路由。該機制相當于即插即用的初級階段，在后續加入設備自動識別機制后，可進一步提升即插即用的能力。

3)支持系統計算能力的按需擴展

在本文的體系結構中，應用CCSDS的消息傳輸業務、設備訪問業務、設備虛擬化業務、設備數據池業務，與底層空間包協議、亞網層包業務及匯聚層配合后，在底層硬件的支持下，可實現處理器數量的靈活擴展。當一個處理器的計算能力不夠時，可以通過增加處理器模塊的數量實現任務的遷移，并進行分布式計算，從而增強系統的整體計算能力。在這個過程中，不同處理器之間的數據傳輸全部通過消息傳輸業務完成，并根據通信雙方位置的不同采用不同的業務。

(1)當同一個處理器模塊內部的進程之間通信時，消息傳輸業務通過本地緩沖區完成消息的交換；

(2)當一個設備內的處理器模塊之間的進程進行通信時，消息傳輸業務經由傳送層、亞網層包業務、內總線匯聚層完成數據傳輸；

(3)當通過1553B總線連接的2個設備內的進程進行通信時，消息傳輸業務經由傳送層、亞網層包業務、1553B總線匯聚層完成數據傳輸。

通過這種方式，可以對應用層完全屏蔽底層鏈路的不同，從而方便應用程序的開發。

4)系統上下行支持標準化的大塊數據傳輸

在本文的體系結構中，應用CCSDS的遙控協議、AOS協議、COP-1協議、空間包協議、亞網層包業務、匯聚層，為地面用戶提供標準化的傳輸機制。用戶可以一次性地將上注數據組成最大65 542 byte的空間包，交由遙控協議進行自動分段，并按照COP-1協議對幀的傳送結果進行自動確認，這樣既可以提供對用戶的友好界面，又可以大幅提升上注效率，從而避免了以往的兩大弊端：①需要人工將大數據包拆分為多個小數據包，分別計算出注入地址后逐個上注，處理繁復；②在每注一幀后，等待遙測下行確認注入正確，才能上注下一幀，效率很低。此外，通過傳送層將空間通信與器內通信互聯，這樣發往其他目的地的數據可以由傳送層直接進行路由，無須提交到上層，并且可以實現在多種物理鏈路上進行路由。

5)支持業務組合實現系統功能

在本文的體系結構中，各功能可以通過多種業務的組合實現。例如：遙測功能中的遙測采集可以利用設備數據池業務，經由設備訪問業務或設備虛擬化業務、空間包協議、亞網層包業務或亞網層存儲器訪問業務獲取設備的數據。遙測的組織可利用ECSS PUS常規/診斷參數報告業務產生遙測包。遙測下傳可應用AOS協議完成幀組織及虛擬信道調度，經由硬件傳送至地面。上述基礎業務將為系統各項功能的開發提供極大的便利，后續的其他智能化功能也可基于上述基礎業務開發，促進器載軟件的重用，并減少用戶的開發工作量。

4 結束語

本文提出的航天器綜合電子系統業務及協議體系架構，充分吸納了CCSDS標準和ECSS標準的最新成果，應用該體系架構開展航天器空間通信協議及器載通信協議的設計，將有助于實現器地/器間操作接口的標準化，以及器內各分系統之間接口的標準化，為后續航天器的智能化、網絡化提供有力的支撐。

隨著對天地一體化需求的深入論證，對于地面協議如何與航天器協議進行融合還有待進一步研究。空間包協議由于地址的受限且與地面協議難以兼容，無法作為器間、器地、器內的互聯協議。目前，一種可能的方式是通過IP協議將空間通信協議與地面互聯網協議融合，同時針對空間鏈路高動態、長延時及可能中斷的特性，將容忍延遲網絡(DTN)協議加入，形成天地一體化的協議體系。其中，網絡路由算法、協議轉換、網絡管理、信息安全等還有待進一步研究。

References)

[1] CCSDS. CCSDS 130.0-G-3 Overview of space communications protocols [S]. Washington D.C.: CCSDS, 2014

[2]CCSDS. CCSDS 850.0-G-2 Spacecraft onboard interface services [S]. Washington D.C.: CCSDS,2013

[3]European Cooperation for Space Standardization. ECSS-E-70-41A Space engineering: ground systems and operations-telemetry and telecommand packet utilization [S]. Noordwijk: ECSS,2003

[4]European Cooperation for Space Standardization．ECSS-E-ST-50-13C Space engineering: interface and communication protocol for MIL-STD-1553B data bus on board spacecraft [S]． Noordwijk： ECSS,2008

[5]CCSDS. CCSDS 232.0-B-3 TC space data link protocol [S]. Washington D.C.: CCSDS,2015

[6]CCSDS. CCSDS 732.0-B-3 AOS space data link protocol [S].Washington D.C.: CCSDS,2015

[7]CCSDS. CCSDS 133.0-B-1 Space packet protocol [S]. Washington D.C.: CCSDS,2003

[8]何熊文,朱劍冰,程博文，等.星載標準接口業務在航天器中的應用方法[J].航天器工程,2015,24(6):52-58

He Xiongwen,Zhu Jianbing,Chen Bowen,et al. Application method of spacecraft onboard interface services in spacecraft [J]. Spacecraft Engineering,2015,24(6): 52-58 (in Chinese)

[9]何熊文,張猛.遙控和遙測包應用標準在航天器中的應用方法[J].航天器工程，2012，21(3)：54-60

He Xiongwen,Zhang Meng. Application method of telemetry and telecommand packet utilization standard in spacecraft [J]. Spacecraft Engineering,2012,21(3): 54-60 (in Chinese)

[10]CCSDS. CCSDS 871.0-M-1 Spacecraft onboard interface services-device access service [S]. Washington D.C.: CCSDS,2013

[11]CCSDS. CCSDS 871.2-M-1 Spacecraft onboard interface services-device virtualization service [S]. Washington D.C.: CCSDS,2014

[12]CCSDS. CCSDS 871.1-M-1 Spacecraft onboard interface services-device data pooling service [S]. Washington D.C.: CCSDS,2012

[13]CCSDS. CCSDS 872.0-M-1 Spacecraft onboard interface services-time access service [S]. Washington D.C.: CCSDS,2012

[14]CCSDS. CCSDS 875.0-M-1 Spacecraft onboard interface services-message transfer service [S]. Washington D.C.: CCSDS,2012

[15]CCSDS.CCSDS 735.1-B-1 Asynchronous message service [S]. Washington D.C.: CCSDS,2011

[16]CCSDS. CCSDS 232.1-B-2 Communications operation procedure-1 [S]. Washington D.C.: CCSDS,2010

[17]CCSDS. CCSDS 851.0-M-1 Spacecraft onboard interface services-subnetwork packet service [S]. Washington D.C.: CCSDS,2009

[18]CCSDS. CCSDS 852.0-M-1 Spacecraft onboard interface services-subnetwork memory access service [S]. Washington D.C.: CCSDS,2009

[19]CCSDS. CCSDS 853.0-M-1 Spacecraft onboard inter-face services-subnetwork synchronisation service [S]. Washington D.C.: CCSDS,2009

(編輯：夏光)

Service and Protocol Architecture Design of Spacecraft Avionics System

HE Xiongwen

(Beijing Institute of Spacecraft System Engineering,Beijing 100094,China)

Common functional requirements of spacecraft avionics system are analyzed and a service and protocol architecture based on CCSDS standard and ECSS standard has been designed. The architecture consists of 4 layers，including application layer，application support layer，transfer layer，subnetwork layer. The service and protocol of each layer can be combined to implement system functions. The detailed description of the architecture is given,including selection process of the standard services and protocols,service and protocol architecture design,and key technical issues solved. Application of the architecture shows that the architecture can provide the technical support for spacecraft intelligentization and network service,benefit the standardization of onboard interface and protocols as well as the universal use of devices and software on board,and provide more flexible and powerful function.

spacecraft avionics system；space communication protocol； onboard communication protocol； onboard interface service

2016-07-06；

2016-12-01

何熊文，男，高級工程師，從事星載綜合電子系統協議設計和軟件開發工作。Email：hexw501@hotmail.com。

V446.4

A

10.3969/j.issn.1673-8748.2017.01.011