基于SOA的設(shè)備遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)體系結(jié)構(gòu)研究

楊 斌，張衛(wèi)冬，伍章明，張利欣

(1.北京科技大學(xué) 國(guó)家材料服役安全科學(xué)中心，北京 100083;2.阿斯頓大學(xué) 工程與應(yīng)用科學(xué)學(xué)院，英國(guó) 伯明翰)

設(shè)備遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)，即利用現(xiàn)代化通信技術(shù)實(shí)現(xiàn)異地監(jiān)測(cè)與診斷的行為。通過設(shè)備故障診斷技術(shù)與分布式計(jì)算機(jī)技術(shù)相結(jié)合，一方面在企業(yè)內(nèi)部建立狀態(tài)監(jiān)測(cè)服務(wù)器，在關(guān)鍵設(shè)備上安裝監(jiān)測(cè)點(diǎn)，將實(shí)時(shí)采集的數(shù)據(jù)存入服務(wù)器;另一方面在技術(shù)力量較強(qiáng)的高校、研究所建立相應(yīng)的故障診斷中心，設(shè)立故障診斷服務(wù)器，隨時(shí)為企業(yè)提供遠(yuǎn)程技術(shù)支持等服務(wù)，在企業(yè)和科研院所之間形成一個(gè)跨越地理位置的互聯(lián)診斷網(wǎng)絡(luò)。當(dāng)現(xiàn)場(chǎng)設(shè)備運(yùn)行出現(xiàn)異常，其狀態(tài)監(jiān)測(cè)服務(wù)器便會(huì)向遠(yuǎn)方的診斷分析服務(wù)器發(fā)出診斷請(qǐng)求，并可通過各種通訊方式向分布在不同區(qū)域的專家發(fā)出請(qǐng)求，在短時(shí)間內(nèi)啟動(dòng)網(wǎng)內(nèi)診斷資源，實(shí)現(xiàn)對(duì)設(shè)備故障的早期診斷和及時(shí)維修［1，2］。

在設(shè)備遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)中，一方面隨著各種信息和計(jì)算機(jī)技術(shù)(如CORBA、COM、Web Service、XML、P2P等)的發(fā)展，這些技術(shù)在設(shè)備遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)中得到廣泛應(yīng)用，分布式軟件、應(yīng)用集成平臺(tái)、各種語(yǔ)言和協(xié)議等在應(yīng)用中的復(fù)雜性問題變得日益突出;另一方面目前國(guó)內(nèi)的大型企業(yè)(如石化、鋼鐵冶金、電力等)內(nèi)部都擁有不同規(guī)模、不同平臺(tái)、面向不同用戶、在線或離線的監(jiān)測(cè)系統(tǒng)，每套監(jiān)測(cè)系統(tǒng)都擁有獨(dú)特的數(shù)據(jù)存儲(chǔ)方式、數(shù)據(jù)格式、診斷方法和診斷規(guī)則。由于運(yùn)行時(shí)間長(zhǎng)短不同，每套系統(tǒng)積累的數(shù)據(jù)和資源也大不相同。這些數(shù)據(jù)和資源對(duì)于企業(yè)實(shí)現(xiàn)預(yù)知維修，減少故障停機(jī)次數(shù)，提高生產(chǎn)效率和經(jīng)濟(jì)效益有著不可估量的價(jià)值。但現(xiàn)有的監(jiān)測(cè)系統(tǒng)很少能將這些數(shù)據(jù)和資源進(jìn)行充分整合和利用，很多企業(yè)甚至不得不將這些數(shù)據(jù)拋棄而造成了資源和資金的極大浪費(fèi)。

因此，針對(duì)現(xiàn)有的監(jiān)測(cè)與診斷系統(tǒng)，如何進(jìn)行數(shù)據(jù)與資源的整合以及解決系統(tǒng)中的異構(gòu)和復(fù)雜性問題，就顯得十分重要。本論文提出了一種面向服務(wù)(Service-Oriented Architecture，SOA)［3］的平臺(tái)架構(gòu)方案，旨在通過利用SOA的架構(gòu)思想為企業(yè)構(gòu)建一個(gè)可擴(kuò)展、易維護(hù)、松耦合的設(shè)備遠(yuǎn)程監(jiān)測(cè)與故障診斷平臺(tái)，從而實(shí)現(xiàn)對(duì)各類監(jiān)測(cè)與診斷資源、數(shù)據(jù)和方法的整合以及對(duì)未來(lái)新的監(jiān)測(cè)技術(shù)、監(jiān)測(cè)手段和診斷方法的持續(xù)支持。

1 SOA的核心思想及其服務(wù)模型

1.1 核心思想

面向SOA的架構(gòu)是一種設(shè)計(jì)方式，指導(dǎo)著業(yè)務(wù)服務(wù)在其生命周期中包括創(chuàng)建和使用的各個(gè)方面。SOA也是一種定義和提供信息結(jié)構(gòu)的方式，它允許不同應(yīng)用相互交換數(shù)據(jù)、參與業(yè)務(wù)流程，無(wú)論它們使用的是何種操作系統(tǒng)或者采用了何種編程語(yǔ)言。

現(xiàn)代的設(shè)備遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)大多是利用計(jì)算機(jī)網(wǎng)絡(luò)構(gòu)成的分布式信息系統(tǒng)。復(fù)雜性是信息系統(tǒng)必須面對(duì)的一個(gè)重要現(xiàn)實(shí)，無(wú)論是構(gòu)建新應(yīng)用、替換現(xiàn)有應(yīng)用，還是處理各種維護(hù)與改進(jìn)需要，都需要處理各種復(fù)雜狀況。面向服務(wù)的架構(gòu)和面向服務(wù)的開發(fā)通過使用公共編程接口及互操作協(xié)議，降低了信息系統(tǒng)的復(fù)雜性，具有可重用性高的特點(diǎn)。公共編程接口統(tǒng)一了應(yīng)用(服務(wù)和系統(tǒng))的使用方式，而通過使用公共編程接口，可以很輕松的實(shí)現(xiàn)、替換和更新系統(tǒng)。

