大型火箭發動機地面試驗系統測控軟件架構設計

許廣柱，吳錦鳳

（西安航天動力試驗技術研究所，陜西西安710100）

0 引言

大型火箭發動機地面試驗測控系統設計分硬件和軟件兩部分。由于目前國內外大部分工業測控硬件都已有系列化的成品設備儀表，所以在硬件設計過程中，絕大部分工作是這些設備儀表的線路連接和硬件分布式設計，而大部分軟件設計都是根據不同類別火箭發動機試驗系統特點有針對性地自主編寫。因此，地面試驗測控系統軟件設計在整個試驗系統中的重要性和比重越來越大，其難度也與試驗系統規模密切相關。對大型火箭發動機地面試驗系統而言，由于試驗涉及參數種類繁多，其測控設備和子設備數量龐大，所以，軟件的結構和開發模式對整個測控系統的使用效率、工作人員配備以及試驗效果等有著決定性的影響。

1 大型火箭發動機地面試驗系統現狀

大型火箭發動機地面試驗系統一般包括：火箭發動機、推進劑供應系統、環境模擬系統和測控系統四部分。其中，發動機推進劑供應系統負責提供燃料和氧化劑；環境模擬系統模擬高空或者真空等環境以實現地面的模擬環境試驗；測控系統負責發動機試驗過程的控制和參數測量。

試驗系統概括起來有如下幾個特性：

測控系統測量參數種類眾多，一般包含壓力、溫度、流量和振動等參數，幾乎涵蓋所有的工業測量參數；

參數物理量范圍大且同種參數的測量傳感器類型繁多。如壓力可以從1 Pa～60 MPa、溫度可從-260℃～3 000℃；一次試驗中測控使用到的溫度傳感器類型可能有鉑電阻、熱敏電阻和各種熱電偶等多種。

由于以上這些特性，導致了系統分類/分組測控困難及設備數量龐大等問題，相應地也給測控軟件設計編寫帶來很多困難。到目前為止，國內大型火箭發動機地面試驗測控系統軟件基本上都是直接根據硬件分系統類型一對一的設計編寫，也就是說，有多少個測控分系統就有多少個應用軟件，而且很多院、所在測控軟件設計上都采用一個分系統由一個設計人員從頭到尾設計編寫整個應用軟件的方式，甚至每個設計人員之間沒有協作和溝通，編寫出來的應用軟件風格不同，通用性差。這種軟件開發模式很明顯不利于維護和操作人員培訓交接等后續工作，更不利于軟件故障診斷和定位。圖1是大多數大型火箭發動機地面試驗測控系統設計采用的架構示意圖。

對于火箭發動機試驗測控系統來說，對象群是指被控制/測量的各種物理參數（如：閥門開關、壓力、溫度和流量等）分類/分組對象。其中軟件部分大多采用以下軟件開發模式（以下簡稱為常規開發模式）：圖2是常規控制軟件功能框圖，圖3是常規測量軟件功能框圖。

常規開發模式中，采用的是過程式程序設計，所有程序流程都是按照操作過程設計編寫的。很顯然，其中有很多重復功能代碼，且由于很多實際設計中不同軟件人員設計編寫整個程序，無法統一規劃和管理，而在軟件規模控制上，只有通過減少控制/測量對象，群的數量才能減少，操作人員的數量相應變化。從大型火箭發動機地面試驗系統幾個特性可以看出，由于控制及測量的參數和對象數量龐大，參數種類繁多，難以按“群組”分組測控，影響測控歸一化管理，相應地測控分系統數量n就會多（n≥3）。因此，在不減少測控分系統數量的前提下，這種程序設計范型效率低且控制難度大。

2 面向過程和面向對象設計方法比較

面向過程設計方法是一種自上而下的傳統設計方法，上面提到的常規開發模式就是面向過程的設計模式。其特征是以函數為中心，細化函數來劃分程序的基本單位，數據在面向過程設計中往往處于從屬的位置。這種模式的優點是易于理解和掌握，逐步細化問題的設計方法和大多數人的思維方式比較接近。然而，面向過程設計對于比較復雜的問題，或是在開發需求變化比較多的時候，往往顯得力不從心。這是因為過程式設計是自上而下的，它要求設計者在一開始就要對需要解決的問題有一定程度的了解。在問題比較復雜時，要做到這一點比較困難，而當開發中需求變化的時候，以前對問題的理解也許會變得不再適用。事實上，開發一個系統的過程也是對一個系統不斷了解和學習的過程，而過程式設計方法忽略了這一點。另外，過程式設計還有個問題就是其設計的程序架構的依賴關系問題。主函數依賴子函數，子函數依賴更細小的子函數。最底層的子函數其實就是需求細節的實現，而這些實現因需求變化而常常變化，這樣的結果導致整個程序的核心邏輯依賴于外延的細節，本應該穩定的程序核心邏輯也因此依賴關系變得不穩定。合理的依賴關系應該是反過來：細節實現依賴于核心邏輯。

