基于麒麟操作系統的運載火箭地面測試系統設計

，，

(裝備學院 航天裝備系，北京 101416)

0 引言

由于我國電子元器件工業基礎相對薄弱，運載火箭地面測試系統使用的各類進口軟硬件設備、核心元器件和高端通用芯片長期依靠進口，但西方發達國家經常采取禁運、限購等方式遏制該類產品在我國航天領域的應用，同時，國外相關軟硬件設備還存在價格高昂、性價比低下、訂貨周期長、購置渠道不暢、代碼不開放、技術服務不可控等問題[1]，對我國運載火箭地面測試系統的安全性、可靠性構成嚴重威脅。為從根本上解決這一問題，必須對運載火箭地面測試系統進行自主可控設計。麒麟操作系統作為核高基的重點研究項目，以兼容Linux的技術思路開發的高安全、高可用、高性能、高可定制的國產操作系統，目前已成功應用于國防、政務、能源、交通、航天、等眾多行業和領域[2-3]，但在運載火箭地面測試領域的研究尚未深入展開。

目前，我國運載火箭地面測試系統主要基于Windows操作系統開發研制，如某型火箭數字筆錄儀、數字化箭地信息檢測分析系統等。本文結合自主可控技術，在對我國運載火箭地面測試系統研究的基礎上，設計了一套基于麒麟系統的運載火箭地面測試系統。系統采用本文提出的數據庫+二進制文件的存儲方案管理數據，以及數字化的變頻采樣策略對數據進行采集，并對麒麟系統下采集設備的驅動程序進行了重新設計。經過系統測試，麒麟系統下的運載火箭地面測試系統實時性以及網絡性能，與Windows下的同類產品性能相當，滿足運載火箭地面測試需求。

1 系統設計

近年來，通過國家“核高基”科技重大專項帶動，國內自主可控關鍵軟硬件技術取得了重大突破，研制出了一批具有代表性的基礎軟硬件產品，例如飛騰處理器、麒麟操作系統、人大金倉數據庫等，國產軟硬件產品的安全性得到較好的保障，可用性得到較大的提升，性能在一定程度上滿足使用要求，為運載火箭地面測試系統的自主可控設計提供了可能。

1.1 系統結構

測試系統包含硬件和軟件兩部分，其中硬件組成包含基于國產龍芯3A模塊的箭上測量設備，銀河麒麟計算機的地面測發控系統后端機，以及基于麒麟操作系統的前端CPCI總線工控采集機。

嵌入式箭上測量遠置端設備主要負責箭上關鍵信號的隔離調理、采集、存儲與傳輸；前端CPCI總線工控采集機主要負責箭地測發控系統關鍵信號的接入、隔離調理、采集、發控配電功能等；后端設備主要用于處理、分析前端發送來的測試結果并將其按要求進行顯示。前、后端，嵌入式遠置端與后端通過網絡交換設備或光纖進行通信。

為了盡可能的對國產化軟硬件在航天發射場合的應用進行驗證，本系統信號輸入包括低頻模擬信號、數字脈沖信號。輸入信號經前端采集機或嵌入式遠置端機箱內的隔離調理模塊調理，模擬信號由自主PCI總線或USB總線采集卡采集，數字信號由自主數字I/O卡采集，并與主板模塊進行交互，由中央處理器處理。一方面，采集信息將轉換成用戶可用的圖形傳輸至前端顯示模塊進行顯示，另一方面，測試數據在前端或遠置端存儲的同時，通過網絡傳輸至后端控制機進行實時顯示、控制與在線判讀。用戶可通過控制機對整個系統進行測試控制，完成測試過程。系統的工作流程如圖1所示。

圖1 系統工作流程圖

1.2 系統硬件設計

系統的嵌入式遠置端主要用于模擬未來自主可控的箭上測量系統，其硬件設計包括信號輸入插座、隔離調理電路、嵌入式計算機平臺(ARM)， USB總線模擬信號采集卡、USB計數/定時器卡、網絡接口、存儲單元等部分組成。系統前端采集部分硬件由信號輸入電纜、接插件、CPCI總線工業控制機箱、計算機卡、激勵信號源、信號采集卡、數字I/O卡、信號隔離調理處理模塊和繼電器組等單元組成。系統前端采集部分通過多條電纜與箭上系統信號轉接箱相連。