基于SOA的設(shè)備遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)并不是一個(gè)全新的事物，事實(shí)上在基于CORBA的系統(tǒng)［5］中就有很多部署都是面向服務(wù)的架構(gòu)，其新穎之處在于SOA能夠混搭各種執(zhí)行環(huán)境、服務(wù)接口與執(zhí)行技術(shù)明確分離，并采用一致的架構(gòu)方式將它們以“松耦合”的方式結(jié)合起來(lái)。然而，先前的大多數(shù)監(jiān)測(cè)與診斷系統(tǒng)，都是基于單一的執(zhí)行環(huán)境的“緊耦合”系統(tǒng)。

SOA主要是通過文本文件來(lái)實(shí)現(xiàn)服務(wù)與執(zhí)行環(huán)境的分離，而且分離得更明確，傳統(tǒng)的接口實(shí)現(xiàn)沒有考慮這種“松散的”分離，因?yàn)樗鼤?huì)影響效率。隨著計(jì)算機(jī)的硬件性能不斷提高，這種影響已越來(lái)越小，而如何在信息系統(tǒng)中獲得更強(qiáng)的互操作性遠(yuǎn)比效率問題更為重要。

因此，構(gòu)建基于SOA的設(shè)備遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)，其本質(zhì)是如何通過以文本文件方式描述的公共編程接口、服務(wù)以及服務(wù)間的互操作協(xié)議把不同“粒度”的監(jiān)測(cè)與診斷服務(wù)進(jìn)行整合，從而實(shí)現(xiàn)、替換和更新系統(tǒng)［4］。

1.2 服務(wù)模型

服務(wù)是由它所支持的消息交換模式所定義的。消息中包含的數(shù)據(jù)應(yīng)具有相應(yīng)的模式，用于在服務(wù)請(qǐng)求者與服務(wù)提供者之間建立描述。同時(shí)，其它一些元數(shù)據(jù)則描述了服務(wù)的網(wǎng)絡(luò)地址、所支持的操作，以及對(duì)可靠性、安全性及事務(wù)性方面的要求。

通常的服務(wù)包含服務(wù)描述、服務(wù)實(shí)現(xiàn)和服務(wù)映射三個(gè)方面。服務(wù)的請(qǐng)求者通過服務(wù)描述和服務(wù)映射層可以獲取服務(wù)實(shí)現(xiàn)，而同時(shí)服務(wù)實(shí)現(xiàn)可能會(huì)調(diào)用另一個(gè)服務(wù)的功能。

SOA及服務(wù)中的元數(shù)據(jù)即服務(wù)的描述信息，元數(shù)據(jù)通常包含以下幾個(gè)部分:①服務(wù)的名稱，服務(wù)的唯一標(biāo)識(shí);②消息數(shù)據(jù)，用于定義消息中的數(shù)據(jù)類型、數(shù)據(jù)結(jié)構(gòu)以及消息間的交換模式;③地址數(shù)據(jù)，服務(wù)名稱的網(wǎng)絡(luò)地址，用于服務(wù)的尋址;④服務(wù)質(zhì)量，包含安全性、可靠性、事務(wù)性等服務(wù)策略。

任何能夠提供服務(wù)支持的組件或系統(tǒng)都可以成為服務(wù)實(shí)現(xiàn)。服務(wù)實(shí)現(xiàn)負(fù)責(zé)實(shí)現(xiàn)各種Web服務(wù)規(guī)范中定義的Web服務(wù)模型。服務(wù)的定義中一個(gè)重要方面是服務(wù)描述與服務(wù)實(shí)現(xiàn)是分開的。一個(gè)服務(wù)描述可以有多個(gè)不同的服務(wù)實(shí)現(xiàn)與之關(guān)聯(lián)，服務(wù)描述通過一個(gè)服務(wù)映射實(shí)現(xiàn)與執(zhí)行環(huán)境分離。服務(wù)映射負(fù)責(zé)接受消息、轉(zhuǎn)換數(shù)據(jù)以及傳輸數(shù)據(jù)。

本文所闡述的系統(tǒng)正是以這種服務(wù)抽象模型，對(duì)監(jiān)測(cè)與診斷系統(tǒng)中各類應(yīng)用進(jìn)行不同層次、不同粒度的抽象，從而將整個(gè)監(jiān)測(cè)與診斷的系統(tǒng)細(xì)分為許多個(gè)“松耦合”的服務(wù)實(shí)現(xiàn)、服務(wù)描述和服務(wù)映射。這種方式構(gòu)建的監(jiān)測(cè)與診斷系的優(yōu)勢(shì)是:易于訪問不同類型的服務(wù)和使用各種功能模塊，如新開發(fā)的服務(wù)，整合已有的應(yīng)用系統(tǒng)以及使用由第三方提供的服務(wù)。

2 面向SOA的遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)

2.1 遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)的功能抽象

面向SOA的遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)不同于傳統(tǒng)的分布式架構(gòu)系統(tǒng)［6－8］，其主要區(qū)別在于服務(wù)的抽象和系統(tǒng)的松耦合性，可以根據(jù)業(yè)務(wù)邏輯和功能需求將系統(tǒng)抽象為不同層次、不同粒度的服務(wù)。通過這些服務(wù)的組合和互操作構(gòu)建整個(gè)系統(tǒng)，具有更好的可重構(gòu)性和擴(kuò)展性。因此，在設(shè)計(jì)面向SOA的遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)之前必須對(duì)業(yè)務(wù)邏輯和功能需求進(jìn)行多層次抽象。

