王洪星,孫 剛,徐 智

(中國直升機設(shè)計研究所,江西 景德鎮(zhèn) 333001)

0 引言

現(xiàn)代飛行器由于控制模型復(fù)雜,在試飛調(diào)參時往往需要多次進行參數(shù)調(diào)整。為定量評估飛行參數(shù)效果,需要在試飛過程中將各項飛行數(shù)據(jù)進行存儲,在飛行后進行分析并為控制律參數(shù)調(diào)整提供依據(jù)。另外,飛行過程中出現(xiàn)故障時,依靠記錄的故障信息可以快捷地對故障點定位。為節(jié)省存儲資源,數(shù)據(jù)存儲的格式往往為二進制形式,需要在飛行后對記錄數(shù)據(jù)進行重新解碼還原。由于常用的飛參設(shè)備需要記錄各系統(tǒng)的大量飛行數(shù)據(jù),數(shù)據(jù)記錄周期往往設(shè)置得較長,以節(jié)約存儲空間,因而導(dǎo)致在長航時飛行時很難對某特定系統(tǒng)的數(shù)據(jù)進行詳細記錄。對此,在試驗試飛階段通常還需專門留出數(shù)據(jù)記錄器。另外,出于調(diào)參排故等需要,各系統(tǒng)需記錄的數(shù)據(jù)種類也會經(jīng)常變化,因此需要一種高適應(yīng)性的解碼軟件對存儲的二進制數(shù)據(jù)進行解碼。基于此方面考慮,本文提出并實現(xiàn)了一種基于MFC框架,用于對飛行數(shù)據(jù)解碼的Windows應(yīng)用軟件,在存儲數(shù)據(jù)種類發(fā)生變化時,無需重新編譯生成軟件,只需對相關(guān)協(xié)議配置文件進行更改即可,可以快速適配新的存儲格式。

1 硬件設(shè)計

1.1 總體概述

數(shù)據(jù)記錄器如圖1所示,采用了ARM+FPGA的處理器架構(gòu),其中FPGA作為429總線接口。在數(shù)據(jù)存儲過程中,FPGA接收并緩存外部輸入的高速429數(shù)據(jù);當數(shù)據(jù)有效后,向ARM發(fā)出中斷信號,通知ARM讀取緩存數(shù)據(jù),并將數(shù)據(jù)順序存儲在Flash中;Flash格式化為FAT32文件系統(tǒng),因此應(yīng)用軟件可以通過文件的形式對存儲數(shù)據(jù)進行讀寫操作。同時,ARM向FPGA發(fā)送控制信號,用于對總線數(shù)據(jù)讀取進行邏輯控制。在數(shù)據(jù)讀出過程中,首先將記錄器引出的USB接口連接上位機電腦;ARM接收到接入信號后,通過內(nèi)部數(shù)據(jù)總線將Flash中存儲的數(shù)據(jù)以二進制文件格式讀出,并通過USB接口向PC發(fā)送;此時在PC中可以通過文件訪問的形式對存儲文件進行操作。

圖1 數(shù)據(jù)記錄器硬件組成

1.2 數(shù)據(jù)發(fā)送與存儲

總線數(shù)據(jù)由飛行記錄軟件發(fā)送。記錄軟件貯存在飛行計算機中,按照固定周期運行,并由操作系統(tǒng)負責周期任務(wù)調(diào)度。記錄軟件負責傳感器數(shù)據(jù)的采集,并將中間數(shù)據(jù)向數(shù)據(jù)記錄器發(fā)送。程序流程如圖2所示?？紤]到發(fā)送的數(shù)據(jù)量較大,為避免阻塞任務(wù),在每個任務(wù)運行周期內(nèi),將待發(fā)送的一幀飛行數(shù)據(jù)包分成四拍發(fā)出。在機型上進行實測時,80 ms的數(shù)據(jù)記錄周期,每周期記錄的429字為113個,則每小時需要記錄的飛行數(shù)據(jù)約為39 MB。

圖2 數(shù)據(jù)發(fā)送流程

