張亞航 袁珺 于俊慧 鄭國成

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

?

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

張亞航 袁珺 于俊慧 鄭國成

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

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

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

1 引言

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

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

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

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

2 軟件體系結(jié)構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1 分層軟件體系結(jié)構(gòu)

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

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

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

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

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

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

2.2.2 通信協(xié)議拓?fù)浣Y(jié)構(gòu)

在既有的軟件構(gòu)件基礎(chǔ)之上，建立了基于路由的體系結(jié)構(gòu)，圖3以遙測進(jìn)程與路由進(jìn)程的通信為例，將該數(shù)據(jù)的拓?fù)浣Y(jié)構(gòu)進(jìn)行了說明。

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

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

圖4 路由進(jìn)程和其他進(jìn)程拓?fù)浣Y(jié)構(gòu)Fig.4 Topology among router and other process

3 設(shè)計與實現(xiàn)

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

struct RouteInfo{

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

unsigned16 link_addr;/*下一跳鏈路地址：對于總線地址，則表示RT地址；對于本地AP，則表示進(jìn)程標(biāo)識*/

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

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

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

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

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

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

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

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

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

表1 典型星載路由表

4 結(jié)論

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

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

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

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

References)

[1]趙和平，李寧寧.CCSDS標(biāo)準(zhǔn)在軍用航天任務(wù)中的應(yīng)用[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]張亞航，袁珺，郭堅.一種基于構(gòu)件的可重配置通用星載遙測軟件設(shè)計[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語言的綜合電子星載軟件構(gòu)件技術(shù)研究[C]// 第一屆高分辨率對地觀測學(xué)術(shù)研討會.北京：中國空間技術(shù)研究院，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)星任務(wù)規(guī)劃模型、算法及其應(yīng)用[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

國家自然科學(xué)基金(91438102)

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

V446

A

10.3969/j.issn.1673-8748.2015.06.012