遠(yuǎn)程監(jiān)測(cè)系統(tǒng)主要有兩大功能:一方面是負(fù)責(zé)將現(xiàn)場(chǎng)前端采集系統(tǒng)獲取的信號(hào)數(shù)據(jù)，經(jīng)過處理、抽取和分析實(shí)時(shí)傳向監(jiān)測(cè)客戶端，在監(jiān)測(cè)客戶端以各種圖表方式實(shí)時(shí)顯示設(shè)備運(yùn)行狀態(tài);另一方面是將這些信號(hào)數(shù)據(jù)存入數(shù)據(jù)庫(kù)，提供數(shù)據(jù)查詢功能，展示設(shè)備的歷史運(yùn)行狀態(tài)。因此遠(yuǎn)程監(jiān)測(cè)系統(tǒng)可以抽象為以下幾個(gè)方面:① 信號(hào)的獲取，即前端采集系統(tǒng)實(shí)時(shí)獲取各類監(jiān)測(cè)信號(hào);② 信號(hào)的處理與分析，包括信號(hào)的降噪、計(jì)算特征值、報(bào)警狀態(tài)判斷和頻譜分析等;③ 信號(hào)的顯示，通過波形曲線、棒圖和數(shù)據(jù)表格等多種方式顯示信號(hào);④ 信號(hào)的存儲(chǔ)，將信號(hào)分類存入數(shù)據(jù)庫(kù)以供查詢;⑤信號(hào)的查詢，通常包含某個(gè)時(shí)間點(diǎn)的信號(hào)細(xì)節(jié)查詢和某個(gè)時(shí)間段的變化趨勢(shì)等方面的查詢。

故障診斷系統(tǒng)主要是利用實(shí)時(shí)或歷史數(shù)據(jù)，通過各種診斷方法設(shè)備運(yùn)行狀況進(jìn)行診斷。同時(shí)，系統(tǒng)可以根據(jù)用戶的請(qǐng)求對(duì)設(shè)備的運(yùn)行狀態(tài)信號(hào)進(jìn)行分析，給出診斷結(jié)果。在交互式診斷中用戶也可以向遠(yuǎn)程診斷中心提出更高級(jí)的診斷請(qǐng)求(如專家診斷)，或?qū)⒆约旱脑\斷結(jié)果提交到診斷中心，作為典型診斷案例。因此遠(yuǎn)程故障診斷系統(tǒng)可以抽象為以下幾個(gè)方面:①診斷流程和規(guī)則，無(wú)論是用戶的自助診斷還是交互式診斷都需要基于特定設(shè)備的一些診斷流程和規(guī)則;②診斷方法，如目前常用的模糊推理和故障樹等方法;③知識(shí)庫(kù)，不同的設(shè)備其診斷機(jī)理通常會(huì)有較大差異，需要利用知識(shí)庫(kù)提供多種故障診斷規(guī)則、分析規(guī)則和故障排除規(guī)則;④ 案例庫(kù)，設(shè)備的故障診斷是診斷經(jīng)驗(yàn)十分重要的實(shí)踐科學(xué)，建立典型案例庫(kù)的目的就是不斷積累實(shí)際的診斷經(jīng)驗(yàn)。

2.2 遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)體系結(jié)構(gòu)

在對(duì)監(jiān)測(cè)和診斷的業(yè)務(wù)邏輯和功能需求分析和抽象的基礎(chǔ)上，結(jié)合SOA的設(shè)計(jì)思想，可以將整個(gè)體系結(jié)構(gòu)劃分為基礎(chǔ)數(shù)據(jù)源層、細(xì)粒度的功能模塊和粗粒度服務(wù)層。基礎(chǔ)數(shù)據(jù)源層主要是系統(tǒng)的數(shù)據(jù)來(lái)源，設(shè)備監(jiān)測(cè)和診斷的基礎(chǔ)都是對(duì)測(cè)點(diǎn)信號(hào)數(shù)據(jù)的顯示和分析。細(xì)粒度功能服務(wù)層主要通過監(jiān)測(cè)或診斷的業(yè)務(wù)邏輯來(lái)抽象出通用的細(xì)粒度功能模塊，以便通過這些模塊的組合和集成實(shí)現(xiàn)更粗粒度的服務(wù)。粗粒度服務(wù)層即提供面向用戶的功能服務(wù)。同時(shí)，這些功能服務(wù)通過企業(yè)服務(wù)總線［9］向企業(yè)級(jí)或遠(yuǎn)程級(jí)的用戶發(fā)布。遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)的體系結(jié)構(gòu)如圖1所示。

圖1 狀態(tài)監(jiān)測(cè)與診斷系統(tǒng)的軟件體系結(jié)構(gòu)Fig.1 Software Architecture of conditions monitoring and fault diagnosis

2.3 基礎(chǔ)數(shù)據(jù)源和細(xì)粒度功能模塊設(shè)計(jì)

2.3.1 信號(hào)采集適配器

信號(hào)采集適配器負(fù)責(zé)現(xiàn)場(chǎng)前端信號(hào)采集系統(tǒng)與監(jiān)測(cè)診斷系統(tǒng)中各功能服務(wù)之間的數(shù)據(jù)連接。通常企業(yè)中存在多種前端信號(hào)采集系統(tǒng)所提供的數(shù)據(jù)格式、采集方式都不相同。因此，信息采集適配器主要是為了屏蔽這種差異性，為后面的各個(gè)服務(wù)功能提供統(tǒng)一的信號(hào)數(shù)據(jù)獲取接口。信號(hào)采集適配器的主要功能只是對(duì)通訊協(xié)議和數(shù)據(jù)格式進(jìn)行統(tǒng)一的轉(zhuǎn)換，并不對(duì)信號(hào)本身處理。

傳統(tǒng)的集中式數(shù)據(jù)流方式是使用特定的服務(wù)器應(yīng)用程序收集所有前端系統(tǒng)的監(jiān)測(cè)點(diǎn)數(shù)據(jù)，再通過集中的數(shù)據(jù)中心向外提供監(jiān)測(cè)數(shù)據(jù)服務(wù)。顯然，這種方式的缺陷是集中式數(shù)據(jù)中心的運(yùn)行異常或故障將導(dǎo)致整個(gè)監(jiān)測(cè)系統(tǒng)的崩潰。與此不同，面向服務(wù)的設(shè)計(jì)使得任何一個(gè)數(shù)據(jù)源本身都可以成為數(shù)據(jù)服務(wù)的提供者和使用者。圖2顯示了這種既分散又集中的數(shù)據(jù)流服務(wù)方式。

