基于專家系統的通信網全鏈路故障智能判讀

李斌成，馬宇飛，李培儒

(中國電子科技集團公司第五十四研究所，河北 石家莊 050081)

0 引言

衛星通信網與地面有線網絡相連接組成了衛星鏈路與有線鏈路混合的綜合通信網絡，綜合通信網兩個地球站數據終端的端到端全鏈路包含了地面鏈路環節和衛通鏈路環節，全鏈路告警故障在故障層次、環節等方面的綜合判讀一直都比較困難。衛星通信網絡管理中已實現了對衛星地球站獨立的系統設備狀態及鏈路狀態的實時監視，達到對設備及鏈路狀態的單獨監視。隨著衛星通信網絡的不斷發展，衛星鏈路調度更加頻繁，衛通網管理越來越復雜，對衛通網運行管理提出了更高的要求。尤其在通信網全鏈路告警故障自動判讀方面提出智能化、自動化、綜合化等要求，原來對系統設備、網絡局限于獨立設備的單個故障參數、獨立鏈路的單個故障參數的管理控制已不能滿足應用對衛通網自動化、綜合化管控的要求。

為提高通信網全鏈路告警故障智能化、自動化判讀水平，結合人工智能技術發展和CLIPS專家系統工具，通過構建衛通領域專家知識結構，設計基于CLIPS的通信網全鏈路告警故障自動判讀專家系統，實現通信網全鏈路告警故障自動判讀。

1 傳統通信鏈路監視的局限

1.1 局限性及分析

通信網告警管理實現了對設備、衛星鏈路、地面有線鏈路等的獨立告警管理，但存在綜合化、自動化不足的局限，通信網全鏈路告警故障無法自動化判讀。傳統通信網鏈路告警故障判讀的不足主要表現在以下方面：

① 范圍不全，僅衛星通信段，未含地面段；

② 層次單一，僅監視Eb/N0，沒有關聯鏈路的故障自動判讀；

③ 自動化不足，發生鏈路中斷故障時，通常通過人工去判讀；

④ 綜合化不足，發生鏈路中斷故障時，通常僅檢查調制解調器接收Eb/N0性能，當中斷時一般認為是發送功率不足引起，不會綜合考慮鏈路多環節多種因素(收發支路設備故障、載波頻譜異常、地面鏈路設備、連線故障等)。

傳統通信鏈路告警故障的判讀局限，是告警監視過程和通信鏈路告警的相互獨立造成的，系統設計時沒有仔細分析通信鏈路告警故障與鏈路背后關聯的設備、頻譜、地面鏈路環節等因素相關聯，同時系統實現上也沒有應用智能化手段，造成通信鏈路的告警故障判讀無法實現自動、智能綜合判讀。同時由于多種調制解調設備解調門限不同，不同站上下行支路的鏈路組成性能也不同，也使傳統管理方法很難實現對全鏈路故障的綜合判讀。

1.2 解決思路

為了解決通信網全鏈路告警故障管理自動化不足、綜合化不足等局限，一種方法是通過故障建模并將其判讀邏輯固化在軟件中；另一種方法是引入人工智能技術，利用專家系統的智能化推理進行告警故障的自動判讀。

第一種方法雖然一定程度上也可實現故障自動判讀，但判讀邏輯是固化的，擴展不便。第二種方法借助人工智能技術實現故障智能化判讀，并可通過完善專家知識庫改進判讀效果。為提高通信網全鏈路告警故障判讀智能化水平，設計了基于CLIPS專家系統的通信網全鏈路故障自動判讀系統。

2 專家系統技術概述

2.1 專家系統組成原理

作為人工智能一個重要分支的專家系統(Expert System，ES)[1]，一般認為專家系統就是應用于某一專門領域，由知識工程師通過知識獲取手段，將領域專家解決特定領域的知識，采用某種知識表示方法編輯或自動生成某種特定表示形式存放在知識庫中；然后用戶通過人機接口輸入信息、數據或命令，運用推理機構控制知識庫及整個系統，能像專家一樣解決困難的和復雜的實際問題的計算機(軟件)系統[2-3]。專家系統結構如圖1所示。

圖1 專家系統結構

一個完整的專家系統由4個部分組成：知識庫、推理機、知識獲取部分和解釋接口。其中知識庫用來存放相關領域專家提供的專門知識；推理機的功能是根據一定的推理策略從知識庫中選取有關知識，對用戶提供的數據進行推理，直到得到相應的結論為止；知識獲取過程可以看作是一類專業知識到知識庫之間的轉移過程；人機接口則完成輸入輸出的人性化[4]。

2.2 CLIPS專家系統工具

CLIPS是“C語言集成產生式系統(C Language Integrated Prodution System)”的簡稱。它是由NASA用C語言設計的用于開發基于規則的專家系統的專用工具[5-6]。CLIPS是一個通用的專家系統工具，有很強兼容性，可安裝在任何 C 編譯器上[7]。CLIPS平臺的基本結構如圖2所示。

