基于信息流的星載軟件需求分析方法

連卉 郝燕艷 李延濱 李溟

（中國空間技術研究院通信衛星事業部，北京 100094）

基于信息流的星載軟件需求分析方法

連卉 郝燕艷 李延濱 李溟

（中國空間技術研究院通信衛星事業部，北京 100094）

針對星載軟件數量多且設計分散，各自承擔不同的信息處理任務，難以進行有效的總體軟件需求分析的問題，文章提出一種基于信息流的軟件需求分析方法，以系統級信息流設計為核心，首先進行信息流構架設計，明確衛星上各級總線架構；其次確定星上接口類型、數據傳輸協議等，并形成整星軟件信息接口關系；最后根據信息流分解的結果，確定軟件配置項的需求。此方法已在通信衛星領域中實際使用，結果表明它可以有效地制定星上處理規則，優化軟件設計流程，增強軟件設計的完備性和健壯性。

星載軟件；衛星信息流；需求分析

1 引言

隨著衛星應用需求的發展，傳統電子產品已經不能滿足航天器的任務需求。依托微電子技術的快速發展，軟件以數字信號處理器為核心，實現衛星內務管理、數據交換、信號處理，改變了傳統電子系統中采用純硬件的實現方式。通常這樣的星載設備具有集成度高、體積小、功耗低的優點，通過軟件升級無需更改硬件即可完成功能和性能的提升或改變，具有高度的靈活性和擴展性。

軟件的質量和可靠性已經成為航天型號產品質量和可靠性的關鍵因素之一，乃至可以直接影響任務的成敗。通過對國外航天器和運載器的故障分析，軟件需求存在缺陷或者質量差是引起航天器軟件故障的重要原因之一［1］。例如1996年6月4日歐洲阿里安-501火箭發射40 s后在2700 m高空偏離航向，爆炸解體［2-3］，故障報告中認為，根本原因在于某軟件需求錯誤。1999年，美國研制的“火星基地著陸器”在執行著陸過程中，沒有按計劃向地球發回任何信息［4］，故障報告認為，故障源于需求遺漏，即系統級軟件需求存在缺陷。1999年4月30日發射的美國大力神號火箭，將一顆美國軍用衛星送入錯誤的LEO軌道，未能進入預定的地球靜止軌道［5］，故障報告指出，缺少內容完整無歧義的軟件需求。因此為了確保軟件的研制質量，必須在理解系統的基礎上，分解并提煉出詳細、完備的軟件需求。

目前我國研制的載人飛船、通信衛星、深空探測器的平臺和載荷設備都包括了大量的嵌入式軟件和現場可編程門陣列（FPGA），可以說星載軟件承擔著航天器系統管理、過程控制、數據采集和處理、數據通信以及系統安全保障等各種功能。由于星載軟件產品眾多，在航天器上所處的位置和所起的作用各有很大不同，加上各設計師理解不同，導致分散提出軟件需求時很容易出現缺陷或錯誤，再加上技術難度大，研制進度緊，給衛星的研制質量帶來極大的挑戰。

本文提出了一種基于信息流的星載軟件需求分析方法，其核心就是強化衛星信息流設計，為軟件需求提供系統分析的基礎支持。軟件需求分析時，以衛星上系統級信息流設計結果和單機需求相結合為輸入，進行軟硬件功能劃分后提出詳細的軟件用戶需求。在衛星總體設計階段，盡可能完善地理解需求、明確功能、性能接口需求，使整個軟件研制的重心提前，盡可能地減少由于理解不一致而引入的軟件缺陷［6］，達到提高星載軟件產品質量的目的。

2 基于信息流的軟件需求分析方法

按照衛星的研制流程，首先進行整星方案設計，其次進行分系統設計、單機設計，最后進行軟件設計（見圖1（a））。但是在這種研制模式下，往往由于總體能力和研制進度等原因，在尚未完成詳細的整星設計時，就并行開展單機設計、分系統設計。即在軟件設計時，只有單機對軟件的初步需求，并非是通過逐級分析整星、分系統對軟件的需求后，提出的詳細明確的軟件需求。這種情況容易引起因需求缺陷導致的軟件設計錯誤。