圖2 面向服務(wù)的監(jiān)測(cè)信號(hào)數(shù)據(jù)流Fig.2 Monitoring signal data stream oriented service

2.3.2 負(fù)載均衡與服務(wù)調(diào)度模塊在實(shí)時(shí)監(jiān)測(cè)系統(tǒng)中，通常會(huì)出現(xiàn)有限的計(jì)算機(jī)資源和大量客戶端并發(fā)請(qǐng)求之間的矛盾，為了保證這些應(yīng)用服務(wù)的穩(wěn)定運(yùn)行，必須在各應(yīng)用服務(wù)中使用負(fù)載均衡模塊控制客戶端的連接和優(yōu)化計(jì)算機(jī)的資源分配。權(quán)重均衡算法可以根據(jù)每個(gè)請(qǐng)求(或服務(wù))所需要的不同的處理能力，給每個(gè)請(qǐng)求分配不同的權(quán)值，當(dāng)接受相應(yīng)權(quán)值的服務(wù)請(qǐng)求時(shí)根據(jù)服務(wù)的權(quán)值計(jì)算負(fù)載狀態(tài)，可以基本確保服務(wù)器和其上服務(wù)的穩(wěn)定運(yùn)行。因此，權(quán)重均衡算法可以作為負(fù)載均衡模塊的核心算法。

不同于傳統(tǒng)的分布式系統(tǒng)客戶端程序的請(qǐng)求與服務(wù)器程序的相應(yīng)之間是一一對(duì)應(yīng)的緊耦合聯(lián)系，在SOA中一個(gè)相同的客戶端請(qǐng)求在系統(tǒng)中可能存在多個(gè)對(duì)應(yīng)的服務(wù)的提供者，因此選擇一個(gè)合適的服務(wù)提供者不僅可以加快服務(wù)響應(yīng)速度還可以合理分配計(jì)算機(jī)資源達(dá)到負(fù)載均衡的目的。負(fù)載均衡與服務(wù)調(diào)度模塊的運(yùn)行流程如圖3所示，負(fù)載均衡實(shí)際上起到了資源與服務(wù)分配的作用，只有分配成功后才能夠提交至Web服務(wù)，在服務(wù)完成后減少當(dāng)前負(fù)載數(shù)(釋放資源)。

圖3 負(fù)載均衡模塊的運(yùn)行流程Fig.3 Running flowchart of load balance model

2.3.3 監(jiān)測(cè)系統(tǒng)數(shù)據(jù)庫(kù)設(shè)計(jì)

監(jiān)測(cè)系統(tǒng)數(shù)據(jù)庫(kù)的設(shè)計(jì)原則是便于監(jiān)測(cè)數(shù)據(jù)的存儲(chǔ)和查詢，在監(jiān)測(cè)系統(tǒng)中最小的信息單元是測(cè)點(diǎn)［10］。因此，本文中根據(jù)獨(dú)立的單一測(cè)點(diǎn)作為庫(kù)表結(jié)構(gòu)的基本單元作為設(shè)計(jì)和建立數(shù)據(jù)庫(kù)的準(zhǔn)則。在頂層有一個(gè)root數(shù)據(jù)庫(kù)，root數(shù)據(jù)庫(kù)包含兩個(gè)表:機(jī)組信息表和機(jī)組數(shù)據(jù)庫(kù)信息表，機(jī)組信息表存儲(chǔ)了機(jī)組的編號(hào)、名稱、描述、機(jī)組簡(jiǎn)圖以及測(cè)點(diǎn)分布情況等;機(jī)組數(shù)據(jù)庫(kù)信息表存儲(chǔ)了后續(xù)子庫(kù)(機(jī)組數(shù)據(jù)庫(kù))的連接信息和庫(kù)表結(jié)構(gòu)。root數(shù)據(jù)庫(kù)是整個(gè)監(jiān)測(cè)系統(tǒng)數(shù)據(jù)庫(kù)的入口，設(shè)計(jì)root數(shù)據(jù)庫(kù)可以動(dòng)態(tài)維護(hù)后續(xù)子庫(kù)的信息和庫(kù)表結(jié)構(gòu)，便于擴(kuò)展。由于各個(gè)機(jī)組數(shù)據(jù)庫(kù)測(cè)點(diǎn)及測(cè)量值的差異性，因此需要?jiǎng)討B(tài)創(chuàng)建各個(gè)機(jī)組數(shù)據(jù)庫(kù)。

2.3.4 故障診斷知識(shí)庫(kù)和案例庫(kù)

故障診斷和推理是一個(gè)基于知識(shí)與經(jīng)驗(yàn)的分析過程，因此通常需要根據(jù)不同類型的診斷對(duì)象(設(shè)備)建立完善的知識(shí)庫(kù)與案例庫(kù)［11］。

故障診斷知識(shí)庫(kù)通常采用多庫(kù)結(jié)構(gòu)的組織模式:設(shè)備信息庫(kù)、故障征兆庫(kù)和診斷規(guī)則庫(kù)。這種結(jié)構(gòu)模式可以提高系統(tǒng)工作效率，也便于知識(shí)的搜索。各庫(kù)之間相互獨(dú)立，某個(gè)庫(kù)的修改不會(huì)影響其它庫(kù)，其結(jié)構(gòu)如圖4所示。

圖4 診斷知識(shí)庫(kù)層次結(jié)構(gòu)Fig.4 Hierarchical structure of fault diagnosis knowledge base

設(shè)備信息庫(kù)包含設(shè)備結(jié)構(gòu)、運(yùn)行規(guī)范和運(yùn)行參數(shù)等信息，是故障診斷重要的背景信息。

對(duì)于設(shè)備運(yùn)行中常見的一些故障類型通常會(huì)有特定的征兆與之對(duì)應(yīng)，故障征兆庫(kù)用于存放故障經(jīng)分類整理后表現(xiàn)出來(lái)的征兆，由征兆屬性和征兆值組成，對(duì)于每個(gè)征兆屬性通常有若干個(gè)征兆值(如振動(dòng)特性、溫度等)。