圖2 CLIPS平臺的基本結構

CLIPS是用來開發基于規則的專家系統，主要包括以下4個基本組成部分：知識庫(規則庫)包含所有的規則，存儲人類專家的知識和經驗；事實表存儲推理使用的事實集合；推理機將知識庫中的規則前件和事實表進行匹配，并授予規則優先級，輸出最高優先級規則的后件即結論；議程(agenda)存儲知識庫規則與事實表匹配成功的規則即已激活的規則。圖2是最簡單的 CLIPS 結構，一般還包括用戶界面、解釋機和知識獲取機。

CLIPS基于事實驅動的正向鏈推理(從事實到結論的推理)，即將事實表里的事實與知識庫中每一條規則的前件部分進行匹配，匹配成功的多條規則放入議程表中，并授予每條規則優先級，執行結果就是輸出議程表中優先級高的規則的后件。

2.3 CLIPS嵌入技術

現在使用CLIPS進行開發一般都是將 CLIPS嵌入到其他高級語言中實現，其中CLIPS與CC++語言的混合編程是最易于實現的，也是最可靠的[3]。CLIPS嵌入技術主要有2種：直接嵌入法和動態鏈接庫(DLL)嵌入法[8-9]。

2.3.1 動態鏈接庫嵌入

動態鏈接庫的嵌入方式需要在網上下載相應的工具也可以自己編譯，這些工具包括動態庫文件clip.dll以及包裝類CCLIPSWrap和說明文檔。使用動態鏈接庫嵌入法的開發流程如下：

① 初始化CLIPS動態庫CLIPSInit()；

② 清空CLIPS工作區CLIPSClear()；

③ 加載規則文件CLIPSLoad()；

④ 復位知識庫CLIPSReset()；

⑤ 加載事實表CLIPSLoadFacts()；

⑥ 運行CLIPS推理CLIPSRun()；

⑦ 退出CLIPS釋放內存CLIPSExit()。

使用動態鏈接庫嵌入法的代碼和CLIPS源碼耦合度低，對用戶的要求相對較低，用戶不用了解CLIPS相關內容，只需知道動態庫提供的接口函數。

2.3.2 直接嵌入

直接嵌入法就是將CLIPS源碼(除了main.c文件外)嵌入到開發的項目中，這種方法是最簡單直接的。以直接嵌入方式開發項目時必須在工程文件中添加支持 CLIPS 的頭文件 clips.h。直接嵌入法的開發流程如下：

① 將源碼加入工程；

② 加入頭文件聲明；

③ 聲明自定義函數；

④ 編寫自定義函數；

⑤ 啟動CLIPS。

直接嵌入法使工程代碼與CLIPS源碼的耦合度較高，不便于以后的維護和修改，同時對開發用戶的要求高，需要用戶對CLIPS有相當深入的理解。

上述2種 CLIPS嵌入方法各有千秋，本文采用動態鏈接庫嵌入的方式來開發項目，將CLIPS內核嵌入到C++主程序中以快速實現仿真環境，專注于CLIPS工具的領域應用。

3 專家系統在告警判讀中的應用

通過獲取通信網全鏈路領域知識，并用CLIPS形式化表示知識結構，應用CLIPS工具對通信網全鏈路告警故障進行自動判讀。

3.1 全鏈路故障判讀知識獲取

3.1.1 全鏈路故障分析

衛通網全鏈路指從源站主機到目的站主機的端到端鏈路，全鏈路含義不僅包括源站衛星調制解調設備到目的站衛星調制解調設備間的衛星通信鏈路，也包括源、目的站站內從數據終端到衛星調制解調設備的有線通信鏈路。通信網全鏈路是通信網拓撲的基本組成單位，網內全部鏈路的狀態一起組成了通信網全網網絡拓撲態勢。

通信網全鏈路故障態勢表現為源站主機到目的站主機的端到端鏈路中斷或鏈路性能的降低，包括了地面有線鏈路的中斷和衛星通信鏈路中斷等環節，主要故障現象有“解調失鎖”、“Eb/N0過低異常”和“地面鏈路中斷”等。

造成衛通鏈路解調失鎖有射頻或中頻設備故障(功放、低噪聲放大器、變頻器和調制解調器等)、調制發開關關閉、衛通鏈路載波消失或被干擾等原因。造成解調器Eb/N0過低的原因有發端信號發送功率過低、載波頻譜被干擾等。地面有線鏈路中斷的原因大致有路由器、交換機、主機等設備故障和設備間連線故障等幾種。

3.1.2 故障樹模型

通過綜合分析、梳理形成圖3所示的故障樹模型。判定依據及和處置方法如表1所示。