系統采集的模擬、數字即開關信號多達700余路。其中，模擬信號由兩塊PCI采集卡獲取，數字、開關信號則通過以FPGA為核心的數字I/O卡以及脈沖計數卡采集。

模擬信號需要顯示的通道數較多，數據量比較大，傳統但緩存采集數據處理效率低，數據處理量受設置的緩沖區大小的限制，為提高數據處理效率，模擬信號的采集采用雙緩沖采集模式。雙緩沖模式是將緩沖區以循環的方式分成上下兩半。雙緩沖采集開始時，設備開始寫數據到上半緩沖區，在設備開始寫下半緩沖區時，可以處理上半緩沖區的數據，上下緩沖區交替存儲，可以存儲無限多的數量，提高了緩沖區利用率。

所有測量信號在調理輸入端設計隔離電路，保證箭體和采集設備之間完全電氣隔離，減少箭體和采集設備兩者之間的串擾。系統硬件框圖如圖2所示。

圖2 系統硬件框圖

1.3 系統軟件設計

麒麟操作系統為整個軟件系統提供包括內核、設備驅動、通信協議、圖形引擎等，是應用軟件運行環境的重要組成部分，為上層應用軟件提供對底層物理硬件的抽象和封裝，組織和管理軟硬件資源，控制程序執行流程，提供系統調用接口、驅動程序等，為方便與其他軟件(如嵌入式數據庫、集成部署框架)集成，操作系統還為上層軟件提供標準的硬件訪問接口和其他的基本操作系統服務。

為了實現系統長時間大容量采集以及綜合處理分析的需要，系統使用支持國產麒麟操作系統的QT集成開發環境進行軟件開發。為了縮短開發周期及便于后期維護，系統軟件采用自頂向下與模塊化設計相結合的方法[4]，采用單文檔結構，并提供各種快捷工具條和按鈕等，完成采集、圖形實時顯示與存儲、事后回放、數據判讀等功能，實現采集過程中的無人值守自動監測與人工控制相結合。

軟件主要包括文件操作、參數設置、采集顯示、數據處理4個功能模塊。其中，單個視圖利用qwtplot插件完成信號曲線的顯示，單屏4*4共16個視圖，并且利用XianshiSetDialog類進行界面X方向和Y方向視圖數量的顯示。利用XinhaoSetDialog類對信號的顯示區域，信號曲線顏色以及通道的測量范圍進行設置。QTcpSocket類實現前后端的信息通信，軟件發出的所有動作均通過信號與槽的方式與相應函數連接。軟件功能總框圖如圖3所示。

圖3 系統軟件功能總框圖

2 關鍵技術

運載火箭地面測試系統采集的信號通道數達700余路，將產生大量的數據信息，并且不同通道間采樣頻率不同，給測試數據存儲及變頻采樣帶來很大難度。另外，系統硬件與軟件之間連接的核心部分是驅動程序，需要進行麒麟操作系統下的驅動程序設計。因此，在具體設計過程中會遇到多方面技術難點，例如：測試數據存儲、變頻采樣、驅動設計等。

2.1 測試數據存儲

目前，運載火箭地面測試系統的前端和后端主要以二進制文件形式保存數據，這種方式不利于數據的查詢與管理，數據庫在數據管理方面具有獨特的優勢，在工業測試系統中廣泛應用。國產數據庫有達夢、神通、人大金倉等[5]。神通數據庫支持SQL通用數據庫查詢語言，提供標準的ODBC、JDBC、OLEDB/ADO和.Net DataProvider等數據訪問接口，并具有海量數據管理和大規模并發處理能力，已經在政府、電信、電力、國防、軍工、教育等行業得到了大量應用。為了解決現有地面測試系統不便于數據管理問題，筆者設計了一種數據庫+二進制文件的測試數據管理方法。