面向對象（Object Oriented）設計是一種自下而上的設計方法。設計過程一般從問題的一部分著手，逐步構建出整體。面向對象設計以數據為中心，類作為表現數據的工具，是劃分程序的基本單位。函數在面向對象設計中成為了類的接口。由于面向對象這個自下而上的特性，允許開發者從問題的局部開始，在開發過程中逐步加深對系統的理解。這些新的理解以及開發中遇到的需求變化，都會再作用到系統開發本身，形成一種螺旋式的開發方式。面向對象程序設計中，類封裝了數據，類的成員函數作為其對外的接口，抽象地描述了類。用類將數據和操作這些數據的函數放在一起，就是面向對象設計方法的本質。引入面向對象的繼承特性，可以將設計中越來越多的模塊之間的依賴型簡化，使整體設計的核心健壯穩定，架構清晰明朗。

由于面向對象設計體現了數據的封裝，避免以前過程式設計方法中任何代碼都可以隨便操作數據而造成的缺陷，而查找修改這種缺陷是非常困難的。面向對象設計方法在軟件體系結構方面是強制性的，從而在程序編譯階段就可以解決惰性問題，而不用在程序運行階段再去查找問題。

3 RUP和“4+1”視圖建模簡介

RUP （Rational unified process）即 Rational統一過程（又稱統一軟件開發過程），是一個面向對象且基于網絡的程序開發方法論，其核心思想是：盡早并且持續地化解重大風險，確保滿足客戶需求，重點放在可執行軟件上，盡早在項目中適應變化，在早期確定一個可執行的架構。基于RUP進行軟件建模帶來的好處也在于此。

Philippe Kruchten提出的“4+1”視圖模型由5個主要視圖構成：用例（場景）、邏輯視圖、過程視圖、物理視圖和開發視圖，目前已被RUP采納，成為架構設計的標準。通過此視圖模型進行軟件面向對象分解后建模，可以提高軟件的復用性、擴展性和可維護性。

4 地面試驗測控系統軟件建模

綜合面向對象、基于RUP的“4+1”視圖模型和地面試驗系統測控軟件開發經驗，對大型火箭發動機地面試驗測控系統軟件進行“4+1”視圖建模，可以得到很好的軟件架構。由于控制和測量在原理上有較大區別，所以在設計上還是采用相對獨立的原則。

設計從各個基本功能元素入手，編制相對獨立的完整功能類（class）或結構（struct），通過各自的接口函數構成程序各功能結構模塊。圖4是控制系統軟件過程視圖，控制時序部分是控制程序的中心，它對系統主控邏輯進行分析、判讀和邏輯輸出，板卡的控制采用命令方式，解析后通過硬件接口與硬件板卡交互數據，控制命令是根據硬件配置生成的規范化硬件控制命令包，比如：主控時序需要控制參數Param1對應的電磁閥關閉 2 s，命令包就如 CLOSE@SLOT_1@Param1@2這種形式，經過命令解析后發送給硬件接口，板卡就會執行此命令關閉SLOT 1槽位上板卡中Param 1電磁閥對應端口電平2 s；通過板卡的數據反饋及時獲取數據后進行數據處理并存儲，再通過消息的方式實時顯示主控時序的執行過程，實時顯示的具體形式是根據事先配置定制的諸如流程顯示的圖形。

測量軟件中心是數據處理功能塊，所有的數據都是通過它與其他模塊交互。圖5是測量系統軟件過程視圖。所有實時數據的獲取都是通過數據實時采集模塊進行的，它直接控制硬件并交互數據；內存池非常重要，它作為采集數據的緩沖區臨時存儲數據，是所有功能模塊的數據源；數據算法根據需求定制不同的數據處理函數，包括各種處理公式、數據輸入接口、數據輸出接口和異常數據剔出處理等，由數據處理模塊根據人機交互的請求實現不同的數據處理功能；數據處理模塊將眾多的功能請求（比如：試驗數據采集、參數校準、存儲數據和打印報表等）集中，通過主線程人機交互模塊中介，實現相應的處理；實時顯示通過消息的方式從主界面獲得數據并顯示相應的需求圖形；數據存儲模塊分為實時數據存儲和事后數據存儲，實時數據通過本地硬盤進行二進制文件形式存儲，事后數據處理的數據一般采用數據庫存儲方式，模塊必須實現所有的數據庫操作和數據的封裝。測量軟件與控制軟件設計不同在于數據處理需求多且復雜，因此，在數據處理需求分析過程中，必須細化各種需求，分類匯總，構建健壯的類模塊。

