遙感衛星接收系統故障診斷專家系統知識庫設計

摘 要： 針對遙感衛星接收系統的故障特性，給出了故障診斷專家系統的架構。通過對系統設備監測信息及任務流程的故障特征分析、系統故障樹的建立與分析，利用產生式的知識表示方式，建立了故障診斷專家系統的知識庫。依據該知識庫設計的故障診斷專家系統已用于實際工程項目，提高了遙感衛星接收系統故障診斷的效率。

關鍵詞： 接收系統； 故障診斷； 專家系統； 知識庫； 故障樹

中圖分類號： TN927?34； TP182 文獻標識碼： A 文章編號： 1004?373X（2016）03?0104?05

Knowledge base design of fault diagnosis expert system applied to

remote sensing satellite receiving system

HU Meng1， WANG Wanyu2， TAO Sunjie3， WANG Jianping2

（1. The No. 39 Research Institute， China Electronics Technology Group Corporation， Xi’an 710065， China；

2. Institute of Remote Sensing and Digital Earth， Chinese Academy of Science， Beijing 100094， China；

3. Southwest China Institute of Electronic Technology， Chengdu 610036， China）

Abstract： For the fault characteristics of the remote sensing satellite receiving system， the architecture of the fault diagnosis expert system is provided. The fault characteristics of the monitoring information and task flow for system equipments are analyzed， and the system fault tree is established and analyzed， based on which the knowledge base of the fault diagnosis expert system is established with the knowledge representation method of production. The designed fault diagnosis expert system according to this knowledge base has been applied in the actual engineering projects， which can improve the fault diagnosis efficiency of the remote sensing satellite receiving system.

Keywords： receiving system； fault diagnosis； expert system； knowledge base； fault tree

0 引 言

遙感衛星接收系統結構復雜，功能繁多，運行的自動化程度高，且系統中設備之間緊密耦合，一處故障可能引起一系列連鎖反應，從而導致系統不能正常工作，影響衛星數據的接收，造成寶貴的衛星數據資源的丟失。

目前，遙感衛星接收系統大多仍采用人工方式進行系統故障診斷，該方式對故障診斷人員技術能力要求高，效率低，已不能適應新的技術發展需求[1]。因此采用先進的智能故障診斷技術，提高遙感衛星接收系統的本地和遠程的故障診斷能力，已成為遙感衛星地面接收系統的重要發展趨勢，具有重要的研究價值和現實意義。

本文針對遙感衛星接收系統故障診斷智能化、自動化的技術需求，依據遙感衛星接收系統的故障特征，在對已有故障診斷技術進行分析總結的基礎上，給出了故障診斷專家系統的架構，并結合實際工程項目完成了故障診斷專家系統知識庫的設計和實現。依據該知識庫設計的故障診斷專家系統已應用于實際工程項目，提高了遙感衛星接收系統故障診斷的效率。

1 遙感衛星接收系統組成及故障特性分析

遙感衛星接收系統是一類復雜系統，主要由天伺饋系統、跟蹤接收系統、測試系統、記錄系統和站監控管理系統組成[2]。系統中包含有天線、座架等機械設備，還包含大量各類電子設備，如變頻器、解調器、調制器、誤碼儀、頻譜儀、計算機和服務器等設備。站監控管理系統監測和控制系統各設備的狀態，各設備在站監控管理系統的控制下完成對遙感衛星數據的跟蹤接收任務。典型的遙感衛星接收系統如圖1所示。

總體來說，遙感衛星接收系統具有以下故障特性[3]：

（1） 系統組成復雜，結構層次多。與此相對應，系統故障點多、故障類型多、故障狀態多、故障因素多，因果關系復雜，快速、高效、準確、可信診斷故障難度高，故障排查、處理決策難度高。

（2） 系統涉及專業領域廣，知識構成復雜，知識表述及規則制定等難度大。

（3） 系統處于數據接收的工作狀態與等待數據接收狀態的交替運行模式，系統不是處于穩定、連續的運行狀態之中，故障突發性概率高。

（4） 系統工作受衛星、空間鏈路、工作環境等外部因素影響大，出現問題時區分內、外部因素難度大。

（5） 故障位置、類型對系統工作的影響程度差別大，故障影響級別的分類、處理決策難度大。

從以上故障特點可知：遙感衛星接收系統的故障具有層次性，而更多的是其形態的多樣性和不確定性。為此，將系統的故障診斷分解為故障檢測、故障識別和定位、故障處理決策三部分。

