公共數據庫檢索在模擬機維護中的應用

貝 珩

(中國國際航空股份有限公司 培訓部，北京 101300)

近10年的統計數字表明，模擬機儀表接口系統是模擬機故障率最高的系統，其故障占比達到各類系統故障總量的50%左右，維護人員在該系統中投入的工作量也相對較大。傳統的故障性維護方式一般是根據故障點對應的電路連接，逐一測量和更換線路上的硬件設備，以期達到恢復模擬機正常功能的效果。以這種方式處理故障通常要面臨3種困難：

① 所有相關設備的更換都需要對應的備件支持，并且新備件必須與原設備所在線路兼容；

② 測量點必須清晰可見，測量人員、測量設備和操作空間必須符合測量要求；

③ 為確保操作者和設備安全，必須暫停飛行訓練，由至少二人協作、占用較長時間完成上述操作。

而在故障現象復雜的情況下，更換單一的備件并不能保證100%排除故障，當故障的癥結存在于未被更換的器件上或者軟件驅動和尋址方面，就應當采用從軟件端對故障設備對應的特征變量(label)實施監測和控制的方法，來尋找故障的形成原因。

公共數據庫(Common Datebase，CDB)檢索也稱為公共數據庫查詢技術，即在數據庫文件或系統中對關鍵字搜索的結果進行分析、篩選和實驗，并獲得有用信息的技術[1]。使用CDB檢索找到特定label的方法剛好符合模擬機接口系統復雜故障的排故需求，但它在現行的排故工作中并不通用，這主要有3方面原因：

① CDB是模擬機軟件運行的動態參數庫，廠家沒有明確給出對CDB進行操作的方法和檢出label的定義；

② 交互頁面式的監控軟件沒有提供輸入特定label實施監控的手段，僅能對軟件中可視的label進行監控；

③ 對由時序信號控制并不斷刷新狀態的label進行賦值時，廠家沒有告知保持其賦值狀態的方法。

就上述問題開展研究，分析模擬機軟硬件運行的原理，在CDB初始文件中，使用設備關鍵字檢索的方法，找到可能影響設備狀態的若干個label。而后通過命令行軟件直接與模擬機運行時使用的CDB進行實時交互，窮舉觀察所有label賦值帶來的設備狀態變化。以期在不中斷飛行訓練的情況下，短時間內確定故障癥結，提高排故的針對性、操作的安全性，并減少對飛行訓練的干擾，這是采用CDB檢索的排故方法預期達到的效果。

1 故障案例

中國國際航空股份有限公司737-800型飛行模擬機于質量自檢中發現第三部無線電調諧面板的對側調諧燈顯示邏輯出現錯誤。根據中國國際航空股份有限公司737機組操作手冊第五章第十節的描述，這類面板在737-800型飛機內共有3部，分別安裝于中央控制臺的左上(第1部)、右上(第2部)和中下(第3部)，其英文名稱為Radio Tuning Panel，簡稱RTP。

RTP的對側調諧燈位于面板中上部，其顯示邏輯正常時應符合中國國際航空股份有限公司737機組操作手冊第五章第十節第七段的概括，即通常與這個面板連接的無線電正在由另一個無線電調諧面板調諧、或這個無線電調諧面板正在用于調諧通常不與它連接的無線電時，該燈顯示為白色常亮[2]。也就是說對側調諧燈邏輯的正常狀態為熄滅狀態，此時三部RTP各自與通常應當連接的無線電進行調諧，即RTP1選擇調諧VHF1(Very High Frequency)，RTP2選擇調諧VHF2，RTP3在非備用狀態時調諧VHF3。而當任何一個RTP調諧了其他RTP通常調諧的無線電頻率時，這兩個RTP的對側調諧燈點亮。如：RTP1選擇調諧VHF2，RTP2和RTP3保持正常調諧狀態，此時RTP1和RTP2的對側調諧燈點亮，RTP3的對側調諧燈熄滅。

按照上述原則，使用窮舉法采樣三部RTP的27組對側調諧燈顯示邏輯，如表1所示。發現僅有RTP1的對側調諧燈顯示邏輯符合機組操作手冊的描述，RTP2和RTP3的顯示邏輯則呈現出相反的狀態，即RTP2的對側邏輯符合RTP3的調諧原則，RTP3的對側邏輯符合RTP2的調諧原則。初步估計二者在接口電路中傳輸的控制信號發生了錯誤的互換。

表1 RTP對側調諧燈顯示邏輯采樣表

2 模擬機儀表接口系統原理分析和CDB檢索方法在排故中的應用

2.1 模擬機儀表接口系統原理分析

模擬機生產商利用波音、空客等飛機制造企業提供的、獲取自真實飛機的特性數據，通過自行開發的主程序及其分支模塊，將各個系統的仿真效果傳遞給模擬機用戶[3]。這些系統通常可以分為計算機系統、儀表接口系統、運動和操縱系統、視景系統和聲音系統[4]。