圖3 通信網全鏈路故障樹模型

表1 故障判定依據及處理措施

序號故障類型故障現象處理措施1功放故障功放故障告警檢修功放2變頻器故障變頻器故障告警檢修變頻器3低噪故障低噪故障告警檢修低噪4調制解調故障調制解調器故障告警檢修調制解調器5調制關閉解調失鎖 and調制發開關關閉打開調制發開關6載波消失解調失鎖 and頻譜消失告警檢查發站發支路連線7載波干擾(解調失鎖or Eb/N0過低) and頻譜干擾告警檢查定位干擾源8發功率低Eb/N0過低 and調制發電平低于目標電平排除天氣、日凌等因素,調整發端功率9主機故障Eb/N0正常 and主機交換機間鏈路中斷 and 交換路由間鏈路正常檢查主機及連線10交換機故障Eb/N0正常 and主機交換機間鏈路中斷 and 交換路由間鏈路中斷檢查交換機及連線11路由器故障Eb/N0正常 and主機交換機間鏈路正常 and交換機路由間鏈路中斷檢查路由器及連線12路由廣域端口連線故障Eb/N0正常 and 主機交換機間鏈路正常 and交換路由間鏈路正常檢修路由器廣域端口與調制解調器連線

3.1.3 故障判定樹模型

故障樹對系統可能的故障原因進行了分析，而判定引起故障具體原因則需要依據判定樹進行。判定樹又叫決策樹，由結點和分枝組成[10,15]。結點分為根結點、判定結點和葉結點，其中判定結點代表一個具體的問題或判定，葉結點代表判定結果或答案。判定推理過程實際就是判定樹的遍歷過程，從根節點開始，直到搜索到問題的正確答案，找到相應的葉結點結束[11,16]。 本系統判定樹模型如圖4所示。

圖4 通信網全鏈路故障判定樹模型

3.2 知識庫構建

3.2.1 知識表示

專家系統的優勢就是通過處理專家提供的知識來解決現實問題。因而開發一個專家系統首先就是把專家的知識表示成推理機所能識別的形式。目前較常用的知識表示方法有 Petri 網、謂詞邏輯、語義網絡、產生式規則、框架等[12]。在CLIPS中知識的表達方式有產生式規則和框架兩種[13]：

① 產生式規則

產生式規則即IF…THEN…的表達形式，如果IF部分滿足則執行THEN之后的動作。

② 框架

框架(frame)是描述事物屬性的一種數據結構。框架的知識表示形式是一種相互嵌套的結構，基本結構如下：

(<框架名> (<槽名 1> (<側面名 1> (<值 1> …)…)…)

(<槽名 2> (<側面名 2> (<值 2> …)…)…)

……)

框架結構具有模塊化的特點，知識可擴充性強，適合表示復雜、層次明顯的知識。

通信網全鏈路告警故障判讀具有復雜性、多樣性和層次性，評估知識是因果關系的產生式規則形式。通信網全鏈路告警故障現象事實、故障判讀規則的前件事實和后件結論事實由框架事實來表示，即系統采用“框架+產生式規則”表示法來表示知識。在 CLIPS 中通過自定義模板deftemplate定義事實模板，通過自定義模板defrule定義推理規則，構建領域專家知識庫。

規則構成了邏輯推理的主要依據，例如：

① Rule1：

功放故障告警

=>

功放故障

② Rule2：

變頻器故障告警

=>

變頻器故障

…

③ Rule9：

Eb/N0正常 and主機到交換機鏈路中斷 and 交換機到路由器鏈路正常

=>

主機故障或主機連線故障

…

一般先定義模板，再定義事實結構，然后建立規則并引用事實進行推理。具體過程如下。

首先自定義3個模板結構分別用于創建故障現象、判讀結果和處置措施3種事實。

(deftemplate fail-facts(slot phenomena))

(deftemplate eval-result(slot result) )

(deftemplate deal-means(slot means))

然后根據故障判定依據及處置措施編寫規則文件。在CLIPS中規則通過defrule命令建立，其一般格式為：“(defrule=> )”，規則中的模式(patterns)代表前提，行為(action)代表結論，構成一個“IF…THEN…”判定結構。

通信網全鏈路故障判讀規則定義如下：