故障檢測功能利用站監控管理系統、測試系統實現，其主要任務是完成各類信息的采集、記錄，包括故障信息、設備狀態、任務執行信息、測試結果信息等。

故障識別和定位是根據故障檢測結果及知識庫信息，經分析、推理確定故障類型（如設備硬件故障、軟件故障、設備參數設置錯、設備需要標校等）和發生故障的設備。

故障處理決策是在故障識別和定位的基礎上，對故障進行解釋和評估并提供處理決策。

2 故障診斷專家系統架構設計

故障診斷專家系統主要包括知識庫、綜合數據庫、推理機、解釋機、知識獲取、故障分類統計評價及人機接口等部分[3]，如圖2所示。

知識庫包含領域中的大量事實和規則，是領域知識和相關常識性知識的集合，這些知識可以用一種或多種知識表示方法來表示，知識表示方法決定了知識庫的組織結構，并直接影響全天整個專家系統的工作效率。

綜合數據庫存儲所有原始特征數據的信息（包含狀態監視信息、任務信息、測試信息、設備信息、參數配置信息等）、推理過程中得到的中間信息和解決問題后輸出的結果信息等。

推理機是專家系統的組織控制機構，它根據輸入信息，運用知識庫中的知識，按一定的策略進行推理，完成故障診斷。

解釋機能夠解釋推理過程，并能夠詢問需要的補充特征信息；此外，還可以解釋推理得到的確定性結論，并對診斷結論做評估。

知識獲取是專家系統和領域專家及知識工程師的接口，通過它與領域專家和知識工程師交互，使知識庫不僅可以獲得知識，而且可使知識庫中的知識不斷更新，從而使專家系統的性能得到不斷改善。

故障分類統計評價對系統故障進行分類、統計及分析評價，獲取系統中的薄弱環節、故障多發設備等信息，為系統設計提供改進建議，也可為系統維護、備件訂購等提供技術支撐。

人機接口是專家系統和用戶之間進行信息交互的媒介，它可以以文字、圖形、表格等多種方式與用戶交互。

3 知識庫設計

知識庫設計是專家系統的關鍵環節，包括問題知識化、知識概念化、概念形式化、形式規則化和規則合法化[4]。本文設計的故障診斷知識庫由知識主表，業務知識主表，業務知識從表的結構組成。知識存儲在數據庫中，通過層級結構對專家知識進行存儲和管理。設計時用故障樹模型表述較為復雜的專家知識，并且關聯其他類型的專家知識。

3.1 知識庫結構

3.1.1 知識庫組織結構

故障診斷知識存儲在數據庫中，通過層級結構，對專家知識進行存儲和管理。知識庫由知識主表、業務知識主表、業務知識從表組成。

知識主表：用抽象的方式存儲各類知識，包括知識ID，知識類型，知識描述，版本號，創建時間，審批時間，狀態等屬性。其中，知識類型用以劃分系統中各種類型的專家知識，知識描述用以描述各類專家知識的特性，其他屬性字段則適用于知識的發布和審批。

業務知識主表：分別描述了故障診斷系統的多類專家知識，包括故障監測點知識主表，閉環測試知識主表，故障樹知識主表等。

業務知識明細：是具體的專家知識的存儲結構。

通過上述三層層級結構，有效地構建了穩固、可靠并且方便擴充的專家知識數據庫模型，方便后續更為復雜的專家業務知識的存儲。

3.1.2 知識庫邏輯結構

本設計用故障樹模型表述較為復雜的專家知識，并且關聯其他類型的專家知識，形成和真實人工診斷基本一致的知識存儲方式。

故障樹知識作為主干，其他類型的知識作為枝蔓，共同構架，完成了故障診斷系統的知識組成和架構設計。同樣，故障樹模型為后續更多不同類型的專家知識的納入建立了基礎和準備。

3.2 知識表示

知識是故障診斷專家系統的核心之一，知識表示方法決定著知識庫的組織結構并直接影響整個故障診斷專家系統的工作效率。知識包括事實與規則。

3.2.1 事實的表示

事實分為葉子事實（LeafFact）和非葉子事實（NotLeafFact）。葉子事實是不能再進一步尋因的、有數據庫數據直接支撐的事實，在故障樹上反映為葉子節點，或者是故障檢測點事實和閉環測試事實等故障產生的原因；非葉子事實是不能進一步尋因的、沒有數據庫數據直接支撐的事實，在故障樹上反映為根節點和葉子節點的祖先節點。事實主要包括以下屬性：