而上述故障發生在儀表接口系統中，對于這一系統的故障，傳統的方法通常需要測量故障線路的信號是否正常受控，或者在電路圖中找出故障線路的label，用軟件對label進行賦值，再觀察對應器件是否出現正常的響應。這種故障處理方式面臨如下幾個問題。

① 可靠的電子產品在設計時通常會考慮，在環境溫度、工作載荷和持續使用時間等因素的影響下，發生元件參數退化或小范圍特性漂移時，產品性能指標仍在關聯設備可識別的容差范圍內，部分電路的潛在故障可以被消除或容忍[5]。但由于RTP2和RTP3的顯示邏輯不是單獨出現錯誤，而是發生了完整互換，其各自的接口設備同時存在對稱的顯性故障的可能性微乎其微，因此單純更換接口設備以消除故障的概率較低。

② 機載設備的功能復雜，對應的接口模塊類型較多，為了維護方便，在設計時一般采用將串行數據模塊和ARINC模塊分別以單獨的接口板卡形式與用戶操作面板連接[6]，同時遵循以最小可更換器件為單元，將每個RTP面板對應的接口設備GPIM(General Purpose Interface Module)設計為3個，如果同時更換2個RTP對應的GPIM，將為接口系統引入7個不同類型的新設備，所需的備件數量和投入的工作時間都很多，新設備的兼容性隱患也非常大[7]。

③ GPIM是封閉安裝的設備，沒有外部可視的測量點，僅可使用專用設備將測量點引出才能進行測量，同時RTP面板除接收處理串口信號外，還接收ARINC信號，這種時序信號需要專用設備測量，使用一般的工具無法得到有效的測量結果。

④ 如果信號的互換錯誤發生在接口設備上，更換對應GPIM可以排除故障，但如果信號的互換錯誤發生在主機(Host)端，那么更換GPIM就毫無意義，必須對主機端軟件進行進一步處理。

因此必須選用軟件監控的方法，從主機端著手，嘗試分別控制RTP2和RTP3，并對產生的現象加以分析，找出發生信號錯誤互換的設備。

2.2 CDB檢索方法在排故中的應用

對于使用一般的串行數據控制的設備，廠家大多會給出每個器件對應的label，正常情況下這些器件可使用特定的監測軟件通過控制label的數值呈現出相應的現象變化，如：燈光亮滅、指針轉動等。而在模擬機內對設備進行如：電門開合、旋鈕轉動等操作，也可以在監測軟件上觀察到label數值的變化。

RTP面板既用到串口信號也用到ARINC信號，其接口電路如圖1所示，主機通過以太網將串行和ARINC數據發送到節點計算機(USB_IO)，再由節點計算機通過簡化PCI總線發送到功能分立的GPIM上，負責串行接口的普通GPIM將信號分為數字量和模擬量的輸入輸出與下游器件實現驅動和交互，而負責ARINC信號的特殊接口卡GPIM_AC則通過板載的FPGA模塊與相關設備建立聯系[8]。

圖1 RTP面板接口電路原理圖

串行信號一般控制面板上的按鍵、旋鈕和燈光，這些功能都在模擬機的CDB中有相應的定義，這種定義被稱為label，可以通過在主機端運行的接口軟件ITMS(Integrated Test Management System)對這些label實現監測和控制。憑借對這些label的賦值和觀察，可以直觀地發現接口設備是否存在故障情況，并且可使用萬用表等常用測量工具，通過由專用工具引出的測量點，獲得對應插針的電壓值。比如：在ITMS上，對某指示燈的label進行賦值，同時檢查燈光的狀態，如果無論賦予的邏輯是“0”還是“1”，燈光始終亮起，則可以認為對應的GPIM存在故障，并輸出了錯誤的驅動信號。但對于使用ARINC429協議的鏈路采用同樣的方法很難取得成效，這種協議傳輸的是雙極歸零式調制信號，即頻率為12.5～100 kbit/s的周期性連續信號，其傳輸字格式如表2所示。

表2 ARINC429傳輸字的格式[9]

這種信號的邏輯特性遵循以下原則：由高電平+5 V回歸到零電平表示邏輯“1”，由低電平-5 V回歸到零電平表示邏輯“0”。同時其信號發送和接收設備也不是常見的邏輯信號保持器，而是綜合譯碼邏輯、控制邏輯、實時時鐘和中斷的集成模塊FPGA(Field Programmable Gate Array)，因此只能使用示波器等不常用手段觀察其信號狀態，很難作為有效的故障判斷依據[10]。雖然原理上講ARINC信號有對應的label，但在電路圖中，這些label往往不被直接給出，想要控制這類信號必須尋找到與之相關的上游label。