在記錄器上電后,ARM首先向FPGA發(fā)送初始化指令,并調(diào)用文件系統(tǒng)API在Flash中創(chuàng)建新文件。在接收到429數(shù)據(jù)后,ARM從FPGA的數(shù)據(jù)緩沖區(qū)中讀取數(shù)據(jù),并向文件中寫入,如圖3所示。

圖3 數(shù)據(jù)存儲流程

2 解碼軟件設(shè)計

2.1 配置文件

為保證軟件的通用性,解碼軟件使用了配置文件對不同的存儲協(xié)議進行適配。配置文件的主要格式如表1所示:第1列為429字的各數(shù)據(jù)位的信號定義;第2列說明了對各數(shù)據(jù)位定義的說明,例如正負號的定義、單位等;第3列表示該429字在一幀數(shù)據(jù)包中的位置;第4列表示該數(shù)據(jù)位在429字中的起始位置;第5列表示該數(shù)據(jù)位所占據(jù)的位長度;第6列代表了數(shù)據(jù)的存儲類型,在本軟件中,以數(shù)字3代表該數(shù)據(jù)為離散量,在解析時只需按位解析即可,無需考慮LSB換算,數(shù)字2代表該數(shù)據(jù)為無符號值,數(shù)字1代表該數(shù)據(jù)為有符號值,在解析時應(yīng)考慮數(shù)據(jù)正負;第7、8列分別為該數(shù)據(jù)的LSB值、數(shù)據(jù)字的429標號;第9列為數(shù)據(jù)在輸出中的列位置,用于在數(shù)據(jù)解析后,在輸出文件中按照一定順序?qū)馕龀龅臄?shù)據(jù)信息重新調(diào)整,以便于解讀。

表1 配置文件格式示例

按照此格式,在數(shù)據(jù)的存儲協(xié)議發(fā)生變化時,無需再重新修改解碼程序,只需要按照新協(xié)議修改配置文件,即可對新協(xié)議進行正確解析。

2.2 數(shù)據(jù)解碼軟件

2.2.1 編程框架

解碼軟件采用基于MFC的程序框架編寫。MFC即微軟基礎(chǔ)類庫,是微軟公司于1992推出的通用C++開發(fā)庫。庫中大量封裝了可重用的Windows API,包括Windows的內(nèi)建控件和組件等,支持消息循環(huán)、運行時類信息機制、動態(tài)創(chuàng)建機制等特性,是一種 Application Framework,包含多個程序框架模板,減少應(yīng)用程序開發(fā)人員的工作量。發(fā)展到今天,MFC已成為一個穩(wěn)定和廣泛覆蓋的C++類庫。

考慮到解碼軟件需要的界面控件數(shù)量較少,因此采用了基于對話框的架構(gòu)進行代碼編寫,所使用到的類架構(gòu)如圖4所示。

圖4 使用到的架構(gòu)類

其中,CMyApp為應(yīng)用程序類,負責應(yīng)用程序的初始化;CMainDlg為對話框類,負責解碼主界面的刷新、消息響應(yīng)等工作;CDialogLogIn用于管理軟件登錄界面并讀取配置文件。

2.2.2 界面設(shè)計

解碼軟件主要設(shè)計了登錄界面與解析界面兩個對話框,登錄界面如圖5所示。在該界面中,用戶需輸入正確的用戶名與登錄密碼后方可進入解析界面。任意輸入錯誤,將進行錯誤提示,如圖6所示。

數(shù)據(jù)解析界面為解碼功能的主界面,如圖7所示。通過點擊“解碼”按鍵,彈出文件選擇對話框,選擇需要解析的二進制文件。當“控件刷新”為選中時,將解析結(jié)果在下方列表框中即時顯示,并在當前進度中顯示解析進度。同時,解析出的故障信息與PBIT自檢信息同樣在控件中顯示。為方便不同界面切換,使用Tab控件來對當前顯示的數(shù)據(jù)主頁面進行管理。

圖7 解碼軟件主界面

2.2.3 軟件流程

