李斌成，馬宇飛，李培儒

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

0 引言

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

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

1 傳統(tǒng)通信鏈路監(jiān)視的局限

1.1 局限性及分析

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

① 范圍不全，僅衛(wèi)星通信段，未含地面段；

② 層次單一，僅監(jiān)視Eb/N0，沒有關聯(lián)鏈路的故障自動判讀；

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

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

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

1.2 解決思路

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

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

2 專家系統(tǒng)技術概述

2.1 專家系統(tǒng)組成原理

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

圖1 專家系統(tǒng)結構

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

2.2 CLIPS專家系統(tǒng)工具

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

圖2 CLIPS平臺的基本結構

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

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

2.3 CLIPS嵌入技術

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

2.3.1 動態(tài)鏈接庫嵌入

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

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

② 清空CLIPS工作區(qū)CLIPSClear()；

③ 加載規(guī)則文件CLIPSLoad()；

④ 復位知識庫CLIPSReset()；

⑤ 加載事實表CLIPSLoadFacts()；

⑥ 運行CLIPS推理CLIPSRun()；

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

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

2.3.2 直接嵌入

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

① 將源碼加入工程；

② 加入頭文件聲明；

③ 聲明自定義函數(shù)；

④ 編寫自定義函數(shù)；

⑤ 啟動CLIPS。

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

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

3 專家系統(tǒng)在告警判讀中的應用

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

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

3.1.1 全鏈路故障分析

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

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

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

3.1.2 故障樹模型

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

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

表1 故障判定依據(jù)及處理措施

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

3.1.3 故障判定樹模型

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

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

3.2 知識庫構建

3.2.1 知識表示

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

① 產生式規(guī)則

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

② 框架

框架(frame)是描述事物屬性的一種數(shù)據(jù)結構?？蚣艿闹R表示形式是一種相互嵌套的結構，基本結構如下：

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

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

……)

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

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

規(guī)則構成了邏輯推理的主要依據(jù)，例如：

① Rule1：

功放故障告警

=>

功放故障

② Rule2：

變頻器故障告警

=>

變頻器故障

…

③ Rule9：

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

=>

主機故障或主機連線故障

…

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

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

(deftemplate fail-facts(slot phenomena))

(deftemplate eval-result(slot result) )

(deftemplate deal-means(slot means))

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

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

(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)))

……

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

3.3 推理流程

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

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

圖5 推理流程

3.4 CLIPS嵌入編程應用

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

#include“clips.h”

CCLIPSWrap* theCLIPS;

theCLIPS=new CCLIPSWrap;//新建對象

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

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

theCLIPS->CLIPSReset();//復位

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

theCLIPS->CLIPSRun();//運行

theCLIPS->CLIPSExit();//退出

4 仿真實驗結果與分析

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

圖6 仿真實驗平臺組成

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

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

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

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

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

④ 仿真Eb/N0低于解調門限閾值現(xiàn)象。

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

5 結束語

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