從軟件設計角度分析，先進行單機軟件設計，再攢成整個系統的總體功能，是不可行的。單個軟件功能的簡單疊加組合，絕對不是軟件系統的功能。單機軟件設計往往是在單機設計的基本框架下完成的，由于單機設計專業性很強，如果缺少系統設計的依據，對航天器的任務特點、星上通信協議、星上處理時序、星地接口協議等要求分析不到位，容易犯“只見樹木不見森林”的錯誤，往往會使軟件需求埋下缺陷，例如，采用先進的技術姑且可以增強功能，但有些功能在航天器上可能是多余的，而這些附加的功能不僅消耗了大量的系統機、電、熱資源，還有可能帶來“多余物”的危害；又例如，為了實現某項功能，采用了高性能芯片，但由于協議不匹配，重要數據無法實時下傳。這樣的例子在從研發階段轉為工程階段時常出現。

基于信息流分析的軟件需求分析方法可以在很大程度上避免上述弊病，它是以信息流作為明確軟件輸入、輸出、接口時序分析的突破口，為星載軟件需求分析提供有力的系統級支持。首先在總體方案、分系統和單機設計的同時，并行開展整星信息流分析（見圖1（b）），即設計一個信息流通道、節點組成關系的方案，確保信息流網絡構架滿足信息需求和航天器總體設計需求。為了保證架構合理，建議使用分級設計方法，先進行一級總線設計，再進行二、三級總線設計。首先，在設計時應規劃與嵌入式軟件的中斷、任務優先級的相對關系。其次，進行信息接口設計，設計出合理的接口功能，確定傳輸數據、傳輸周期、接口時序，通過該項分析，涉及到的嵌入式軟件的任務、時序應基本確定。在分系統總線設計后，形成各個單機的功能性能需求。最后，基于信息流分析結果和單機任務要求，確定軟件配置項的需求。

圖1 兩種軟件需求分析方法Fig.1 Two methods of software requirement analysis

3 基于信息流的軟件需求分析實例

3.1 信息流分析

在本文的例子中，信息流分析時按兩級信息總線加以分解，有必要時可以向下再擴展到三級，如載荷系統內信息流等。

3.1.1 一級總線架構分析

本文涉及的某衛星總體設計，確定采用1553B作為系統的數據主干路，把分配在各艙位的遠置終端單元（Remote Terminal Unit，RTU）和具有連接總線能力的分系統與數管計算機——中央終端單元（Center Terminal Unit，CTU）連接成系統，它在物理上是一條實實在在的數據串行總線，在信息流分析中是系統信息的一級總線。CTU作為總控端（BC），數據管理分系統的RTU A/B、其他分系統的計算機作為終端（RT）。CTU與RTU A/B協作，實時地完成衛星數據采集、數管指令存儲、處理和分發、分系統工作狀態的自主監控、自主熱控、電源自主管理以及控制分系統重要數據存儲轉發功能。RTU A/B完成包括定期循環采集各分系統的遙測參數，并通過1553B總線送給數管計算機，對總線接收的指令進行校驗、譯碼并執行。

除了RTU A/B，還應分析總線上是否需要連接其他分系統的重要計算機。例如控制、電源、熱控、有效載荷如何與CTU進行數據交互?？刂品窒到y計算機作為衛星的控制核心，接收地球敏感器、太陽敏感器、陀螺數據，控制太陽翼驅動裝置（SADA）、動量輪、10 N推力器等執行機構，同時完成故障診斷與處理、遙控、遙測及程控功能，因此與CTU應具備一級總線接口。某載荷子系統上下行數據量較大，載荷設備A需要通過CTU完成與地面的數據通信。