軟件登錄界面中,添加“登錄”按鍵的消息響應(yīng)函數(shù)CDialogLogIn::OnBnClickedOk(),在響應(yīng)函數(shù)中,首先校驗用戶名與密碼是否正確。在正確輸入后,顯示解碼軟件的主界面。主界面由CMainDlg類管理,在對話框初始化函數(shù)CMainDlg:: OnInitDialog()中讀取應(yīng)用程序路徑中存在的有效配置文件,并將讀取結(jié)果存放于類成員m_pConfigStruct中。

在協(xié)議配置文件成功讀取后,CMainDlg將各協(xié)議字配置項名稱作為列標,插入到列表控件中,顯示順序由配置文件中的列位置決定。

進入解碼主界面,在“解碼”按鍵的單擊事件響應(yīng)函數(shù)中,調(diào)用系統(tǒng)文件打開對話框,選擇并讀入待解析的二進制文件,開始解析飛行數(shù)據(jù)。解析流程如圖8所示。

圖8 數(shù)據(jù)解析流程

首先根據(jù)標號尋找每幀數(shù)據(jù)中第一個429字位置;此后每讀取到一個429字時,應(yīng)首先對其標號與配置文件中的標號進行對比。配置文件中的各429字的行順序應(yīng)與接收順序相一致,當接收順序不同時,認為該次數(shù)據(jù)包接收錯誤,不再解析本包中的其余字,并在故障字解析文件中進行說明,同時尋找下一包有效數(shù)據(jù)。

根據(jù)429字中數(shù)據(jù)位類型的不同,將有符號數(shù)、無符號數(shù)以及離散量進行分類解析。

在數(shù)據(jù)解析過程中,考慮到本軟件采用了單線程的工作方式,在數(shù)據(jù)量較大時,往往不能及時響應(yīng)系統(tǒng)消息,會出現(xiàn)界面無法響應(yīng)用戶操作的情況,因此加入了消息循環(huán)結(jié)構(gòu),::SendMessage用于將消息發(fā)送到消息所標識的窗口,直到窗口完成指定的窗口過程后再返回。這樣就避免了在解碼過程中,當發(fā)生窗口事件時無法響應(yīng)消息的情況:

if(PeekMessage(&msg,(HWND)NULL,0,0,PM_REMOVE))

{ …

::SendMessage(msg.hwnd,msg.message,msg.wParam,msg.lParam);

…

}

解析完成后,創(chuàng)建輸出文件夾。文件夾按照飛行時間與架次重命名,并將生成文本格式的數(shù)據(jù)解析文件、格式說明文件、故障信息、PBIT結(jié)果文件依次存放。

2.2.4 軟件驗證

在機型上進行記錄器功能驗證,如圖9所示,飛行過程共計約2小時。

圖9 試飛數(shù)據(jù)解析結(jié)果

通過解析數(shù)據(jù)能夠基本還原飛行過程中的各系統(tǒng)狀態(tài)與內(nèi)部運行信息,數(shù)據(jù)記錄準確,解析結(jié)果(圖10)與實際飛行情況一致。

圖10 離散量解析結(jié)果

3 結(jié)束語

本文提出了一種通用的429數(shù)據(jù)解碼軟件設(shè)計方法,用于對數(shù)據(jù)記錄器存儲的數(shù)據(jù)進行解碼,即將二進制總線數(shù)據(jù)解析還原為實際物理量。一方面用于在試驗試飛時,對各系統(tǒng)的參數(shù)調(diào)試提供參考,同時保證飛行數(shù)據(jù)的完整性,能夠高效地還原飛行過程中各飛行系統(tǒng)工作狀態(tài);也可以用于對飛行過程中的故障快速定位,為地面維護人員排故工作提供數(shù)據(jù)支持。最后對軟件的正確性進行了充分驗證。

飛機實際飛行試驗表明,軟件易于使用,飛行數(shù)據(jù)解碼準確,通用性較好,能夠方便地將該解碼軟件移植到不同的機型中。本文為429總線數(shù)據(jù)譯碼提供了一套通用的方法,證明了該軟件的實用意義,為今后的試驗試飛提供了有力保障。