診斷規(guī)則庫(kù)中的規(guī)則分成三組:故障診斷規(guī)則組、故障原因分析規(guī)則組和故障排除措施規(guī)則組，表達(dá)形式如下。

故障診斷規(guī)則組:［數(shù)據(jù)，事實(shí)］→故障類型;

故障原因分析規(guī)則組:［事實(shí)，故障類型］→故障原因;

故障消除措施規(guī)則組:［事實(shí)，故障類型，故障原因］→故障排除指導(dǎo)。

案例庫(kù)的建立主要是對(duì)現(xiàn)有案例的表示、組織與存儲(chǔ)［12］。案例的表示必須能夠清楚地表達(dá)出故障類型、表現(xiàn)形式、因果關(guān)系及故障機(jī)理，案例組織與存儲(chǔ)結(jié)構(gòu)則關(guān)系到案例檢索的效率。為了使案例庫(kù)能夠方便地進(jìn)行案例的新增、修改、刪除等操作和維護(hù)，本文設(shè)計(jì)了故障案例種類表、故障案例表、故障案例特征表三個(gè)關(guān)系數(shù)據(jù)表用于描述案例庫(kù)的各項(xiàng)信息。故障案例種類表記錄了故障案例中的典型案例種類;故障案例表記錄了每個(gè)案例的詳細(xì)信息，其中包括故障現(xiàn)象、征兆、解決方法等;故障案例特征表記錄對(duì)應(yīng)案例的各特征屬性(振動(dòng)特征量、溫度、壓力等)的值。

遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)針對(duì)上述基礎(chǔ)數(shù)據(jù)源和細(xì)粒度功能模塊設(shè)計(jì)，使得整個(gè)監(jiān)測(cè)系統(tǒng)具有良好的擴(kuò)展性，其中信號(hào)采集適配器屏蔽了底層數(shù)據(jù)采集的差異，同時(shí)配合靈活的數(shù)據(jù)庫(kù)系統(tǒng)設(shè)計(jì)使得增加新的數(shù)據(jù)采集模塊只需簡(jiǎn)單配置數(shù)據(jù)庫(kù)服務(wù)器即可完成。另外，負(fù)載均衡與服務(wù)調(diào)度模塊可以靈活應(yīng)對(duì)客戶端數(shù)量的擴(kuò)展，均衡系統(tǒng)資源，提高客戶端服務(wù)的實(shí)時(shí)性。

2.4 監(jiān)測(cè)系統(tǒng)關(guān)鍵服務(wù)設(shè)計(jì)

2.4.1 測(cè)點(diǎn)信息服務(wù)

測(cè)點(diǎn)信息服務(wù)主要包含兩類任務(wù)，一方面是面向采集適配器為各個(gè)測(cè)點(diǎn)提供信息的注冊(cè)與注銷，在服務(wù)內(nèi)維護(hù)一個(gè)所有測(cè)點(diǎn)信息的列表，發(fā)布的相關(guān)接口提供測(cè)點(diǎn)信息的添加、刪除或更新;另一方面是面向客戶端測(cè)點(diǎn)信息的各種查詢服務(wù)。測(cè)點(diǎn)信息服務(wù)發(fā)布的Web Service包含如下6個(gè)接口:① 測(cè)點(diǎn)注冊(cè)，注冊(cè)測(cè)點(diǎn)信息，如果測(cè)點(diǎn)重合則更新當(dāng)前測(cè)點(diǎn)信息;② 測(cè)點(diǎn)注銷，刪除測(cè)點(diǎn)停止同時(shí)通知其他服務(wù)/模塊，停止該測(cè)點(diǎn)的相關(guān)信息和數(shù)據(jù)服務(wù);③ 測(cè)點(diǎn)更新，更新某個(gè)測(cè)點(diǎn)的相關(guān)信息;④ 單個(gè)測(cè)點(diǎn)查詢，利用測(cè)點(diǎn)ID查詢相關(guān)信息;⑤ 機(jī)組測(cè)點(diǎn)查詢，根據(jù)機(jī)組名稱(或其他唯一標(biāo)識(shí))查詢?cè)摍C(jī)組對(duì)應(yīng)的測(cè)點(diǎn)列表;⑥ 全部測(cè)點(diǎn)查詢，返回系統(tǒng)內(nèi)所有測(cè)點(diǎn)信息。為了方便測(cè)點(diǎn)信息的結(jié)構(gòu)本身的擴(kuò)展與修改，測(cè)點(diǎn)信息按照XML規(guī)范組織，測(cè)點(diǎn)信息文檔的根節(jié)點(diǎn)是“ROOT”，下一級(jí)節(jié)點(diǎn)為機(jī)組節(jié)點(diǎn)，機(jī)組節(jié)點(diǎn)下一級(jí)是該機(jī)組擁有測(cè)點(diǎn)類型的種類列表(加速度、速度或溫度等)。

2.4.2 實(shí)時(shí)波形數(shù)據(jù)服務(wù)

實(shí)時(shí)波形數(shù)據(jù)服務(wù)是指向客戶端提供信號(hào)的實(shí)時(shí)的原始波形數(shù)據(jù)和根據(jù)對(duì)應(yīng)的原始波形數(shù)據(jù)計(jì)算出的頻譜數(shù)據(jù)。

實(shí)時(shí)波形數(shù)據(jù)服務(wù)包括兩類操作:一類是當(dāng)實(shí)時(shí)波形數(shù)據(jù)服務(wù)接收到由監(jiān)測(cè)適配器傳來(lái)的測(cè)點(diǎn)采集數(shù)據(jù)后，進(jìn)行緩存并調(diào)用信號(hào)處理Web Service服務(wù)進(jìn)行頻譜計(jì)算;另一類是當(dāng)接收到客戶端的實(shí)時(shí)波形數(shù)據(jù)請(qǐng)求時(shí)，返回緩存的測(cè)點(diǎn)采集數(shù)據(jù)和頻譜數(shù)據(jù)。數(shù)據(jù)操作流程如圖5所示。