假設一個ARINC邏輯信號的函數模型為

A{0,1}=F(a，b，c，…，n)

如果找到任何一個可控的變量a，b，c，…,n，在對這一變量進行賦值的同時，保持其他所有變量不變，能夠使A的值發生變化，則可以認為A能夠單獨被上述變量控制。也就是說，當CDB中存在一個可以單獨控制某路ARINC邏輯的label時，可以通過在賦值該label的同時觀察RTP面板狀態的變化，來確定GPIM、ARINC設備或鏈路是否存在故障，以期實施有針對性的軟硬件調整。

由于CDB文件中含有的變量包含了所有的輸入/輸出變量和所有系統之間，甚至是系統內部模塊之間的交連變量，如圖2所示[11]。因此對CDB文件進行檢索，一般可以發現直接或者間接控制ARINC設備各種功能的特定label。

圖2 模擬機數據庫文件內容示意

根據模擬機的軟件運行原理，模擬機各個節點計算機和接口設備會從在用的配置下轄的CDB中調用label。這些CDB的初始文件可以借助Windows系統，在主機端的各個configuration文件夾下，使用*cdb*關鍵字搜索獲得，而與ARINC協議相關的初始文件，也可以用*arinc*關鍵字搜索獲得，此故障中涉及到的兩個文件為b73x2.cdb和b73xarinc.csv。可以使用UltraEdit等軟件打開上述CDB文件，并在其中繼續搜索與RTP相關的label，對比兩個文件中描述語句具有相關性的label，可以發現數十項與一般label存在關聯的ARINC邏輯。

由于這些label在ITMS中缺少調用接口，因此使用監控工具CTS-PLUS(Control Test System)來進行label賦值，CTS的工作原理如圖3所示。

圖3 CTS軟件工作原理

可以看到，CTS將獲取到的初始數據通過同步和異步進程按照主程序的要求寫入CDB，模擬機執行來自CDB的初始輸出后，再根據模擬機使用者的人為輸入形成反饋，并發往CDB中，CTS此時再通過同步和異步進程從CDB中獲取反饋數據，以實現監測和控制。ARINC邏輯通常在同步進程中進行運算和傳遞，并且刷新頻率較高。如果通過賦值其相關label來改變ARINC邏輯，則可能會發生賦值當時所生成的ARINC輸出在下一個時鐘周期到來時即被刷新回原有狀態的現象，這會令監測者無法看到機艙端發生的變化，因此在CTS中進行label賦值操作前，可以對模擬機進行飛行凍結(Flight Freeze)，此時大部分同步進程會暫停刷新，操作者此時再行賦值，模擬機主程序只對發生賦值的label和由此產生的單次運算結果進行響應，對應的機艙端現象可以保留下來，直至凍結解除。

在上述故障中，通過搜索找到影響RTP2和RTP3對側調諧燈的label后，發現當對RTP2的相關label進行賦值改變其邏輯狀態時，對側調諧燈發生亮暗變化的是RTP3；反之當對RTP3的相關label進行賦值改變其邏輯狀態時，對側調諧燈發生亮暗變化的是RTP2；同時賦值RTP1的相關label，僅有RTP1會有對應現象。由此可以斷定主程序發出的指令在接口鏈路中而不是主機端發生錯誤互換。此后檢查RTP2和RTP3的地址定義列表，發現兩路接口設備的地址定義與正常值相反，重新進行接口設備固件燒錄后，故障現象消失。

3 結束語

通過公共數據庫檢索，找出待測設備對應的特征變量，并結合CTS軟件進行賦值，是一種高效、準確和安全的儀表接口系統故障排查方法。大量的工作驗證這種方法可以應用于CAE公司生產的不同機型，不同技術代別的各類模擬機中。運用該種方法處理關閉的故障有：B737-800型CLASSIC模擬機氣象雷達面板增益旋鈕功能不正常、B737-Max型XR模擬機燈光測試開關常閉、A330型SIMXXI模擬機黃系統滲油測試閥開關常開、A320型R4模擬機時鐘計時器失效等。

故障性維護對工程人員的要求主要是對故障的快速定位和隔離，同時應兼顧以最小的維護成本換取故障的排除。一般熟練的工程人員能夠在1 h內完成label檢索和賦值，而更換對應接口設備或節點計算機的工時都相對更長，從搜尋備件到斷電更換，再到對主機進行相應的軟件更新，耗時通常在2 h以上，同時還可能引入新備件兼容性帶來的故障隱患。如果對電路進行直接測量，除去可能存在的觸電或損傷電路的風險外，還可能遇到測量點難以確認或接觸、信號特殊無法用常規設備采樣等問題。而在機艙端對故障現象的觀察也是通過CTS賦值的方式最為便捷。因此該種方法應在模擬機儀表接口系統的故障處理中被優先考慮和應用。