{

事實名稱：

事實代號：

事實描述：

是否為葉子事實：

GET信息：

JUDGE信息：

值：

置信度：

排除故障建議：

……

}

事實名稱：事實的中文ID，方便用戶和開發人員理解事實的意義；

事實代號：事實的英文ID，惟一，不可重復，在知識庫中事實的惟一標識；

事實描述：事實的詳細說明；

是否為葉子事實：事實的類別；

GET信息：獲取支撐數據，只有葉子事實才會有；

JUDGE信息：對獲取到的數據進行計算判斷，只有葉子事實才會有；

值：表示該事實的狀態，有正常、異常、未知等可能的狀態；

置信度：計算或推理得到該事實節點正常、異常等狀態的可信度；

排除故障建議：如果該部位發生故障，可以給出排除該部位故障的意見。

3.2.2 規則的表示

規則的表達有產生式、框架、語義網絡、神經網絡等表示形式[5]，也可以簡單地理解為一組條件和滿足此條件下的操作[6]。本設計用產生式規則存儲領域專家的故障診斷知識。產生式規則的通用表達方式如下：

if A， then B

其中：A為規則前件，表示觸發該規則需要滿足的先決條件；B為規則后件，表示觸發規則后，可以得出的結論或者應該執行的操作；A包含一個或多個前件元素（又成為“模式”），B也包含一個或多個后件元素，當A中的所有前件元素能在全局數據庫中得到匹配時，稱為模式匹配成功，該規則可以觸發，推出規則后件元素。規則主要有如下屬性：

{

規則名稱：

規則代號：

規則描述：

規則前件元素列表：

規則后件元素列表：

后件元素關系：

參數：

……

}

規則名稱：規則的中文ID，方便用戶和開發人員理解規則的意義；

規則代號：規則的英文ID，惟一，不可重復，在知識庫中規則的惟一標識；

規則描述：規則所實現功能的詳細說明；

規則前件元素列表：需要哪些事實得到匹配，才會觸發該規則，是事實代號的集合；

規則后件元素列表：規則觸發后可以推出哪些結論；

后件元素關系：標準關系有與或非，當然用戶也可以自定義關系；

參數：后件元素關系可能會包含某個參數。

3.3 知識庫管理和維護

知識庫是一個獨立的實體，它存儲的知識需要通過程序來提取和管理。然而，故障診斷知識庫還需不斷完善，領域專家可能隨時會更新知識庫，故障樹也可能隨時會根據需要更新。因此本故障診斷專家系統以圖形、列表等形式，對故障診斷專家系統的各類事實、規則等知識進行管理和維護，包括查詢瀏覽、增加、修改、刪除等功能。

3.3.1 事實管理

事實管理包括GET函數管理、JUDGE函數管理和事實管理。GET函數管理是對動態鏈接庫“get.dll”中的GET函數登記管理，即讀取其中的標準GET函數和自定義的GET函數名，將其讀入到數據庫中。同樣，JUDGE函數管理，也是讀取“judge.dll”中的標準JUDGE函數名和自定義JDUGE函數名，將其存入數據庫中，只有登記到數據庫中的GET函數和JUDGE函數才能供葉子事實調用。

3.3.2 規則管理

規則管理主要包括規則管理、解釋管理和后件元素關系管理。規則管理包含對規則各個屬性的管理，其中，規則前件、規則后件是在彈出對話框中的事實庫中選擇的；解釋管理是對系統如何尋因進行管理；后件元素關系管理包含標準的And，Or，Not，或者其他自定義關系，如圖3所示。

規則管理，其可視化操作包括故障樹查看、故障樹模型建立、故障樹變更和刪除等，可直接在圖形界面上進行編輯，通過事件拖拽形式建立或變更故障樹，并可在圖形界面上直接修改故障樹各個節點屬性，如事件名稱、描述、故障建議等。

3.3.3 知識庫的更新

如果對知識庫中的事實、規則、函數不加限制的隨意添加、刪除，很可能出現知識庫不一致的情況，比如出現規則前件元素的事實在事實庫中找不到，那么該規則永遠都得不到匹配；或者葉子事實的標準GET函數在函數庫中找不到，那么該葉子事實永遠獲取不到數據判斷不了它的狀態。為了保證知識庫的一致性，需要按一定順序對知識庫進行操作。

要添加一條規則，必須保證它的前件元素、后件元素存在于事實庫中，因此需要先添加事實，添加事實之前，必須保證其GET函數、JUDGE函數在函數庫中，因此必須先添加GET函數和JUDGE函數。