圖5 實(shí)時(shí)波形數(shù)據(jù)服務(wù)流程Fig.5 Sevice flowchart of realtime wave data

2.4.3 實(shí)時(shí)特征值服務(wù)

實(shí)時(shí)特征值服務(wù)的實(shí)現(xiàn)方式、數(shù)據(jù)流程與實(shí)時(shí)波形數(shù)據(jù)服務(wù)完全相同，不同是需要根據(jù)接收到的波形數(shù)據(jù)計(jì)算其特征值并傳遞給客戶端。

此外實(shí)時(shí)特征值服務(wù)還有兩個(gè)附加的功能:①根據(jù)計(jì)算出的特征值服務(wù)判斷當(dāng)前的數(shù)據(jù)是否超過了預(yù)設(shè)的報(bào)警線，如果超過則需要將對(duì)應(yīng)的數(shù)據(jù)(原始波形和特征值數(shù)據(jù))發(fā)送至實(shí)時(shí)報(bào)警數(shù)據(jù)服務(wù)中進(jìn)行緩存;②將計(jì)算出的特征值數(shù)據(jù)(包含報(bào)警狀態(tài)信息)發(fā)送至歷史數(shù)據(jù)庫(kù)模塊進(jìn)行存儲(chǔ)。

2.4.4 測(cè)點(diǎn)信號(hào)數(shù)據(jù)存儲(chǔ)服務(wù)

測(cè)點(diǎn)數(shù)據(jù)存儲(chǔ)服務(wù)的主要任務(wù)是在接收到其它各個(gè)服務(wù)模塊發(fā)送來(lái)的信號(hào)原始數(shù)據(jù)或特征值數(shù)據(jù)時(shí)調(diào)用數(shù)據(jù)庫(kù)操作模塊進(jìn)行數(shù)據(jù)存儲(chǔ)。為了能夠?qū)崿F(xiàn)更高效率的數(shù)據(jù)存儲(chǔ)，可以使用存儲(chǔ)過程。由于振動(dòng)信號(hào)的波形數(shù)據(jù)的數(shù)據(jù)量較大，因此在存儲(chǔ)這類數(shù)據(jù)時(shí)需要做特殊的處理。本文引用一種“記錄－文件”的方式進(jìn)行處理，將實(shí)際的振動(dòng)波形數(shù)據(jù)存儲(chǔ)在基于XML規(guī)范的數(shù)據(jù)文件中，同時(shí)在數(shù)據(jù)庫(kù)中記錄該文件的相關(guān)信息(即建立文件索引)，便于將來(lái)的查詢。本文使用XML規(guī)范存儲(chǔ)數(shù)據(jù)主要考慮到數(shù)據(jù)文件格式的可擴(kuò)展性。

測(cè)點(diǎn)數(shù)據(jù)存儲(chǔ)服務(wù)屬于系統(tǒng)內(nèi)部服務(wù)，因此無(wú)需提供外部調(diào)用接口，但仍然需要與SOA基礎(chǔ)架構(gòu)有交互服務(wù)的操作接口。

2.4.5 歷史波形和特征值查詢服務(wù)

由于歷史波形數(shù)據(jù)存儲(chǔ)在特定的數(shù)據(jù)文件中，因此歷史波形查詢服務(wù)在接收到客戶端的查詢請(qǐng)求時(shí)需要先搜索在數(shù)據(jù)庫(kù)中的文件記錄，再根據(jù)文件的記錄信息訪問實(shí)際的波形數(shù)據(jù)文件，然后需要調(diào)用信號(hào)處理Web Service服務(wù)計(jì)算頻譜數(shù)據(jù)，經(jīng)過封裝后返回給客戶端。

在進(jìn)行歷史特征值數(shù)據(jù)查詢時(shí)需要提供查詢的起始時(shí)間和終止時(shí)間，即查詢的時(shí)間跨度。時(shí)間跨度短的查詢可以直接查詢和返回查詢結(jié)果，但對(duì)于時(shí)間跨度長(zhǎng)的查詢，其查詢結(jié)果和數(shù)據(jù)將非常龐大，不適合直接使用網(wǎng)絡(luò)傳輸。考慮到歷史特征值數(shù)據(jù)查詢的應(yīng)用大多是進(jìn)行查看數(shù)據(jù)的歷史趨勢(shì)，因此本文對(duì)于大跨度時(shí)間的查詢進(jìn)行數(shù)據(jù)提取，在保證原有數(shù)據(jù)變化趨勢(shì)不變的情況下，提取可以表征趨勢(shì)特征的關(guān)鍵數(shù)據(jù)點(diǎn)以減少數(shù)據(jù)量。

趨勢(shì)數(shù)據(jù)的提取策略可以有很多種，本文使用定時(shí)間段極值提取策略:①首先確定一個(gè)定時(shí)間段;②然后按照最為重要的特征值(如振動(dòng)信號(hào)的均方根值)將該時(shí)間段中的數(shù)據(jù)描繪為曲線并求出所有的極值點(diǎn);③最后將得到的極值點(diǎn)作為提取的特征點(diǎn)存儲(chǔ)在數(shù)據(jù)庫(kù)中。這種提取策略的優(yōu)勢(shì)是可以保留所有趨勢(shì)中的拐點(diǎn)數(shù)據(jù)，但是需要研究合理的時(shí)間段。

2.5 診斷系統(tǒng)關(guān)鍵服務(wù)設(shè)計(jì)

通常對(duì)于不同的診斷任務(wù)，其診斷難度和故障的嚴(yán)重程度往往差別很大，有的故障可能通過信號(hào)頻譜分析就可以得到較為準(zhǔn)確的結(jié)果，而某些較為復(fù)雜故障的診斷往往需要領(lǐng)域?qū)＜覀兊膮f(xié)同診斷。因此，在面向服務(wù)的監(jiān)測(cè)與診斷系統(tǒng)中分別為不同難度、不同層次的診斷需求提供了三種類型的診斷服務(wù):自助診斷、交互式診斷和專家診斷。