圖4和圖5的視圖模型適用于測控分系統軟件設計和整體設計。如果測控硬件設備屬于同一公司產品，因軟件平臺統一，一般情況下可以將所有分系統軟件合并為一個應用軟件，設計中只需對各個模塊功能依據板卡驅動或者板卡執行命令來擴展功能即可，整體設計建模完全不需要改動，軟件的擴展維護很顯然是非常容易的。如果測控分系統硬件設備分屬不同公司，軟件平臺可能不一致，導致不能合并分系統軟件程序，但每個分系統軟件的設計模型仍可采用上述建模，因建模統一，在使用過程中擴展維護也比較簡便。

通過在硬件結構上的調整，采用分布式測控設備和以太網構建局域網的方式，相應測控軟件在以上視圖模型基礎上稍作調整即可形成高效的軟件架構。圖6是基于以太網的控制系統軟件體系結構示意。考慮到控制系統的實時性，將軟件配置和邏輯控制通過主控端分發給各控制分系統軟件，分系統對時序分析后直接進行實時控制操作。

基于以太網的測量系統軟件體系結構如圖7所示。測量分系統機將測量所得數據通過以太網傳送給服務端，所有數據分析和處理均由服務端程序執行。

通過統一軟件建模，不論控制系統軟件還是測量系統軟件，由設計人員根據需求制定編寫規范和接口，每個功能模塊都應分解并采用面向對象編程進行數據封裝設計。利用面向對象編程語言（如：C++和C#等）進行類模塊代碼編寫，規范化類實例繼承特性。在代碼編寫過程中，避免大量使用全局變量；對于父類的設計，注意總結歸納，利用面向對象的多態特性，在子類里編寫細節實現代碼。對于模塊的發布方式，盡量采用動態鏈接庫的方式，這樣可以做到改動一個對象實例功能代碼，只需要重新編譯此對象模塊即可，其他模塊完全不需要改動。為了規范化代碼編寫過程，有必要制定統一的代碼編寫規范，按要求注釋代碼功能，建立代碼修改日志文檔，這對于系統軟件的功能修改、擴展和發布等有很大的幫助。圖8是基于“4+1”視圖模型建模后整個火箭發動機地面試驗測控系統的架構示意圖。

由圖可看出：將以前復雜眾多的分系統軟件分解和歸納，總結其特征并統一設計結構，可做到所有控制分系統和測量系統也只由一套測量軟件進行后臺操作，最終在整體層面上，只需要兩個系統應用軟件和相應的操作人員即可。

參考開發規范，火箭發動機地面試驗測控系統軟件設計需確定一個設計小組分工設計軟件，每個模塊設計都需要分工協作，好的模塊接口是整體應用便利、日后維護和故障定位的前提。

基于RUP的“4+1”視圖模型建模方法給出了粗線條的整體設計方式，在實際操作中，各系統的功能模塊還需要根據需求再分解，以達到整體設計的高重用性、高可靠性和高效性的效果。

5 結束語

綜上所述，依據統一軟件開發過程和面向對象設計思想，借助目前各種優秀的面向對象編程語言，可以為大型火箭發動機地面試驗測控系統軟件設計帶來較好的效果，在設計過程中就能最大程度地避免風險和適應工程項目的需求變化，從而在工程早期就確定一個可執行的軟件架構，提高測控軟件使用效率、減少操作和維護人員、更好的故障定位和系統擴展。

[1]比約尼爾（德）.軟件工程卷1～3[M].劉伯超,譯.北京:清華大學出版社,2010.

[2]何炳林,張煥文,梁柱揚,等.基于ADS1252的數據采集模塊設計[J].現代電子技術,2011,34(13):139-141.

[3]邵維忠,楊芙清.面向對象的系統分析,面向對象的系統設計[M].北京:清華大學出版社,2003.

[4]KRUCHTEN P.The 4+1 view model of architecture[J].IEEE Software,1995,12(6):42-50.

[5]張磊.基于FPGA與PCI總線的實時控制計算機的設計與實現[J].電子設計工程,2011,19(20):173-180.

[6]KRUCHTEN P H,THOMPSON C H.An object-oriented,distributed architecture for large scale Ada systems[C]//Proceedings of the TRI-Ada'94 Conference.Baltimore,USA:ACM,1994:262-271.

[7]張春祥.軟件體系結構理論與實踐[M].北京:中國電力出版社,2011.

[8]毛頓,郭慶平.LabVIEW中用DataSocket技術實現網絡化應用[J].現代電子技術,2002(3):70-71,85.

[9]楊海成.航天型號軟件工程[M].北京:中國宇航出版社,2011.

[10]孫誠,王雪梅,張艷紅.連接計算機并口的數據采集系統[J].電子設計工程,2011,19(16):48-50.