在數據存儲方面有文件存儲和數據庫存儲兩種方式。文件存儲中，由于二進制文件具有占空間小、讀取和存儲速度快等優點，在容量數據存儲中被廣泛使用，但不便于數據的檢索。數據庫存儲具有便于數據管理、數據查詢等優點，其機制主要是先將數據寫入緩存空間，然后再從緩存空間寫入到數據庫中[6]，如通過內存緩存機制，由于運載火箭地面測試系統數據實時采集時，需要頻繁的對數據庫進行操作，而數據存入數據庫所消耗的時間較長，容易造成數據丟失。因此在存儲頻率高的情況下使用內存緩存機制并不合適。將1 000個float數據寫入數據庫需要約13 s，而文件只需要2 ms。就存儲空間而言，文件存儲100個數據需要1 KB空間，因此存儲5 000到10 000個數據只需要50～100 KB的空間。

鑒于以上問題，為了兼顧二者優點，系統前端由于空間有限仍然采用二進制文件存儲方案，系統后端采用二進制文件與數據庫結合的方式存儲數據，即測試數據保存在二進制壓縮文件中，而數據的索引保存在神通數據庫中。地面測試系統數據采集的通道號是唯一的，將某次的二進制數據文件以相應通道號命名，建立起二進制數據文件與索引之前一一對應的關系，對數據文件進行索引。這種數據庫+二進制文件的存儲方案兼顧了二者的優點，可更加高效的管理數據。

2.2 運載火箭測試系統數字變頻采樣方法

目運載火箭地面測試系統采集的信號包括模擬電壓信號、脈沖計數信號、不帶電觸點信號和時序開關信號，共計700余路，測試時間長達10小時以上，將產生大量數據信息，并且不同通道間采樣頻率不一樣。因此，變頻采樣技術是研究的重點。

變頻采樣一般有兩種實現方式：一種通過改變底層配置函數、AD時鐘的方法，屬于傳統變頻采樣策略。這種方式一般是對所有通道頻率整體修改，工作效率低，不能適應采集通道數多，頻率改變頻繁的測試試驗要求。同時頻繁改變硬件的采集頻率，可能降低采集系統的可靠性。另一種是數字變頻采樣方式，核心思想是高速采樣、選擇性存儲，即以固定采樣頻率進行采集，得到完整的數據源，根據不同采樣頻率需求，改變數據寫入存儲器的頻率實現抽點存儲，達到變頻采樣的目的[7]。這種方式避免了頻繁的硬件底層操作，工作效率以及系統可靠性更高，相比傳統變頻采樣，數字變頻采樣更加適用于運載火箭地面測試系統。

運載火箭地面測試系統變頻采樣實現方法如下。以1 000 Hz實際頻率采集數據，將數據按通道分別存儲至相應緩存中，根據各通道設置的采樣頻率獲取每次需要存儲的有效數據，達到變頻采樣的目的。數字變頻采樣的數據先存儲至緩存空間，再存儲至存儲器，通過改變存入存儲器的頻率實現變頻采樣。采樣頻率在低速和高速之間變換時，會存在數據丟失問題[7]。由低速采樣過程到高速采樣過程中，當t1時刻觸發時，數據以高速存入存儲器，此時t1時刻之前的一段數據保存在緩存器，保證了兩個交替子過程之間數據的有效存儲，保證信號完整、有效。由高速采樣過程到低速采樣過程中，當觸發后以較低速率存入存儲器的數據時，會造成觸發時刻之前的高速采樣數據丟失，此時延遲改變存儲器的寫入速率，保證緩存器中的數據(觸發時刻之前的一段高速采樣數據)正確、有效的寫入存儲器，這樣可保證信號完整、有效。

2.3 驅動解決方案

系統硬件與軟件之間連接的核心部分是驅動程序，然而由于通用采集設備多依賴Windows操作系統，其驅動程序與應用函數庫多是基于Windows操作系統定制，為了能夠使自研或通用數據采集設備能夠在基于麒麟操作系統的平臺上順利運行，必須要對相關的驅動程序進行匹配或者重新開發。

為提高系統工作效率，實現高速穩定傳輸目的，驅動采用DMA傳輸方式[8]。這種基于Linux 設備驅動的一大特點是可以以模塊的形式加載各種設備類型。用戶根據需要，在不對內核重新編譯的情況下，將設備驅動模塊動態地載入內核或從內核移出。采用模塊化的設計方案，主要分為初始化模塊、內存讀寫模塊、I/O操作模塊、配置空間訪問模塊以及中斷模塊。