2.5.1 自助診斷服務(wù)

自助診斷服務(wù)是指用戶通過向診斷系統(tǒng)提交故障的描述、故障信號(hào)以及其他相關(guān)信息后，再選定對(duì)應(yīng)信號(hào)分析方法和診斷規(guī)則，利用診斷推理機(jī)自動(dòng)獲取診斷結(jié)果的診斷方式。利用自助診斷服務(wù)用戶可自主分析、查詢?cè)O(shè)備故障原因，作為診斷參考。自助診斷的流程圖如下圖6所示。

圖6 自助診斷流程圖Fig.6 Self-assist diagnosis flowchart

2.5.2 交互式診斷和專家診斷服務(wù)

交互式診斷是通過用戶和專家交互的方式進(jìn)行故障診斷。用戶提出診斷請(qǐng)求，診斷平臺(tái)管理員將請(qǐng)求分配給相關(guān)的診斷專家，專家做出診斷結(jié)論并反饋給用戶，用戶根據(jù)診斷結(jié)論對(duì)設(shè)備做出相應(yīng)處理，如果處理效果不明顯，用戶可以進(jìn)一步將處理結(jié)果提供給專家，專家再一次對(duì)請(qǐng)求給出診斷結(jié)論，此過程可以反復(fù)進(jìn)行，直到用戶對(duì)診斷結(jié)果表示滿意為止，完成一次交互式診斷。

專家診斷服務(wù)的發(fā)起者是請(qǐng)求用戶，但用戶的請(qǐng)求需要系統(tǒng)管理員驗(yàn)證，只有達(dá)到專家診斷的級(jí)別的故障案例才能通過驗(yàn)證。管理員根據(jù)請(qǐng)求確定參加這次專家會(huì)診的專家列表，將請(qǐng)求發(fā)送給這些專家。這些專家根據(jù)用戶提出的請(qǐng)求信息，通過系統(tǒng)提供的診斷方法，經(jīng)過分析得出各自的診斷結(jié)論。專家會(huì)診的最大優(yōu)勢(shì)就是它可以充分利用不同專家的經(jīng)驗(yàn)，通過相互交流給出結(jié)論，避免了交互式診斷中專家獨(dú)自承擔(dān)診斷任務(wù)帶來(lái)的片面性，最準(zhǔn)確的給出故障的形成原因以及解決方案。

2.5.3 基于SVG的富客戶端系統(tǒng)

在普通基于HTML的Web頁(yè)面上顯示實(shí)時(shí)的數(shù)據(jù)圖表一直是業(yè)界的一個(gè)難題，除了傳統(tǒng)的ActiveX技術(shù)和Java Applet技術(shù)外，目前成熟的解決方案并不是很多，其中主要的兩種解決方法是利用Flash插件和基于SVG的Web矢量圖形技術(shù)。本課題針對(duì)監(jiān)測(cè)系統(tǒng)的功能需求，設(shè)計(jì)和實(shí)現(xiàn)了一套簡(jiǎn)單的基于SVG技術(shù)的Web動(dòng)態(tài)圖表組件。

利用SVG技術(shù)的實(shí)現(xiàn)Web下的動(dòng)態(tài)圖表基本原理如下:首先利用 SVG來(lái)繪制基本的圖表形狀，然后通過使用Ajax數(shù)據(jù)層向Web服務(wù)器請(qǐng)求最新的實(shí)時(shí)數(shù)據(jù)，當(dāng)接收到實(shí)時(shí)數(shù)據(jù)則再通過JavaScript腳本調(diào)用DOM接口動(dòng)態(tài)修改SVG圖形，這樣就實(shí)現(xiàn)了Web下的動(dòng)態(tài)圖表。

3 系統(tǒng)實(shí)現(xiàn)與驗(yàn)證

為了驗(yàn)證基于SOA的遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)的可行性以及本文所闡述的設(shè)計(jì)思路和功能模塊，設(shè)計(jì)并實(shí)現(xiàn)了基于SOA的遠(yuǎn)程監(jiān)測(cè)與診斷演示系統(tǒng)。系統(tǒng)開發(fā)平臺(tái)參數(shù)如下:Windows XP專業(yè)版操作系統(tǒng)，E4300(1.8G)的 CPU，2 G 內(nèi)存，Web 服務(wù)器為 IIS，數(shù)據(jù)庫(kù)系統(tǒng)為SQL Server 2005，開發(fā)語(yǔ)言為ASP，服務(wù)器開發(fā)平臺(tái)為VC 2005。另外，在整個(gè)演示系統(tǒng)中模擬了10個(gè)監(jiān)測(cè)點(diǎn)的數(shù)據(jù)，采樣頻率為2 kHz，整個(gè)演示系統(tǒng)的核心部分是SOA運(yùn)行監(jiān)測(cè)中心，分別包括服務(wù)注冊(cè)中心、服務(wù)網(wǎng)關(guān)以及消息總線，詳見圖7部分。下面從SOA運(yùn)行監(jiān)測(cè)中心、遠(yuǎn)程監(jiān)測(cè)系統(tǒng)、診斷系統(tǒng)三個(gè)方面詳細(xì)介紹演示系統(tǒng)的運(yùn)行效果。

圖7 SOA運(yùn)行監(jiān)測(cè)中心的前臺(tái)界面Fig.7 The front interface of SOA monitoring center

(1)SOA的運(yùn)行監(jiān)測(cè)中心

SOA的各個(gè)功能模塊基本上都屬于系統(tǒng)“后臺(tái)”的進(jìn)程或服務(wù)，因此為了使SOA的管理者能夠方便地獲取這些功能模塊的運(yùn)行狀況，這里通過一個(gè)SOA的運(yùn)行監(jiān)測(cè)中心，實(shí)時(shí)顯示SOA的各個(gè)功能模塊的運(yùn)行狀態(tài)。如圖7所示，監(jiān)測(cè)中心主要用于顯示服務(wù)注冊(cè)中心、服務(wù)網(wǎng)關(guān)等SOA核心部件的運(yùn)行狀態(tài)，同時(shí)提供了對(duì)系統(tǒng)中各個(gè)功能服務(wù)進(jìn)行人工管理的方式。

