一種基于星內(nèi)路由的航天器數(shù)管軟件框架設計

張亞航 袁珺 于俊慧 鄭國成

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

?

一種基于星內(nèi)路由的航天器數(shù)管軟件框架設計

張亞航 袁珺 于俊慧 鄭國成

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

傳統(tǒng)航天器數(shù)管分系統(tǒng)開發(fā)時，往往需要深入分析各類傳輸協(xié)議細節(jié)，對協(xié)議數(shù)據(jù)的格式處理、數(shù)據(jù)轉換等功能需要占用大量的開發(fā)時間。文章提出了一種基于星內(nèi)路由的數(shù)管軟件框架，其遙測鏈路協(xié)議(AOS Link)、遙控鏈路協(xié)議(TC Link)和星內(nèi)總線鏈路協(xié)議(1553B Link)等鏈路層協(xié)議都由網(wǎng)絡層路由接管，并以軟件構件的形式存在。星載數(shù)管應用層程序在對數(shù)據(jù)進行收發(fā)時，僅僅調(diào)用網(wǎng)絡層“發(fā)送”和“接收”接口即可，而后臺路由程序?qū)⒏鶕?jù)路由表選擇鏈路層協(xié)議下一跳地址和對應的傳輸服務，實現(xiàn)地面、數(shù)管系統(tǒng)和其他分系統(tǒng)之間的數(shù)據(jù)流轉。該框架將底層通信和應用層功能嚴格分離，大幅度簡化了應用層軟件設計。

航天器；數(shù)管分系統(tǒng)；路由；軟件框架

1 引言

隨著航天任務的發(fā)展，星載計算機處理速度越來越快；與此同時，星載軟件處理的任務也越來越復雜，軟件系統(tǒng)規(guī)模也越來越龐大。面對更加復雜的需求，星載軟件研制者不斷借鑒國外航天器靈活的協(xié)議和體制(例如空間數(shù)據(jù)系統(tǒng)咨詢委員會CCSDS相關標準和協(xié)議[1-4]和歐洲標準化合作組織ECSS的1553B協(xié)議標準[5])，不斷探索星載軟件構件[6-7]、航天器自主任務管理[8]等新型技術。

傳統(tǒng)航天器在傳輸協(xié)議的實現(xiàn)方面，往往深入?yún)f(xié)議細節(jié)，協(xié)議數(shù)據(jù)的格式處理、數(shù)據(jù)轉換等功能需要占用開發(fā)的大量精力。同時這種體系結構雖然具備分層的協(xié)議，但是實際軟件中，應用程序和協(xié)議處理程序相互糾纏，難以剝離。

隨著星上不同分系統(tǒng)和單機之間的數(shù)據(jù)交互越來越頻繁，星地之間操作頻繁，星間和星內(nèi)傳輸協(xié)議的復雜性也大幅度提高。以時間同步1553B總線通信協(xié)議標準[5]為例，這種通信協(xié)議總共提供多達11種類型的業(yè)務，其中常用的業(yè)務也有6～7種。如果每個航天器任務的研發(fā)者都需要對各種協(xié)議學習、開發(fā)和測試，一則工作量太大，難以接受；二則協(xié)議軟件和應用軟件耦合度太高，軟件的復雜性增加，可靠性難以控制。

在這種背景下，本文提出了一種基于星內(nèi)路由的星務軟件分層體系結構，其中AOS Link，TC Link和1553B Link等鏈路層協(xié)議都由網(wǎng)絡層路由接管，并以軟件構件的形式存在。航天器型號軟件開發(fā)者僅僅需要在程序入口處將需要傳輸?shù)臄?shù)據(jù)放入空間包構件的Send函數(shù)中，則路由程序?qū)⒏鶕?jù)路由表下層鏈路協(xié)議和業(yè)務的選擇，實現(xiàn)數(shù)據(jù)轉發(fā)至地面或其他分系統(tǒng)單機。這種軟件體系結構，已經(jīng)在遙感敏捷平臺等航天器上成功得到應用，并計劃在后續(xù)型號中應用。

2 軟件體系結構