(defrule rule-1

(fail-facts(phenomena PA_Fault_Alert))

=>

(assert(eval-result(result PA_Fault))

(deal_means(means Inspect-PA)))

(defrule rule-2

(fail-facts(phenomenaConvertor_Fault_Alert))

=>

(assert(eval-result(result Convertor_Fault))

(deal_means(means Inspect-Convertor)))

……

(defrule rule-9

(and (fail-facts(phenomenaEbNo_Normal))

(fail-facts(phenomena HS2SW_Halt))

(fail-facts(phenomena SW2ROU_Normal)))

=>

(assert(eval-result(result HOST_Fault))

(deal_means(means Inspect-HostAndCable)))

……

上述規則文本保存在*.clp規則文件中，通過CLIPS工具的CLIPSLoad()函數API加載進行推理。

3.3 推理流程

專家系統中使用推理技術和控制策略進行推理[14]。本系統采用正向推理方法，將通信網全鏈路故障判讀系統和鏈路各環節狀態(現象)監視參數事實聯系起來，由已知的鏈路故障現象推斷出故障對象、原因及相應處置措施。

CLIPS專家系統工具內置強大的推理機，自動完成模式匹配、沖突消解、規則激活及執行。對用戶而言只需根據以下流程依次完成：初始化、規則文件加載、故障事實輸入、運行啟動以及退出等簡單操作。如果推理不成功沒有得到確定的故障判定結果，說明知識庫不完備，缺少相應的知識，需要對知識庫進行完善。具體推理流程如圖5所示。

圖5 推理流程

3.4 CLIPS嵌入編程應用

實用的專家系統，除了要有較完備的知識庫和靈活強大的推理功能外，還應具備強大的數據處理能力和友好的人機交互界面，而CLIPS的優勢僅限于知識庫構建和邏輯推理，因此需要和高級語言配合使用[11]。本文選擇C++作為主體語言，采用動態鏈接庫嵌入的方式將CLIPS專家系統工具集成在系統中，C++主體程序主要代碼如下：

#include“clips.h”

CCLIPSWrap* theCLIPS;

theCLIPS=new CCLIPSWrap;//新建對象

theCLIPS->CLIPSInit();//初始化

theCLIPS->CLIPSLoad();//加載規則

theCLIPS->CLIPSReset();//復位

theCLIPS->CLIPSAssert(+);//輸入事實

theCLIPS->CLIPSRun();//運行

theCLIPS->CLIPSExit();//退出

4 仿真實驗結果與分析

通過對包含衛星網在內的通信網全鏈路建模，設計實現了基于CLIPS的通信全鏈路告警故障自動判讀系統及仿真實驗平臺。如圖6所示，平臺由地面網絡狀態仿真軟件、衛星站狀態仿真軟件、頻譜監視仿真軟件、基于CLIPS的告警故障自動判讀系統等組成。

圖6 仿真實驗平臺組成

仿真實驗平臺中地面網絡狀態仿真軟件用于仿真地面鏈路部分(路由器、交換機、主機等)的狀態，衛星站狀態仿真軟件用于仿真衛通地球站工作狀態(即衛星通信鏈路部分)，頻譜監視仿真軟件用于仿真頻譜監視系統對衛星轉發器載波頻譜狀態的監視。狀態及頻譜采集模塊采集以上各仿真系統產生的鏈路和設備告警狀態、衛星載波頻譜等仿真數據，并轉換為CLIPS自定義事實輸入到CLIPS工具環境。在通信全鏈路出現故障時，系統依據構建的專家知識規則庫對輸入故障現象事實進行推理分析，實時自動判讀出故障對象、原因及應采取的處置措施，通過人機界面通知管理人員。

通過全鏈路各部分仿真軟件，仿真通信網全鏈路多種不同原因引起的故障情況，以驗證基于CLIPS的全鏈路故障自動判讀系統的判讀效果。仿真的故障現象包括：

① 仿真地面鏈路設備的故障(路由器、交換機、主機)；

② 仿真衛星地球站設備故障(功放、變頻器、調制解調器等)；

③ 仿真衛星載波頻譜異常(載波頻譜消失、頻譜干擾)；

④ 仿真Eb/N0低于解調門限閾值現象。

實驗結果表明基于CLIPS的通信網全鏈路告警故障自動判讀系統對于故障機理清楚、診斷規則明確的故障具有判讀定位快、效率高的特點，而對于故障機理模糊、診斷知識缺乏的故障則判讀困難。當多個故障同時出現時診斷準確性也會受到影響，故障自動判讀專家系統的準確程度依賴專家知識的完善性，因此需要不斷分析系統故障機理，改進領域專家知識庫。

5 結束語

系統針對通信網全鏈路告警故障自動判讀難題，為提高故障判讀的的智能化自動化水平，對CLIPS專家系統工具在通信網全鏈路告警故障自動判讀方面的應用進行了研究。通過分析建立了通信網全鏈路告警故障模型，利用CLIPS的deftemplate和defrule定義事實模板和規則，構建了知識庫，實現了領域知識在CLIPS專家系統中的表示，設計實現了基于CLIPS的通信網全鏈路告警故障自動判讀系統及其仿真驗證平臺。仿真結果表明，系統能夠根據發生的多種故障現象智能、自動、準確地判讀出故障對象、原因及應采取的處置措施，從而實現了通信網全鏈路告警故障智能自動判讀的目的。