(2)遠(yuǎn)程監(jiān)測(cè)系統(tǒng)示例

演示系統(tǒng)中主要提供了基于Web的遠(yuǎn)程監(jiān)測(cè)系統(tǒng)的客戶端，這里以振動(dòng)信號(hào)的實(shí)時(shí)波形監(jiān)測(cè)(圖8)、特征值棒圖監(jiān)測(cè)(圖9，去掉瀏覽器部分)為例展示了監(jiān)測(cè)系統(tǒng)運(yùn)行的效果。可以看出，一方面已經(jīng)成功地實(shí)現(xiàn)了完全基于Web方式的監(jiān)測(cè)界面和操作，另一方面由于和客戶端的數(shù)據(jù)和業(yè)務(wù)相分離，監(jiān)測(cè)界面的設(shè)計(jì)與實(shí)現(xiàn)十分簡(jiǎn)單易行，因此將來(lái)可以很方便地為實(shí)際的應(yīng)用系統(tǒng)設(shè)計(jì)更豐富和完善的監(jiān)測(cè)界面。

圖8 實(shí)時(shí)波形監(jiān)測(cè)Fig.8 Realtime wave monitoring

圖9 特征值棒圖監(jiān)測(cè)Fig.9 Feature bar monitoring

圖10 自助診斷前端Web界面Fig.10 The web interface of self-assist diagnosis

(3)診斷系統(tǒng)示例

本文中所述遠(yuǎn)程故障診斷系統(tǒng)主要提供自助診斷、交互診斷和專家診斷三個(gè)模塊的服務(wù)與功能。以自助診斷為例，其前端界面如圖10所示。這些前端界面主要提供了用戶與診斷服務(wù)的數(shù)據(jù)交換(用戶提交數(shù)據(jù)，服務(wù)結(jié)果顯示等)。

4 結(jié)論

針對(duì)目前設(shè)備遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)面臨著日趨復(fù)雜的應(yīng)用需求和環(huán)境，為了在不同的應(yīng)用平臺(tái)、不同的開發(fā)環(huán)境、不同的基礎(chǔ)硬件上構(gòu)建一個(gè)分布式部署、松耦合、易擴(kuò)展的應(yīng)用平臺(tái)，本文提出了基于SOA的遠(yuǎn)程監(jiān)測(cè)與故障系統(tǒng)體系結(jié)構(gòu)。該體系結(jié)構(gòu)利用SOA的設(shè)計(jì)思想，首先對(duì)遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)的業(yè)務(wù)邏輯和功能需求進(jìn)行了不同層次、不同粒度的抽象和劃分，建立了一個(gè)松散耦合的Web服務(wù)系統(tǒng)。然后給出了基于SOA的松耦合Web服務(wù)的構(gòu)建方式，使得功能模塊的可重用度更高，易于系統(tǒng)的擴(kuò)展，實(shí)現(xiàn)了對(duì)分散、異構(gòu)的監(jiān)測(cè)與診斷系統(tǒng)資源進(jìn)行有效的整合。最后，本論文開發(fā)并實(shí)現(xiàn)了一套基于SOA的遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)，驗(yàn)證了整個(gè)遠(yuǎn)程監(jiān)測(cè)與故障診斷系統(tǒng)體系結(jié)構(gòu)的可行性。

［1］韓 捷，張瑞琳.旋轉(zhuǎn)機(jī)械故障機(jī)理及診斷技術(shù)［M］.北京:機(jī)械工業(yè)出版社，1997.

［2］屈梁生，何正嘉.機(jī)械故障診斷學(xué)［M］.上海:上海科學(xué)技術(shù)出版社，1986.

［3］Newcomer E，Lomow G.Understanding SOA with Web Services［M］.Maryland:Addison-Wesley，2005.

［4］郭春燕.基于SOA的企業(yè)應(yīng)用的研究與實(shí)現(xiàn)［D］.大連:大連理工大學(xué)，2005.

［5］王海峰，徐金梧，楊德斌，等.基于CORBA的分布式遠(yuǎn)程故障診斷體系［J］.北京科技大學(xué)學(xué)報(bào)，2004，26(2):192－196.

［6］姚寶恒，楊霞菊，佟德純，等.基于互聯(lián)網(wǎng)的設(shè)備遠(yuǎn)程監(jiān)測(cè)診斷技術(shù)［J］.振動(dòng)與沖擊，2002，21(3):52 －57.

［7］蔣全勝，賈民平.基于Web的連鑄旋轉(zhuǎn)塔遠(yuǎn)程狀態(tài)監(jiān)測(cè)與診斷系統(tǒng)［J］.東南大學(xué)學(xué)報(bào)，2006，36(3):407 －410.

［8］吳立偉，陳 進(jìn)，孫衛(wèi)祥.遠(yuǎn)程設(shè)備監(jiān)測(cè)與診斷系統(tǒng)的DCOM組件設(shè)計(jì)與實(shí)現(xiàn)方法［J］.振動(dòng)與沖擊，2007，26(3):117－120.

［9］Woods D，Mattern T.Enterprise SOA:designing IT for business innovation［M］.Cambridge:O'Reilly，2006.

［10］陳一鳴，陳 進(jìn)，伍 星，等.基于網(wǎng)絡(luò)的遠(yuǎn)程監(jiān)測(cè)和故障診斷系統(tǒng)的數(shù)據(jù)庫(kù)系統(tǒng)［J］.振動(dòng)與沖擊，2005，24(6):61－64.

［11］多麗華，楊擁民，陶利民，等.基于層次分析法和與/或樹的遠(yuǎn)程診斷專家系統(tǒng)實(shí)現(xiàn)研究［J］.華中科技大學(xué)學(xué)報(bào)，2005，35(4):75 －78.

［12］王 東，劉懷亮，徐國(guó)華.案例推理在故障診斷系統(tǒng)中的應(yīng)用［J］.計(jì)算機(jī)工程，2003，29(12):10－12.