在研究構件化綜合電子軟件體系之前，首先需要明確什么是軟件體系結構。許多學者從不同角度對軟件體系結構的定義進行了不同的描述[9-11]。盡管這些定義各有側重，但其核心內(nèi)容都是軟件系統(tǒng)結構，并蘊含構件、構件之間的關系、構件和連接件之間的關系。本文引用其中最為廣泛接受的定義(IEEE 610.12-1990軟件工程標準詞匯定義)[10]：

體系結構是以構件、構件之間的關系、構件與環(huán)境之間的關系為內(nèi)容的某一系統(tǒng)的基本組織以及指導上述內(nèi)容的設計與演化的原理，即

軟件體系結構 ={構件，連接件，環(huán)境，原理}。

2.1 傳統(tǒng)遙感衛(wèi)星軟件體系結構

傳統(tǒng)遙感衛(wèi)星中，軟件一般以進程的形式分為多個模塊。進程之間一般以消息通信和全局變量的方式進行交互，尤其是后者。典型的功能劃分如下：

(1)遙控相關的數(shù)據(jù)處理和傳輸，其軟件實現(xiàn)融入在遙控相關進程里面，例如TcRecv進程負責遙控格式檢查和校驗，CmdRealHandle進程負責實時指令分發(fā)，CmdDelayHandle進程負責延時指令分發(fā)。

(2)遙測相關的數(shù)據(jù)處理和傳輸，其軟件實現(xiàn)融入在遙測相關進程里面，例如TmOrgDown進程負責遙測采集、組包、組幀、信道調(diào)度和下行。

(3)總線相關的數(shù)據(jù)處理和傳輸，其軟件實現(xiàn)融入在數(shù)據(jù)處理和內(nèi)務管理相關進程中，例如DataService負責總線數(shù)據(jù)處理，HouseKeeping負責處理一些內(nèi)務相關的指令發(fā)送。

以遙測功能為例，如圖1所示。

這種體系結構的好處在于，能夠根據(jù)傳統(tǒng)航天器的設計思想，相對獨立劃分各個功能模塊，并由不同的工程師完成。但是缺點也很明顯：

(1)由于負責通信的功能部分代碼和進程的功能揉合在一起，因此其他功能模塊如果需要傳遞數(shù)據(jù)，則往往需要調(diào)用另外進程的函數(shù)，因此進程與進程之間耦合度較高。

(2)應用程序的編寫者，同時也負責通信協(xié)議的設計和實現(xiàn)。因此負責具有通信功能的模塊編寫者任務很重，這也是傳統(tǒng)航天器遙測功能的編寫者由負責軟件的副主任設計師擔任的原因。

采用星載軟件構件技術可以一定程度上減輕以上問題[6-7]，大幅度降低程序模塊間耦合，提高復用程度，減輕研制工程師的負擔。但是一般來說，仍然要求有數(shù)據(jù)傳輸需求的應用程序詳細了解各個協(xié)議構件所提供的服務。為了真正實現(xiàn)“傻瓜式”數(shù)據(jù)通信，需要改變現(xiàn)有的軟件體系結構，建立分層的通信體系。

圖1 傳統(tǒng)星載軟件遙測模塊處理流程和結構Fig.1 TM module process and structure of traditional onboard software

2.2 基于星內(nèi)路由的數(shù)管軟件分層體系結構

2.2.1 分層軟件體系結構

一般來說，現(xiàn)有軟件體系結構包括4個層次，包括應用層、構件層、操作系統(tǒng)和驅(qū)動層、物理層等，如圖2所示。

注：①構件本身也能夠包含更底層的構件，但是在本體系結構中不反映。②本圖主要描述軟件體系的層次結構，而協(xié)議的分層結構，則主要封裝在其中的路由模塊中。圖2 新型數(shù)管系統(tǒng)分層軟件體系結構Fig.2 Multilayered software architecture of new OBDH system

(1)第一層是各個應用過程：實現(xiàn)了與需求相關的各個功能。其中，各個進程之間不存在直接的調(diào)用關系，以降低進程間的耦合，保持各個模塊的獨立性。

(2)第二層是構件或中間件：本層各個模塊必須嚴格保證是獨立存在的個體(具體來說，就是能夠獨立編譯)，其向上提供應用接口，并隱藏自身細節(jié)，以提供其他應用進程使用。