要想刪除GET函數或者JUDGE函數，需先刪除引用該GET函數或者JUDGE函數的所有事實，要刪除事實，必須先刪除所有引用該事實的規則。如果想強行刪除GET函數或者JUDGE函數，那么會提示有哪些事實引用了該GET函數或者JUDGE函數，而刪除失??；如果想強行刪除事實，那么會提示有哪些規則引用了該事實而導致刪除失敗。如此，能在一定程度上保證用戶在操作知識庫時的安全。

3.3.4 知識庫一致性檢查

在故障診斷系統的知識庫建立好后，隨著系統的運行與專家知識的不斷總結，會有新的知識不斷加入到知識庫中，產生式規則的數量也在不斷增加，雖然在操作知識庫的時候進行了一些一致性控制，但仍然會存在規則之間矛盾、冗余、蘊含等不一致和不完整性。

在知識庫構建之初，可以通過人工的方式進行檢查，但知識庫變得龐大之后，規則之間的聯系變得復雜，人工方式難以排查，因此知識庫必須建立知識有效性和完整性檢查機制。

知識庫一致性檢查包含：知識矛盾、知識循環、知識等價、知識蘊含、知識不完整性。知識矛盾是指相同的前件推出兩個相反的結論，或者在相同的前提條件下得出相互矛盾的兩個結論；知識循環是指規則形成了一個循環鏈；知識等價是指如果兩個規則R1和R2的前件等價時，得出的結論也等價；知識蘊含是指如果兩條規則R1和R2的結論部分等價，但一條規則R1的前件蘊含另一條規則R2的前件；知識不完整性是指事實庫中的事實沒有完全包含在規則庫中規則的所有前件和后件中。

同時，根據故障診斷規則的特點，還需要做如下檢查：

（1） 規則前件元素一般只有一個，且是非葉子事實；

（2） 故障樹層次結構清晰，故障樹之間相互獨立無交叉；

（3） 任何一個事實最多作為一個規則的前件，最多作為一個規則的后件。

3.3.5 模擬推理

在按照正常流程對知識庫進行編輯、更新事實和規則并進行一致性檢查后，仍需確認更新后的知識庫，以便確保故障診斷系統按預期進行推理。因此，在知識管理模塊設計了一個模擬推理功能。

模擬推理界面可向全局事實庫中輸入需要測試的事實，然后推理并觀察規則匹配后的推理結論是否與預期一致。模擬推理有兩種方式：第一種是一鍵推理，根據全局事實庫中的事實，推理機推出所有可能的結論；第二種是步進推理，根據當前全局事實庫中的事實，每一步只觸發一條規則，直到沒有規則可以觸發，這個過程就像一步一步調試程序。

4 結 論

知識庫設計是專家系統的關鍵環節，本文通過對系統設備監測信息及任務流程的故障特征分析、系統故障樹的建立與分析，利用產生式的知識表示方式，建立了故障診斷專家系統的知識庫。知識庫存儲在數據庫中，通過層級結構，對專家知識進行存儲和管理。

依據該知識庫設計的故障診斷專家系統已應用于實際工程項目中，提高了遙感衛星接收系統故障診斷的效率。

參考文獻

[1] 馮旭祥，王萬玉，張寶全.遙感衛星接收系統的故障診斷技術綜述[C]//中國空間科學學會空間探測專業委員會第二十六次學術會議論文集.北京：中國空間科學學會，2013：195?201.

[2] 王萬玉，張寶全，劉愛平，等.頻率復用高碼速率遙感衛星數據接收系統設計[J].電訊技術，2012，52（4）：423?428.

[3] 王萬玉，陶孫杰，馮旭祥，等.遙感衛星接收系統故障診斷專家系統設計[J].電訊技術，2015，55（5）：491?496.

[4] 張志杰.測控裝備故障診斷專家系統的設計與實現[J].艦船電子工程，2012，32（6）：95?97.

[5] 王帆.基于故障樹的空間有效載荷故障診斷系統研究[D].北京：中國科學院研究生院，2007：21?23.

[6] 戎月莉.計算機模糊控制原理及應用[M].北京：北京航空航天大學出版社，1995.

[7] 王萬玉，王永華，王強.雙圓極化遙感衛星數據接收系統極化鑒別率需求分析[J].現代電子技術，2014，37（15）：45?48.

[8] 于智春，李中偉.一種導彈飛行測控裝備遙控策略的設計與實現[J].現代電子技術，2014，37（4）：70?71.