各RTU完成各分系統遙測信息的采集和遙控指令的發送。因此，各RTU與各分系統有信息接口，考慮分級設計方式CTU不需要設計直接與各分系統數據的接口。遙控單元完成對上行通信的業務操作，包括副載波信號的解調，信道譯碼及地址識別，將解析出的指令發送給CTU。同時對于數管計算機將編排好的遙測數據發送給遙測單元，由遙測單元完成副載波調制等下行業務［7］。

通信衛星通過1553B總線進行星上數據交換，采用互為備份的雙總線冗余結構（即A總線和B總線），在信息傳輸超時或出錯情況下，由CTU軟件進行容錯管理，確定重新傳輸或切換另一條總線的機制。因此一級總線如圖2所示。

圖2 信息流一級總線（1553B）架構Fig.2 First grade（1553B）information bus

3.1.2 二級總線架構分析

RTU A設計有8個串行接口，可以輪詢完成與8臺設備的雙向通信。有效載荷設備B/C/D/E通過串口1—4完成與RTU A數據交換，其余4個串口備用，如圖3所示。它們在物理上是一組串口，但在信息流分析中可視其為二級信息總線。

RTU A在接收CTU的指令，驗證正確后，根據設備地址轉發給相應的有效載荷設備，各載荷設備在收到指令數據后，對數據的有效性進行判斷，包括判斷設備地址及校驗和的正確性，并執行有效的指令。

同時，RTU A采用輪詢的方式，依次向有效載荷設備發送采集數據命令信息，完成相應的遙測數據的接收，將編排后的數據轉發給CTU。如在規定時間內未采集遙測信息則向CTU報警，保證系統傳輸的實時性。

圖3 信息流二級（RTU向下）總線構架Fig.3 Second grade（RTU down）information bus

3.2 信息接口設計

3.2.1 一級總線接口

經上述總線架構分析，按照信息流歸納出CTU通過一級總線通信完成以下功能，信息接口見表1。

（1）發送常規指令至RTU A/B（常規指令指數據指令和離散指令）；

（2）采集RTU A/B的常規遙測數據（常規遙測包括模擬量、溫度量、雙電平量等）；

（3）通過RTU A轉發有效載荷指令；

（4）通過RTU A采集有效載荷遙測；

（5）完成與控制計算機的數據交互，實現數管分系統與控制分系統的數據備份；

（6）完成與載荷設備A的數據交互，實現對載荷設備A的程序、數據注入。

表1 1553B總線接口信息Table 1 Interface Information of 1553B

3.2.2 二級總線接口

RTU A將CTU的指令解析后，確定向某臺載荷設備發送指令信息，并配置相應的串口，向該串口發送指令信息。該載荷設備收到串口信息后，解析指令并執行后，向RTU A發送相應信息。同時載荷軟件編排設備的遙測信息，在RTU通過串口發送“采集遙測數據”的指令后，將約定好的遙測信息發給RTU A。RTU A轉發給CTU后，通過遙測單元下傳地面。按照信息流分析得到的二級總線信息接口見表2。

表2 串行總線接口信息Table 2 Interfaceinformation of serial bus

RTU A在數據的發送上采用不定長方式，按照串行通信協議設計波特率為9600 bit/s，數據位為8位，無奇偶校驗位，先傳高字節后傳低字節的方式進行傳輸。RTU A為控制端，所有載荷設備均為被控端，并為各處理設備分配地址。

3.3 形成軟件系統信息流圖

經上述分析，各單機軟件功能基本確定。CTU軟件完成與RTU A/B的通信，包括指令注入、遙測數據、1553B總線通信，與控制計算機通信，及其數管內務管理等，與載荷設備A通信，完成對載荷設備A的程序、數據注入。

RTU A/B軟件完成各分系統模擬量、溫度量、數字量的采集及編排，發送給CTU；對總線接收的指令進行校驗、譯碼并執行；RTU A通過串口轉發載荷設備的指令，采集遙測信息。