(3)第三層是所有封裝好設備的驅(qū)動和操作系統(tǒng)：負責進程調(diào)度、硬件操作和資源管理。

(4)第四層是物理層：物理的硬件設備。

2.2.2 通信協(xié)議拓撲結構

在既有的軟件構件基礎之上，建立了基于路由的體系結構，圖3以遙測進程與路由進程的通信為例，將該數(shù)據(jù)的拓撲結構進行了說明。

圖3 基于路由的協(xié)議分層體系結構Fig.3 Multilayered protocol architecture based on router

在這種體系中應用程序?qū)?shù)據(jù)包的接收和發(fā)送操作僅僅需要將數(shù)據(jù)和目的地址準備好，交給路由進程即可，其邏輯拓撲圖如圖4所示。

圖4 路由進程和其他進程拓撲結構Fig.4 Topology among router and other process

3 設計與實現(xiàn)

在這種體系結構中，應用進程無需關心包括星內(nèi)和星地的任何鏈路層協(xié)議，僅僅需要將路由表進行修改。因此，路由表的設計和網(wǎng)絡層、鏈路層編址是關鍵。路由表項數(shù)據(jù)結構設計如下所示：

struct RouteInfo{

unsigned16 apid;/*被路由源包的APID*/

unsigned16 link_addr;/*下一跳鏈路地址：對于總線地址，則表示RT地址；對于本地AP，則表示進程標識*/

SERVICETYPE service_type;/*下個鏈路要采用的服務類型，或表示本地*/

unsigned16 transfer_id;/*下一跳鏈路輔助信息*/}；

而根據(jù)以上路由表項，某衛(wèi)星典型的路由表如表1所示。于是，在本體系結構中，當衛(wèi)星綜合處理單元(SMU)應用層需要給其他終端發(fā)送數(shù)據(jù)時，其主要過程如下：

(1)應用程序輸入源包APID和數(shù)據(jù)，啟動發(fā)送；

(2)網(wǎng)絡層協(xié)議構件組織好的源包到路由模塊；

(3)路由模塊根據(jù)源包的APID搜索路由表，找到下一跳鏈路地址、下一跳鏈路業(yè)務和可選的下一跳輔助信息；

(4)根據(jù)下一跳鏈路地址和鏈路業(yè)務，調(diào)用底層鏈路協(xié)議構件，將相關數(shù)據(jù)傳輸。

顯然，以上步驟中，第2、3和4步在本體系結構中，由底層通信模塊完成，完全參數(shù)化配置運行。應用程序僅僅需要完成第1步，即提供APID和需要傳輸?shù)臄?shù)據(jù)即可，完全與底層鏈路協(xié)議隔離。

事實上，即使衛(wèi)星傳輸方案發(fā)生了重大變化，例如將1553B總線更換為CAN總線，那么在本方案中，僅需要在底層通信中增加CAN總線協(xié)議處理構件或模塊，然后更新相關的路由表項，即可以實現(xiàn)衛(wèi)星數(shù)據(jù)流轉，應用層軟件無需任何變動。

表1 典型星載路由表

4 結論

本體系結構在遙感公用平臺等航天器型號中得到實施，且取得了以下良好作用。

(1)建立了分層的協(xié)議雛形，將注重協(xié)議的格式轉變?yōu)橹魂P心協(xié)議提供的服務，極大簡化應用程序數(shù)據(jù)傳輸，從而降低應用程序復雜度。

(2)有利于需求變化和系統(tǒng)演化，當需要增加或減少數(shù)據(jù)包，或修改總線通信規(guī)劃，則僅僅需要更改路由配置表，甚至是協(xié)議的變化，也不會影響上層應用程序。

當然，這種軟件體系結構也對任務提出了一定的要求，即星內(nèi)、星地傳輸?shù)臄?shù)據(jù)必須以空間包的格式傳輸。除此之外，現(xiàn)階段對統(tǒng)一的鏈路層編址方式考慮尚不完善，因此路由表的設計存在冗余和不規(guī)則。

References)

[1]趙和平，李寧寧.CCSDS標準在軍用航天任務中的應用[J].航天器工程，2007，16(4)：78-82

