連卉 郝燕艷 李延濱 李溟
(中國(guó)空間技術(shù)研究院通信衛(wèi)星事業(yè)部,北京 100094)
基于信息流的星載軟件需求分析方法
連卉 郝燕艷 李延濱 李溟
(中國(guó)空間技術(shù)研究院通信衛(wèi)星事業(yè)部,北京 100094)
針對(duì)星載軟件數(shù)量多且設(shè)計(jì)分散,各自承擔(dān)不同的信息處理任務(wù),難以進(jìn)行有效的總體軟件需求分析的問(wèn)題,文章提出一種基于信息流的軟件需求分析方法,以系統(tǒng)級(jí)信息流設(shè)計(jì)為核心,首先進(jìn)行信息流構(gòu)架設(shè)計(jì),明確衛(wèi)星上各級(jí)總線架構(gòu);其次確定星上接口類型、數(shù)據(jù)傳輸協(xié)議等,并形成整星軟件信息接口關(guān)系;最后根據(jù)信息流分解的結(jié)果,確定軟件配置項(xiàng)的需求。此方法已在通信衛(wèi)星領(lǐng)域中實(shí)際使用,結(jié)果表明它可以有效地制定星上處理規(guī)則,優(yōu)化軟件設(shè)計(jì)流程,增強(qiáng)軟件設(shè)計(jì)的完備性和健壯性。
星載軟件;衛(wèi)星信息流;需求分析
隨著衛(wèi)星應(yīng)用需求的發(fā)展,傳統(tǒng)電子產(chǎn)品已經(jīng)不能滿足航天器的任務(wù)需求。依托微電子技術(shù)的快速發(fā)展,軟件以數(shù)字信號(hào)處理器為核心,實(shí)現(xiàn)衛(wèi)星內(nèi)務(wù)管理、數(shù)據(jù)交換、信號(hào)處理,改變了傳統(tǒng)電子系統(tǒng)中采用純硬件的實(shí)現(xiàn)方式。通常這樣的星載設(shè)備具有集成度高、體積小、功耗低的優(yōu)點(diǎn),通過(guò)軟件升級(jí)無(wú)需更改硬件即可完成功能和性能的提升或改變,具有高度的靈活性和擴(kuò)展性。
軟件的質(zhì)量和可靠性已經(jīng)成為航天型號(hào)產(chǎn)品質(zhì)量和可靠性的關(guān)鍵因素之一,乃至可以直接影響任務(wù)的成敗。通過(guò)對(duì)國(guó)外航天器和運(yùn)載器的故障分析,軟件需求存在缺陷或者質(zhì)量差是引起航天器軟件故障的重要原因之一[1]。例如1996年6月4日歐洲阿里安-501火箭發(fā)射40 s后在2700 m高空偏離航向,爆炸解體[2-3],故障報(bào)告中認(rèn)為,根本原因在于某軟件需求錯(cuò)誤。1999年,美國(guó)研制的“火星基地著陸器”在執(zhí)行著陸過(guò)程中,沒(méi)有按計(jì)劃向地球發(fā)回任何信息[4],故障報(bào)告認(rèn)為,故障源于需求遺漏,即系統(tǒng)級(jí)軟件需求存在缺陷。1999年4月30日發(fā)射的美國(guó)大力神號(hào)火箭,將一顆美國(guó)軍用衛(wèi)星送入錯(cuò)誤的LEO軌道,未能進(jìn)入預(yù)定的地球靜止軌道[5],故障報(bào)告指出,缺少內(nèi)容完整無(wú)歧義的軟件需求。因此為了確保軟件的研制質(zhì)量,必須在理解系統(tǒng)的基礎(chǔ)上,分解并提煉出詳細(xì)、完備的軟件需求。
目前我國(guó)研制的載人飛船、通信衛(wèi)星、深空探測(cè)器的平臺(tái)和載荷設(shè)備都包括了大量的嵌入式軟件和現(xiàn)場(chǎng)可編程門陣列(FPGA),可以說(shuō)星載軟件承擔(dān)著航天器系統(tǒng)管理、過(guò)程控制、數(shù)據(jù)采集和處理、數(shù)據(jù)通信以及系統(tǒng)安全保障等各種功能。由于星載軟件產(chǎn)品眾多,在航天器上所處的位置和所起的作用各有很大不同,加上各設(shè)計(jì)師理解不同,導(dǎo)致分散提出軟件需求時(shí)很容易出現(xiàn)缺陷或錯(cuò)誤,再加上技術(shù)難度大,研制進(jìn)度緊,給衛(wèi)星的研制質(zhì)量帶來(lái)極大的挑戰(zhàn)。
本文提出了一種基于信息流的星載軟件需求分析方法,其核心就是強(qiáng)化衛(wèi)星信息流設(shè)計(jì),為軟件需求提供系統(tǒng)分析的基礎(chǔ)支持。軟件需求分析時(shí),以衛(wèi)星上系統(tǒng)級(jí)信息流設(shè)計(jì)結(jié)果和單機(jī)需求相結(jié)合為輸入,進(jìn)行軟硬件功能劃分后提出詳細(xì)的軟件用戶需求。在衛(wèi)星總體設(shè)計(jì)階段,盡可能完善地理解需求、明確功能、性能接口需求,使整個(gè)軟件研制的重心提前,盡可能地減少由于理解不一致而引入的軟件缺陷[6],達(dá)到提高星載軟件產(chǎn)品質(zhì)量的目的。
按照衛(wèi)星的研制流程,首先進(jìn)行整星方案設(shè)計(jì),其次進(jìn)行分系統(tǒng)設(shè)計(jì)、單機(jī)設(shè)計(jì),最后進(jìn)行軟件設(shè)計(jì)(見(jiàn)圖1(a))。但是在這種研制模式下,往往由于總體能力和研制進(jìn)度等原因,在尚未完成詳細(xì)的整星設(shè)計(jì)時(shí),就并行開(kāi)展單機(jī)設(shè)計(jì)、分系統(tǒng)設(shè)計(jì)。即在軟件設(shè)計(jì)時(shí),只有單機(jī)對(duì)軟件的初步需求,并非是通過(guò)逐級(jí)分析整星、分系統(tǒng)對(duì)軟件的需求后,提出的詳細(xì)明確的軟件需求。這種情況容易引起因需求缺陷導(dǎo)致的軟件設(shè)計(jì)錯(cuò)誤。
從軟件設(shè)計(jì)角度分析,先進(jìn)行單機(jī)軟件設(shè)計(jì),再攢成整個(gè)系統(tǒng)的總體功能,是不可行的。單個(gè)軟件功能的簡(jiǎn)單疊加組合,絕對(duì)不是軟件系統(tǒng)的功能。單機(jī)軟件設(shè)計(jì)往往是在單機(jī)設(shè)計(jì)的基本框架下完成的,由于單機(jī)設(shè)計(jì)專業(yè)性很強(qiáng),如果缺少系統(tǒng)設(shè)計(jì)的依據(jù),對(duì)航天器的任務(wù)特點(diǎn)、星上通信協(xié)議、星上處理時(shí)序、星地接口協(xié)議等要求分析不到位,容易犯“只見(jiàn)樹(shù)木不見(jiàn)森林”的錯(cuò)誤,往往會(huì)使軟件需求埋下缺陷,例如,采用先進(jìn)的技術(shù)姑且可以增強(qiáng)功能,但有些功能在航天器上可能是多余的,而這些附加的功能不僅消耗了大量的系統(tǒng)機(jī)、電、熱資源,還有可能帶來(lái)“多余物”的危害;又例如,為了實(shí)現(xiàn)某項(xiàng)功能,采用了高性能芯片,但由于協(xié)議不匹配,重要數(shù)據(jù)無(wú)法實(shí)時(shí)下傳。這樣的例子在從研發(fā)階段轉(zhuǎn)為工程階段時(shí)常出現(xiàn)。
基于信息流分析的軟件需求分析方法可以在很大程度上避免上述弊病,它是以信息流作為明確軟件輸入、輸出、接口時(shí)序分析的突破口,為星載軟件需求分析提供有力的系統(tǒng)級(jí)支持。首先在總體方案、分系統(tǒng)和單機(jī)設(shè)計(jì)的同時(shí),并行開(kāi)展整星信息流分析(見(jiàn)圖1(b)),即設(shè)計(jì)一個(gè)信息流通道、節(jié)點(diǎn)組成關(guān)系的方案,確保信息流網(wǎng)絡(luò)構(gòu)架滿足信息需求和航天器總體設(shè)計(jì)需求。為了保證架構(gòu)合理,建議使用分級(jí)設(shè)計(jì)方法,先進(jìn)行一級(jí)總線設(shè)計(jì),再進(jìn)行二、三級(jí)總線設(shè)計(jì)。首先,在設(shè)計(jì)時(shí)應(yīng)規(guī)劃與嵌入式軟件的中斷、任務(wù)優(yōu)先級(jí)的相對(duì)關(guān)系。其次,進(jìn)行信息接口設(shè)計(jì),設(shè)計(jì)出合理的接口功能,確定傳輸數(shù)據(jù)、傳輸周期、接口時(shí)序,通過(guò)該項(xiàng)分析,涉及到的嵌入式軟件的任務(wù)、時(shí)序應(yīng)基本確定。在分系統(tǒng)總線設(shè)計(jì)后,形成各個(gè)單機(jī)的功能性能需求。最后,基于信息流分析結(jié)果和單機(jī)任務(wù)要求,確定軟件配置項(xiàng)的需求。
圖1 兩種軟件需求分析方法Fig.1 Two methods of software requirement analysis
3.1 信息流分析
在本文的例子中,信息流分析時(shí)按兩級(jí)信息總線加以分解,有必要時(shí)可以向下再擴(kuò)展到三級(jí),如載荷系統(tǒng)內(nèi)信息流等。
3.1.1 一級(jí)總線架構(gòu)分析
本文涉及的某衛(wèi)星總體設(shè)計(jì),確定采用1553B作為系統(tǒng)的數(shù)據(jù)主干路,把分配在各艙位的遠(yuǎn)置終端單元(Remote Terminal Unit,RTU)和具有連接總線能力的分系統(tǒng)與數(shù)管計(jì)算機(jī)——中央終端單元(Center Terminal Unit,CTU)連接成系統(tǒng),它在物理上是一條實(shí)實(shí)在在的數(shù)據(jù)串行總線,在信息流分析中是系統(tǒng)信息的一級(jí)總線。CTU作為總控端(BC),數(shù)據(jù)管理分系統(tǒng)的RTU A/B、其他分系統(tǒng)的計(jì)算機(jī)作為終端(RT)。CTU與RTU A/B協(xié)作,實(shí)時(shí)地完成衛(wèi)星數(shù)據(jù)采集、數(shù)管指令存儲(chǔ)、處理和分發(fā)、分系統(tǒng)工作狀態(tài)的自主監(jiān)控、自主熱控、電源自主管理以及控制分系統(tǒng)重要數(shù)據(jù)存儲(chǔ)轉(zhuǎn)發(fā)功能。RTU A/B完成包括定期循環(huán)采集各分系統(tǒng)的遙測(cè)參數(shù),并通過(guò)1553B總線送給數(shù)管計(jì)算機(jī),對(duì)總線接收的指令進(jìn)行校驗(yàn)、譯碼并執(zhí)行。
除了RTU A/B,還應(yīng)分析總線上是否需要連接其他分系統(tǒng)的重要計(jì)算機(jī)。例如控制、電源、熱控、有效載荷如何與CTU進(jìn)行數(shù)據(jù)交互。控制分系統(tǒng)計(jì)算機(jī)作為衛(wèi)星的控制核心,接收地球敏感器、太陽(yáng)敏感器、陀螺數(shù)據(jù),控制太陽(yáng)翼驅(qū)動(dòng)裝置(SADA)、動(dòng)量輪、10 N推力器等執(zhí)行機(jī)構(gòu),同時(shí)完成故障診斷與處理、遙控、遙測(cè)及程控功能,因此與CTU應(yīng)具備一級(jí)總線接口。某載荷子系統(tǒng)上下行數(shù)據(jù)量較大,載荷設(shè)備A需要通過(guò)CTU完成與地面的數(shù)據(jù)通信。
各RTU完成各分系統(tǒng)遙測(cè)信息的采集和遙控指令的發(fā)送。因此,各RTU與各分系統(tǒng)有信息接口,考慮分級(jí)設(shè)計(jì)方式CTU不需要設(shè)計(jì)直接與各分系統(tǒng)數(shù)據(jù)的接口。遙控單元完成對(duì)上行通信的業(yè)務(wù)操作,包括副載波信號(hào)的解調(diào),信道譯碼及地址識(shí)別,將解析出的指令發(fā)送給CTU。同時(shí)對(duì)于數(shù)管計(jì)算機(jī)將編排好的遙測(cè)數(shù)據(jù)發(fā)送給遙測(cè)單元,由遙測(cè)單元完成副載波調(diào)制等下行業(yè)務(wù)[7]。
通信衛(wèi)星通過(guò)1553B總線進(jìn)行星上數(shù)據(jù)交換,采用互為備份的雙總線冗余結(jié)構(gòu)(即A總線和B總線),在信息傳輸超時(shí)或出錯(cuò)情況下,由CTU軟件進(jìn)行容錯(cuò)管理,確定重新傳輸或切換另一條總線的機(jī)制。因此一級(jí)總線如圖2所示。
圖2 信息流一級(jí)總線(1553B)架構(gòu)Fig.2 First grade(1553B)information bus
3.1.2 二級(jí)總線架構(gòu)分析
RTU A設(shè)計(jì)有8個(gè)串行接口,可以輪詢完成與8臺(tái)設(shè)備的雙向通信。有效載荷設(shè)備B/C/D/E通過(guò)串口1—4完成與RTU A數(shù)據(jù)交換,其余4個(gè)串口備用,如圖3所示。它們?cè)谖锢砩鲜且唤M串口,但在信息流分析中可視其為二級(jí)信息總線。
RTU A在接收CTU的指令,驗(yàn)證正確后,根據(jù)設(shè)備地址轉(zhuǎn)發(fā)給相應(yīng)的有效載荷設(shè)備,各載荷設(shè)備在收到指令數(shù)據(jù)后,對(duì)數(shù)據(jù)的有效性進(jìn)行判斷,包括判斷設(shè)備地址及校驗(yàn)和的正確性,并執(zhí)行有效的指令。
同時(shí),RTU A采用輪詢的方式,依次向有效載荷設(shè)備發(fā)送采集數(shù)據(jù)命令信息,完成相應(yīng)的遙測(cè)數(shù)據(jù)的接收,將編排后的數(shù)據(jù)轉(zhuǎn)發(fā)給CTU。如在規(guī)定時(shí)間內(nèi)未采集遙測(cè)信息則向CTU報(bào)警,保證系統(tǒng)傳輸?shù)膶?shí)時(shí)性。
圖3 信息流二級(jí)(RTU向下)總線構(gòu)架Fig.3 Second grade(RTU down)information bus
3.2 信息接口設(shè)計(jì)
3.2.1 一級(jí)總線接口
經(jīng)上述總線架構(gòu)分析,按照信息流歸納出CTU通過(guò)一級(jí)總線通信完成以下功能,信息接口見(jiàn)表1。
(1)發(fā)送常規(guī)指令至RTU A/B(常規(guī)指令指數(shù)據(jù)指令和離散指令);
(2)采集RTU A/B的常規(guī)遙測(cè)數(shù)據(jù)(常規(guī)遙測(cè)包括模擬量、溫度量、雙電平量等);
(3)通過(guò)RTU A轉(zhuǎn)發(fā)有效載荷指令;
(4)通過(guò)RTU A采集有效載荷遙測(cè);
(5)完成與控制計(jì)算機(jī)的數(shù)據(jù)交互,實(shí)現(xiàn)數(shù)管分系統(tǒng)與控制分系統(tǒng)的數(shù)據(jù)備份;
(6)完成與載荷設(shè)備A的數(shù)據(jù)交互,實(shí)現(xiàn)對(duì)載荷設(shè)備A的程序、數(shù)據(jù)注入。
表1 1553B總線接口信息Table 1 Interface Information of 1553B
3.2.2 二級(jí)總線接口
RTU A將CTU的指令解析后,確定向某臺(tái)載荷設(shè)備發(fā)送指令信息,并配置相應(yīng)的串口,向該串口發(fā)送指令信息。該載荷設(shè)備收到串口信息后,解析指令并執(zhí)行后,向RTU A發(fā)送相應(yīng)信息。同時(shí)載荷軟件編排設(shè)備的遙測(cè)信息,在RTU通過(guò)串口發(fā)送“采集遙測(cè)數(shù)據(jù)”的指令后,將約定好的遙測(cè)信息發(fā)給RTU A。RTU A轉(zhuǎn)發(fā)給CTU后,通過(guò)遙測(cè)單元下傳地面。按照信息流分析得到的二級(jí)總線信息接口見(jiàn)表2。
表2 串行總線接口信息Table 2 Interfaceinformation of serial bus
RTU A在數(shù)據(jù)的發(fā)送上采用不定長(zhǎng)方式,按照串行通信協(xié)議設(shè)計(jì)波特率為9600 bit/s,數(shù)據(jù)位為8位,無(wú)奇偶校驗(yàn)位,先傳高字節(jié)后傳低字節(jié)的方式進(jìn)行傳輸。RTU A為控制端,所有載荷設(shè)備均為被控端,并為各處理設(shè)備分配地址。
3.3 形成軟件系統(tǒng)信息流圖
經(jīng)上述分析,各單機(jī)軟件功能基本確定。CTU軟件完成與RTU A/B的通信,包括指令注入、遙測(cè)數(shù)據(jù)、1553B總線通信,與控制計(jì)算機(jī)通信,及其數(shù)管內(nèi)務(wù)管理等,與載荷設(shè)備A通信,完成對(duì)載荷設(shè)備A的程序、數(shù)據(jù)注入。
RTU A/B軟件完成各分系統(tǒng)模擬量、溫度量、數(shù)字量的采集及編排,發(fā)送給CTU;對(duì)總線接收的指令進(jìn)行校驗(yàn)、譯碼并執(zhí)行;RTU A通過(guò)串口轉(zhuǎn)發(fā)載荷設(shè)備的指令,采集遙測(cè)信息。
控制分系統(tǒng)軟件完成采集太陽(yáng)敏感器、地球敏感器、陀螺等敏感器信息和動(dòng)量輪轉(zhuǎn)速信息,計(jì)算出控制量送給動(dòng)量輪和推進(jìn)分系統(tǒng)。完成衛(wèi)星在軌模式控制功能,同時(shí)完成故障診斷與處理、遙控、遙測(cè)及程控功能。與數(shù)管計(jì)算機(jī)互相保存重要數(shù)據(jù)供出現(xiàn)故障時(shí)使用。
全系統(tǒng)軟件的信息流如圖4所示(不包含有效載荷等軟件的設(shè)計(jì)結(jié)果),它是在系統(tǒng)級(jí)信息流分析基礎(chǔ)上形成的(本章節(jié)只對(duì)軟件進(jìn)行概述,未給出詳細(xì)的軟件系統(tǒng)分析結(jié)果)。
3.4 以信息流分析結(jié)果開(kāi)展軟件需求分析
在進(jìn)行分系統(tǒng)設(shè)計(jì)后,形成各個(gè)單機(jī)的功能性能需求,結(jié)合信息流分析結(jié)果,開(kāi)展軟件配置項(xiàng)需求設(shè)計(jì)。
以RTU A軟件為例,從整星信息流分析結(jié)果來(lái)看,除完成自身的參數(shù)初始化外,需要完成以下4項(xiàng)功能:①發(fā)送串口指令至各載荷設(shè)備;②發(fā)送常規(guī)指令至各分系統(tǒng);③采集各分系統(tǒng)常規(guī)遙測(cè)并發(fā)送至CTU;④采集各載荷設(shè)備串口遙測(cè)并發(fā)送至CTU軟件數(shù)據(jù)流(見(jiàn)圖5)。根據(jù)整星的任務(wù)分析,RTU A首先保證遙測(cè)信息發(fā)送,因此遙測(cè)發(fā)送設(shè)置為一個(gè)外部中斷,且優(yōu)先級(jí)最高。在每個(gè)中斷觸發(fā)前,需要準(zhǔn)備好常規(guī)遙測(cè)并組包。設(shè)計(jì)總線指令接收中斷,接收CTU發(fā)送的指令數(shù)據(jù)包,解包后將不同的指令進(jìn)行相應(yīng)的處理和執(zhí)行。RTU A在采集遙測(cè)數(shù)據(jù)的間隙,如果有串口有效載荷指令,則發(fā)送串口有效載荷指令至相應(yīng)的串口。若此周期內(nèi)無(wú)串口指令,則依次向有效載荷設(shè)備發(fā)送采集遙測(cè)的信息。
軟件各模塊頂層設(shè)計(jì)如下,包括兩個(gè)外部中斷0和1,用于發(fā)送遙測(cè)數(shù)據(jù)至CTU和接收來(lái)自CTU的指令數(shù)據(jù)包。設(shè)置4個(gè)任務(wù):①發(fā)送硬件指令至各設(shè)備;②循環(huán)接收各串口遙測(cè);③發(fā)送串口指令;④執(zhí)行軟件指令,即地面控制端需要RTU軟件完成的命令。其他主要工作包括參數(shù)初始化,軟件自檢,定期啟用“看門狗”,組包遙測(cè)數(shù)據(jù)和數(shù)據(jù)指令解包,這些工作在后臺(tái)進(jìn)行,即主程序中循環(huán)完成,如圖6所示。
圖6 基于信息流分析的RTU A軟件需求設(shè)計(jì)Fig.6 Software requirement design base on information flow analysis
通過(guò)以上工作,軟件的主要功能、性能、輸入、輸出、數(shù)據(jù)處理、接口等指標(biāo)和要求均已明確,軟件需求分析工作完成,可以根據(jù)分析結(jié)果進(jìn)行RTU A軟件配置項(xiàng)的設(shè)計(jì)開(kāi)發(fā)工作。
本文提出了一種基于信息流設(shè)計(jì)的軟件需求分析方法,與傳統(tǒng)軟件需求分析方法相比,它能夠以系統(tǒng)信息流為脈絡(luò)牽動(dòng)各軟件需求,從而全面反映系統(tǒng)、分系統(tǒng)與單機(jī)的需求,為高質(zhì)量的軟件設(shè)計(jì)提供系統(tǒng)級(jí)的有力支持。并以通信衛(wèi)星為例,詳細(xì)介紹了衛(wèi)星設(shè)計(jì)階段的軟件需求分析全過(guò)程,首先進(jìn)行信息流分析,再進(jìn)行信息接口設(shè)計(jì),確定整星軟件接口,結(jié)合硬件設(shè)計(jì),形成詳細(xì)而準(zhǔn)確的軟件用戶需求。經(jīng)過(guò)衛(wèi)星研制過(guò)程的設(shè)計(jì)驗(yàn)證和在軌飛行驗(yàn)證,基于信息流設(shè)計(jì)的軟件需求方法合理可行,可優(yōu)化軟件設(shè)計(jì)流程,有利于采用更合理的軟件架構(gòu)、開(kāi)發(fā)環(huán)境、硬件芯片資源。
隨著高性能嵌入式軟件、數(shù)字處理芯片、FPGA處理芯片在航天器上的廣泛應(yīng)用,通過(guò)數(shù)據(jù)、程序上注的方式更新軟件,可以解決軟件固有的缺陷,也可以根據(jù)在軌應(yīng)用時(shí)用戶的反饋意見(jiàn),提升軟件的性能。開(kāi)展基于信息流的軟件需求分析工作,可以從方案階段確保數(shù)管計(jì)算機(jī)支持上注信息,實(shí)現(xiàn)星載軟件的在軌維護(hù)功能,提升衛(wèi)星系統(tǒng)設(shè)計(jì)的靈活性。
(
)
[1]侯成杰.國(guó)外航天軟件故障原因分析[J].航天器工程,2012,21(1):90-91 Hou Chengjie.Analysis on fault causes of space software abroad[J].Spacecraft Engineering,2012,21(1): 90-91(in Chinese)
[2]Leveson N.The role of software in spacecraft accidents[R].Boston:MIT,2001
[3]Lions J L.Ariane 501 failure:report by the inquiry board[R].Paris:ESA,1996
[4]Weiss K A.An analysis of causation in aerospace accidents[R].Boston:MIT,2001
[5]Bureau of Air Safety Investigation.Advanced technology aircraft safety survey report[R].Brisbane:Bureau of Air Safety Investigation,1996
[6]王振華,張維瑾,張國(guó)峰,等.航天星載軟件項(xiàng)目質(zhì)量管理的思考[J].航天器工程,2012,21(z):90-93 Wang Zhenhua,Zhang Wei jin,Zhang Guofeng.Thinking of project quality control on space software aboard[J].Spacecraft Engineering,2012,21(z):90-93(in Chinese)
[7]譚維熾.胡金剛.航天器系統(tǒng)工程[M].北京:中國(guó)科學(xué)技術(shù)出版社,2009:261-262 Tan Weichi,Hu Jingang.Spacecraft systems engineering[M].Beijing:China Science and Technology Press,2009(in Chinese)
(編輯:李多)
Software Requirement Analysis of Satellite Based on Information Flow
LIAN Hui HAO Yanyan LI Yanbin LI Ming
(Institute of Telecommunication Satellite,China Academy of Space Technology,Beijing 100094,China)
The software onboard is responsible for processing large amount of imformation.It is hard to carry out effective software requirement analysis.The paper introduces a method of the spacecraft software requirement analysis by developing an information flow design.Firstly to carry out information architecture design and specify bus architectures at all levels;secondly to determine onboard interfaces type and data transmission protocol and form software interface relationship for whole satellite,and finally to specify the software input,output and interface,and to define the software configuration item requirement.The method has been tested on the satellite and the result demonstrated the validity.It is benefical to specifing a reasonable rule of information processing,and is conducive to enhancing the function of in-orbit maintenance.
software on board;information flow of satellite;analysis of requirement
V443
A DOI:10.3969/j.issn.1673-8748.2015.02.012
2015-02-13;
2015-03-09
連卉,女,碩士,從事衛(wèi)星軟件總體設(shè)計(jì)、測(cè)控信息設(shè)計(jì)研究工作。Email:lianhui2008@sohu.com。