基于Linux的麒麟操作系統中，中斷服務并不是直接從中斷向量表中調用，而是先接受來自硬件的中斷，再由系統調用中斷服務子程序。數據采集數量滿足采集要求后，采集卡會產生一個中斷，通知進程啟動DMA傳輸，進行讀寫操作。

在運載火箭地面測試中需要大量的數據傳輸，這就需要若干輪次的DMA傳輸。每一輪的DMA傳輸完畢后，驅動便處于外部中斷等待狀態。外部中斷觸發后，應用程序接受中斷并判斷是否需要續傳，若需要DMA進行新一輪的數據傳輸，否則釋放資源關閉設備，結束傳輸。DMA傳輸及中斷流程圖如圖4所示。

圖4 DMA傳輸及中斷流程圖

3 系統測試

由于自主可控軟硬件技術水平還有待完善，并且系統中核心元器件難以替代，因此系統各模塊間的匹配會存在很多問題，系統的測試工作十分重要。對系統進行以下測試：

3.1 實時性驗證

利用Cyclictest實時性能測試工具，利用麒麟操作系統提供的定時器和計數器，通過設置線程的數量以及優先級等參數，測試計算機的響應能力，其中最小時延20 μs，最大時延280 μs，平均時延32 μs。Windows平臺下的地面測試系統最

小時延8 μs，最大時延215 μs，平均時延21 μs，麒麟系統下的地面測試系統時延較大，但是滿足地面測試需求。

3.2 基于網絡的遠程化測試能力驗證

地面測試系統前端作為服務器端，后端作為客戶端，IP地址設置完成后，在測試系統各臺計算機上，通過應用ping手段測試和檢查網絡連接正常，前端和后端數據收發正常。同時利用支持國產系統和Linux系統的Iperf網絡性能測試工具對數據收發負載相應能力和組播能力進行測試。對于TCP協議，可以測量網絡帶寬，報告MSS/MTU值的大小和觀測值，支持多線程。經測試，麒麟系統下的運載火箭地面測試系統網絡帶寬約為50 Mbit/s，Windows平臺下的地面測試系統網絡帶寬約為45 Mbit/s，二者網絡性能相當。

3.3 數據存儲與查詢功能測試

由于數據仍以二進制文件的形式保存，因此數據存儲速度與現有地面測試系統存儲速度相當，滿足每秒1000個數據的存儲需求，同時，系統兼有了數據查詢功能，實現了以通道、日期、數據類型查詢數據的功能，增強了系統的數據管理能力。

4 結論

本文結合我國運載火箭地面測試需求，設計了一套基于麒麟操作系統的運載火箭地面測試系統，對系統結構，硬件設計以及軟件設計進行了詳細介紹，并針對其中涉及到的關鍵技術提出了解決方案。測試結果表明，麒麟系統下的運載火箭地面測試系統的實時性以及網絡性能滿足運載火箭地面測試需求，對運載火箭地面測試系統的自主可控研究具有重要的現實意義。

[1] 畢錦棟, 鄭麗香, 周軍連,等. 電子元器件國產化替代工作探討[J]. 質量與可靠性, 2015(3):35-40.

[2] 趙正旭. 麒麟操作系統使用與推廣[M]. 北京：科學出版社, 2015.

[3] 劉 濤. 基于國產軟硬件平臺下辦公軟件插件的設計與開發[D]. 北京工業大學, 2014.

[4] 馬永青, 謝 平, 陳宜成. 采用統一測試策略的運載火箭測試系統[J]. 航天控制, 2004, 22(4):87-90.

[5] 段 榮. 國產數據庫在軍事信息系統中的應用[J]. 電子技術與軟件工程, 2015 (8): 208-209.

[6] 王加樂. 內存數據庫存儲管理設計與實現[D]. 復旦大學, 上海：2013.

[7] 陳昌鑫, 靳 鴻, 馬鐵華. 沖擊加速度存儲測試的變頻采樣策略分析[J]. 爆炸與沖擊, 2015, 35(4):501-506.

[8] 裴喜龍, 童 莉. 基于PCI總線的高速數據采集卡系統設計與實現[J]. 微計算機信息, 2006, 22(19):129-131.