Zhao Heping,Li Ningning.Implementation of CCSDS standard in military space mission[J].Spacecraft Engineering，2007，16(4)：78-82 (in Chinese)

[2]CCSDS.CCSDS 232.0-B-1 AOS data link protocol — recommendation for space data system standards[S].Blue Book Issue 1.Washington D.C.：CCSDS，2003

[3]CCSDS.CCSDS 133.0-B-1 Space packet protocol — recommendation for space data system standards[S].Blue Book Issue 1.Washington D.C.：CCSDS，2003

[4]王向暉，王同桓，李寧寧，等.一種AOS遙測源包多路調(diào)度算法[J].航天器工程，2011，20(5)：83-87

Wang Xianghui，Wang Tonghuan，Li Ningning，et al.An efficient scheduling algorithm of multiplexing TM service based on the AOS[J].Spacecraft Engineering，2011，20(5)：83-87 (in Chinese)

[5]European Cooperation for Space Standardization. Space engineering：interface and communication protocol for MIL-STD-1553B data bus on board spacecraft,Ecss-E-ST-50-13C[S].Noordwijk，The Netherlands：ECSS Secretariat ESA-ESTEC Requirements & Standards Division，2008

[6]張亞航，袁珺，郭堅.一種基于構件的可重配置通用星載遙測軟件設計[J].航天器工程，2013，22(4)：62-67

Zhang Yahang，Yuan Jun，Guo Jian.Design of reconfigurable general TM based on software component [J].Spacecraft Engineering，2013，22(4)：62-67 (in Chinese)

[7]張亞航，張猛，袁珺，等.基于C語言的綜合電子星載軟件構件技術研究[C]// 第一屆高分辨率對地觀測學術研討會.北京：中國空間技術研究院，2012

Zhang Yahang，Zhang Meng，Yuanjun，et al.Research of spacecraft software components based on C language[C]// The 1st Conference on High Graphics Earth Observation Technology.Beijing：CAST，2012 (in Chinese)

[8]賀仁杰，高鵬，白保存，等.成像衛(wèi)星任務規(guī)劃模型、算法及其應用[J].系統(tǒng)工程理論與實踐，2011，31(3)：411-412

He Renjie，Gao Peng，Bai Baocun，et al.Models,algorithms and applications to the mission planning system of imaging satellites[J].Systems Engineering —Theory & Practice，2011，31(3)：411-412 (in Chinese)

[9]Gacek C，Abd Allah A，Clark B K，et al.On the definition of software system architecture[C]// Proceedings of the 1st International Workshop on Architecture for Software Systems.New York：ACM Press.1995：85-95

[10]IEEE.IEEE standard glossary of software engineering terminology[S].New York：Standards Coordinating Committee of the IEEE Computer Society，1990

[11]Nicolas G，Charles L，David D.A modeling framework for software architecture specification and validation[J].Lecture Notes in Computer Science，2014，8810(1)：303-314

(編輯：張小琳)

Design of Spacecraft OBDH Software Framework Based on Onboard Route

ZHANG Yahang YUAN Jun YU Junhui ZHENG Guocheng

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

During the development of data management sub-system on traditional spacecrafts，the management of protocol data form and data transaction take plenty of time，because of the meticulous analysis of all kinds of transport protocol.A design of spacecraft OBDH software framework based on onboard route is introduced in this article.By using this framework，data link layer protocols，such as AOS Link，TC Link and 1553B Link，are handled by network layer route which works as a component.When application layer software needs to send/receive data，the sending/receiving interfaces of the network layer are utilized，and the background running route will choose the destination and service type needed for the data automatically，according to the route table.The data flow between ground，OBDH and other onboard sub-systems is thus formed.This framework seperates the functions of the application layer from the commucation of the bottom layer totally，which makes the design of application layer software more convenient.

spacecraft;OBDH;route;software framework

2015-09-28；

2015-11-17

國家自然科學基金(91438102)

張亞航，男，碩士，從事衛(wèi)星數(shù)管/綜合電子設計、信息安全研究等工作。Email：zhangyahang@163.com。

V446

A

10.3969/j.issn.1673-8748.2015.06.012