控制分系統軟件完成采集太陽敏感器、地球敏感器、陀螺等敏感器信息和動量輪轉速信息，計算出控制量送給動量輪和推進分系統。完成衛星在軌模式控制功能，同時完成故障診斷與處理、遙控、遙測及程控功能。與數管計算機互相保存重要數據供出現故障時使用。

全系統軟件的信息流如圖4所示（不包含有效載荷等軟件的設計結果），它是在系統級信息流分析基礎上形成的（本章節只對軟件進行概述，未給出詳細的軟件系統分析結果）。

3.4 以信息流分析結果開展軟件需求分析

在進行分系統設計后，形成各個單機的功能性能需求，結合信息流分析結果，開展軟件配置項需求設計。

以RTU A軟件為例，從整星信息流分析結果來看，除完成自身的參數初始化外，需要完成以下4項功能:①發送串口指令至各載荷設備；②發送常規指令至各分系統；③采集各分系統常規遙測并發送至CTU；④采集各載荷設備串口遙測并發送至CTU軟件數據流（見圖5）。根據整星的任務分析，RTU A首先保證遙測信息發送，因此遙測發送設置為一個外部中斷，且優先級最高。在每個中斷觸發前，需要準備好常規遙測并組包。設計總線指令接收中斷，接收CTU發送的指令數據包，解包后將不同的指令進行相應的處理和執行。RTU A在采集遙測數據的間隙，如果有串口有效載荷指令，則發送串口有效載荷指令至相應的串口。若此周期內無串口指令，則依次向有效載荷設備發送采集遙測的信息。

軟件各模塊頂層設計如下，包括兩個外部中斷0和1，用于發送遙測數據至CTU和接收來自CTU的指令數據包。設置4個任務:①發送硬件指令至各設備；②循環接收各串口遙測；③發送串口指令；④執行軟件指令，即地面控制端需要RTU軟件完成的命令。其他主要工作包括參數初始化，軟件自檢，定期啟用“看門狗”，組包遙測數據和數據指令解包，這些工作在后臺進行，即主程序中循環完成，如圖6所示。

圖6 基于信息流分析的RTU A軟件需求設計Fig.6 Software requirement design base on information flow analysis

通過以上工作，軟件的主要功能、性能、輸入、輸出、數據處理、接口等指標和要求均已明確，軟件需求分析工作完成，可以根據分析結果進行RTU A軟件配置項的設計開發工作。

4 結束語

本文提出了一種基于信息流設計的軟件需求分析方法，與傳統軟件需求分析方法相比，它能夠以系統信息流為脈絡牽動各軟件需求，從而全面反映系統、分系統與單機的需求，為高質量的軟件設計提供系統級的有力支持。并以通信衛星為例，詳細介紹了衛星設計階段的軟件需求分析全過程，首先進行信息流分析，再進行信息接口設計，確定整星軟件接口，結合硬件設計，形成詳細而準確的軟件用戶需求。經過衛星研制過程的設計驗證和在軌飛行驗證，基于信息流設計的軟件需求方法合理可行，可優化軟件設計流程，有利于采用更合理的軟件架構、開發環境、硬件芯片資源。

隨著高性能嵌入式軟件、數字處理芯片、FPGA處理芯片在航天器上的廣泛應用，通過數據、程序上注的方式更新軟件，可以解決軟件固有的缺陷，也可以根據在軌應用時用戶的反饋意見，提升軟件的性能。開展基于信息流的軟件需求分析工作，可以從方案階段確保數管計算機支持上注信息，實現星載軟件的在軌維護功能，提升衛星系統設計的靈活性。

（

）

［1］侯成杰.國外航天軟件故障原因分析［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］王振華，張維瑾，張國峰，等.航天星載軟件項目質量管理的思考［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］譚維熾.胡金剛.航天器系統工程［M］.北京:中國科學技術出版社，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

連卉，女，碩士，從事衛星軟件總體設計、測控信息設計研究工作。Email：lianhui2008@sohu.com。