陳希祥，申宇皓

(湖南信息學(xué)院 電子信息學(xué)院,長沙 410007)

0 引言

隨著科學(xué)技術(shù)發(fā)展，現(xiàn)代工業(yè)系統(tǒng)的模塊化、網(wǎng)絡(luò)化、數(shù)字化、智能化水平有了很大提升，設(shè)備結(jié)構(gòu)也越來越復(fù)雜，系統(tǒng)內(nèi)部存在著復(fù)雜關(guān)系。系統(tǒng)功能單元故障原因復(fù)雜，故障表現(xiàn)出多樣性、漸變性、耦合性等特點(diǎn)[1-3]。傳統(tǒng)的現(xiàn)場檢測與診斷模式已不能滿足快速性、實(shí)時性等實(shí)際需要，開發(fā)網(wǎng)絡(luò)化、信息化故障診斷系統(tǒng)是工業(yè)系統(tǒng)故障診斷的發(fā)展趨勢[4]。網(wǎng)絡(luò)化故障診斷系統(tǒng)通過傳輸和處理現(xiàn)場故障信息，將現(xiàn)場人員與遠(yuǎn)程專家相結(jié)合，利用不同的領(lǐng)域知識處理系統(tǒng)，提高故障診斷的準(zhǔn)確性和效率。

網(wǎng)絡(luò)化故障診斷系統(tǒng)的實(shí)現(xiàn)包括跨平臺、故障信息標(biāo)準(zhǔn)描述、網(wǎng)絡(luò)傳輸?shù)汝P(guān)鍵基礎(chǔ)技術(shù)。跨平臺技術(shù)可提高診斷系統(tǒng)在不同操作系統(tǒng)中的部署能力及針對不同開發(fā)平臺的適應(yīng)能力，提高檢測診斷系統(tǒng)的通用性；故障信息標(biāo)準(zhǔn)描述增強(qiáng)了不同開發(fā)平臺之間的信息共享能力；網(wǎng)絡(luò)傳輸是實(shí)現(xiàn)故障檢測信息與診斷決策信息遠(yuǎn)程傳輸及交互的關(guān)鍵。

在不同研究領(lǐng)域，對診斷方法都進(jìn)行了大量的研究和討論[5-7]，然而所開發(fā)的系統(tǒng)在跨領(lǐng)域、跨平臺和故障信息標(biāo)準(zhǔn)描述方面顯得不足，通用性較差，難以實(shí)現(xiàn)遠(yuǎn)程信息分析與故障診斷。通過對比分析，LabVIEW(laboratory virtual instrument engineering workbench)可支持跨平臺系統(tǒng)的快速開發(fā)[8-10]，而XML(Extensive Markup Language)也支持跨平臺信息描述，獨(dú)立于硬件和軟件。將LabVIEW和XML應(yīng)用于網(wǎng)絡(luò)化故障診斷系統(tǒng)的開發(fā)，可以使系統(tǒng)具有很強(qiáng)的靈活性和通用性[8-12]。因此，本文選擇XML實(shí)現(xiàn)故障信息的標(biāo)準(zhǔn)描述，以LabVIEW作為開發(fā)平臺實(shí)現(xiàn)系統(tǒng)構(gòu)建及信息網(wǎng)絡(luò)傳輸，從而實(shí)現(xiàn)跨平臺網(wǎng)絡(luò)化遠(yuǎn)程故障診斷系統(tǒng)。文獻(xiàn)[11]中給出了在LabVIEW中創(chuàng)建和訪問XML文件的基本方法。但是，它對不同類型的信息缺乏靈活性。文獻(xiàn)[12]中討論了在LabVIEW中實(shí)現(xiàn)遠(yuǎn)程數(shù)據(jù)傳輸?shù)幕痉椒?。然而，它不能避免?shù)據(jù)的丟失。

本文首先給出了系統(tǒng)總體規(guī)劃，詳細(xì)介紹了設(shè)計(jì)過程，然后給出了服務(wù)器端和客戶端程序的詳細(xì)設(shè)計(jì)，用XML描述典型故障模式影響分析信息(FMEA，failure mode effect analysis)。利用VI腳本技術(shù)實(shí)現(xiàn)程序的動態(tài)創(chuàng)建和運(yùn)行，采用TCP協(xié)議實(shí)現(xiàn)數(shù)據(jù)傳輸，采用供應(yīng)商和客戶模式增強(qiáng)了安全性，避免了數(shù)據(jù)丟失。最后構(gòu)建了一個演示仿真系統(tǒng)，討論仿真試驗(yàn)結(jié)果，對本文進(jìn)行總結(jié)。

1 總體方案設(shè)計(jì)

本節(jié)從跨平臺、故障信息標(biāo)準(zhǔn)描述、網(wǎng)絡(luò)傳輸?shù)确矫嫣接懭绾芜x擇和優(yōu)化相關(guān)技術(shù)，實(shí)現(xiàn)總體設(shè)計(jì)。

1.1 確定開發(fā)平臺

跨平臺是軟件開發(fā)中一個重要的概念，是指程序設(shè)計(jì)語言、應(yīng)用軟件或硬件設(shè)備可在多個操作系統(tǒng)中工作。由此可見，跨平臺既不依賴于操作系統(tǒng)，也不依賴硬件環(huán)境，可提高軟件的重用性。

JAVA是SUN公司推出的Java面向?qū)ο蟪绦蛟O(shè)計(jì)語言和Java平臺的總稱，它利用虛擬機(jī)技術(shù)實(shí)現(xiàn)跨平臺，但開發(fā)效率不高。LabVIEW是由美國國家儀器(NI)公司推出的重要軟件產(chǎn)品，它是一種圖形化編程語言，完全支持跨平臺，其代碼無需更改即可運(yùn)行于3種常見的操作系統(tǒng)：Windows、Mac OS和Linux。同時，LabVIEW也是一種程序開發(fā)環(huán)境，可實(shí)現(xiàn)系統(tǒng)快速的開發(fā)。根據(jù)大量統(tǒng)計(jì)數(shù)據(jù)發(fā)現(xiàn)，開發(fā)同一個大型應(yīng)用程序，LabVIEW程序員只需花費(fèi)C程序員1/5的時間。因此，本文選擇LabVIEW作為開發(fā)平臺實(shí)現(xiàn)網(wǎng)絡(luò)化故障診斷演示仿真系統(tǒng)。

1.2 信息描述語言及其實(shí)現(xiàn)方法

XML是一種基于文本、使電子文件或信息具有結(jié)構(gòu)性的標(biāo)記語言，它將可理解的標(biāo)記和結(jié)構(gòu)化格式應(yīng)用于保存數(shù)據(jù)。XML是支持跨平臺、依賴于內(nèi)容的技術(shù)，提供統(tǒng)一的方法來描述和交換獨(dú)立于應(yīng)用程序或供應(yīng)商的結(jié)構(gòu)化數(shù)據(jù)，已經(jīng)成為數(shù)據(jù)交換標(biāo)準(zhǔn)，非常適合網(wǎng)絡(luò)傳輸，是當(dāng)今處理分布式結(jié)構(gòu)化文檔信息的有力工具。

相比于HTML有一個固定的標(biāo)記集，XML只提供一個標(biāo)準(zhǔn)，用戶可按照這個標(biāo)準(zhǔn)來定義自己專用的標(biāo)記，所以XML的標(biāo)記是可以無限擴(kuò)展的，可用于描述各種應(yīng)用領(lǐng)域的數(shù)據(jù)信息，人們可以理解并且計(jì)算機(jī)可以處理它。因此，選擇XML來描述故障信息。

在LabVIEW中實(shí)現(xiàn)信息的XML描述有兩種方法：一種是LabVIEW模式，另一種是XML解析器。LabVIEW模式根據(jù)預(yù)定義的XML模式轉(zhuǎn)換數(shù)據(jù)。簡單的幾個函數(shù)可以完成基本的XML操作。XML解析器是Xerces 2.7，它依賴于DOM(文檔對象模型)，提供了許多靈活處理XML數(shù)據(jù)的功能，但它不支持除英語以外的其他語言。因此，選擇xerces 2.7模式來實(shí)現(xiàn)故障信息的XML描述，同時，采用了一些技術(shù)措施來提高Xerces 2.7模式的靈活性。Xerces 2.7模式中FlattedToXML函數(shù)給出字符串的XML轉(zhuǎn)換結(jié)果如下：

其中 標(biāo)記表示輸入數(shù)據(jù)類型為字符串“String”。標(biāo)記表示輸入的名稱(如功能function)。標(biāo)簽表示功能內(nèi)容(如燃料儲存)。

1.3 常見故障信息及其動態(tài)描述方法

故障信息的類型和形式是多種多樣的。FMEA是診斷中故障信息的重要來源，對典型故障信息FMEA進(jìn)行描述和傳輸，實(shí)現(xiàn)總體規(guī)劃設(shè)計(jì)的演示驗(yàn)證。通常FMEA信息用FMEA表來表示，明確了系統(tǒng)或設(shè)備故障的詳細(xì)信息，包括名稱、功能、故障模式、故障原因、故障影響(局部、進(jìn)一步、最終影響)、故障檢測方法等。

在設(shè)計(jì)程序時，要能夠?qū)?biāo)準(zhǔn)的FMEA信息進(jìn)行處理，并使其具有可擴(kuò)展性。通常FMEA表信息的字段名和內(nèi)容不是固定的，本文采用動態(tài)的方式實(shí)現(xiàn)了LabVIEW中常用的表信息的XML描述，將VI腳本技術(shù)應(yīng)用于創(chuàng)建VI、控件、函數(shù)、運(yùn)行程序以及結(jié)果輸出。VI腳本依賴于本地LabVIEW VI服務(wù)器所提供的的服務(wù)，客戶端則是本地LabVIEW 程序。

1.4 網(wǎng)絡(luò)通信協(xié)議選擇

TCP和UDP是兩種重要的網(wǎng)絡(luò)通信協(xié)議。TCP定義了兩臺計(jì)算機(jī)之間可靠的數(shù)據(jù)傳輸格式和方法，其重要特性是提供面向連接的可靠字節(jié)流服務(wù)。UDP是一種簡單的面向數(shù)據(jù)包的協(xié)議雖然UDP的傳輸速度較高，但其提供的傳輸服務(wù)并非面向連接且是不可靠的。因此，選擇TCP作為演示仿真系統(tǒng)的通信協(xié)議實(shí)現(xiàn)故障信息的傳輸需要高可靠性，由服務(wù)器描述并發(fā)送信息，客戶機(jī)接收和處理信息。

如果客戶機(jī)以順序循環(huán)的方式接收和處理信息，數(shù)據(jù)將不能被及時接收，且由于處理數(shù)據(jù)花費(fèi)了大量時間，會發(fā)生數(shù)據(jù)丟失。該模式采用隊(duì)列的數(shù)據(jù)存儲方式，按先進(jìn)先出(FIFO)方式工作，新元素總是加載隊(duì)列的末端，而最先取出的數(shù)據(jù)則是最先進(jìn)入隊(duì)列、位于隊(duì)列首段的數(shù)據(jù)。因此以該方式進(jìn)行數(shù)據(jù)的存取可避免數(shù)據(jù)遺失。供應(yīng)商和客戶模式利用多個環(huán)路并行實(shí)現(xiàn)供應(yīng)商和客戶的不同功能，可提高數(shù)據(jù)傳輸?shù)陌踩浴?/p>

1.5 總體規(guī)劃設(shè)計(jì)

通過以上分析，對演示仿真系統(tǒng)進(jìn)行規(guī)劃設(shè)計(jì)。該仿真系統(tǒng)由服務(wù)器端和客戶端組成，服務(wù)器實(shí)現(xiàn)故障信息FMEA的XML描述，并將描述結(jié)果傳送到網(wǎng)絡(luò)；而客戶端與服務(wù)器連接，用于接收服務(wù)器傳送的網(wǎng)絡(luò)數(shù)據(jù)，提取并顯示故障信息。

圖1 服務(wù)器工作流

圖2 客戶端工作流

圖3 服務(wù)器與客戶端的交互工作流

服務(wù)器端和客戶端的工作流程分別如圖1、圖2所示。在服務(wù)器中，首先創(chuàng)建一個網(wǎng)絡(luò)連接，利用XML對故障信息進(jìn)行描述，并發(fā)送到網(wǎng)絡(luò)中，直到信息全部發(fā)送完畢。然后服務(wù)器等待，直到客戶端接收到最后一組數(shù)據(jù)信息為止，并關(guān)閉網(wǎng)絡(luò)連接。在客戶端，首先打開網(wǎng)絡(luò)連接，接收網(wǎng)絡(luò)數(shù)據(jù)、提取并顯示故障信息。服務(wù)器和客戶端按一定時序同時工作，確保數(shù)據(jù)信息的發(fā)送與接收同步進(jìn)行，交互的工作流情況如圖3所示。

仿真系統(tǒng)技術(shù)框架如圖4所示。如前所述，整個系統(tǒng)采用LabVIEW開發(fā)，支持跨平臺。服務(wù)器通過XML-LABVIEW模式和VI腳本技術(shù)，利用XML實(shí)現(xiàn)典型故障信息FMEA的描述，客戶端根據(jù)供應(yīng)商和客戶模式技術(shù)接收網(wǎng)絡(luò)數(shù)據(jù)，提取并顯示傳輸?shù)墓收闲畔?，兩者之間通過TCP協(xié)議進(jìn)行通信。

圖4 仿真系統(tǒng)技術(shù)框架

2 具體實(shí)現(xiàn)方法

本節(jié)對總體方案中的關(guān)鍵技術(shù)及其實(shí)現(xiàn)方法進(jìn)行探討。

2.1 服務(wù)器

服務(wù)器控制面板如圖5所示?！癋MEA”表顯示將要發(fā)送的故障信息，“Sending XML”文本框顯示FMEA表中數(shù)據(jù)信息的XML描述結(jié)果，“Port”端口控制用于輸入TCP通信的端口號，“Sending”指示器用于顯示發(fā)送狀態(tài)，“Start”啟動按鈕用于運(yùn)行程序。服務(wù)器利用XML來描述FMEA的數(shù)據(jù)信息，并逐條將描述結(jié)果發(fā)送到網(wǎng)絡(luò)。

圖5 服務(wù)器面板

服務(wù)器框圖如圖6所示。框圖的外部是響應(yīng)啟動按鈕“Start”動作的循環(huán)事件結(jié)構(gòu)。圖的內(nèi)部由5個模塊組成：1)創(chuàng)建TCP連接;2)XML描述和發(fā)送數(shù)據(jù);3)發(fā)送“發(fā)送結(jié)束”字符串;4)等待“接收完成”字符串;5)關(guān)閉TCP連接。

圖6 服務(wù)器框圖

在第一個模塊中，程序創(chuàng)建一個偵聽器，等待來自客戶端端口上的TCP連接，等待時間為1分鐘。在第二個模塊中，F(xiàn)MEA表是數(shù)據(jù)源，由XML逐條記錄、逐個字段分別描述，在一條記錄被描述并發(fā)送到網(wǎng)絡(luò)之后，開始描述下一條記錄。

為滿足不同故障信息描述的需要，在LabVIEW中采用VI腳本技術(shù)描述FMEA記錄中的某一字段。此時，需要創(chuàng)建一個新的VI，如圖7所示，以便每個字段的描述結(jié)果與第1.2節(jié)LabVIEW模式中的示例格式保持一致。面板由兩個文本框組成，一個用于輸入字段名和字段內(nèi)容，另一個顯示該字段的描述結(jié)果。相應(yīng)的框圖由輸入文本框的局部變量和Flatted to XML函數(shù)組成。

圖7 通過VI腳本創(chuàng)建VI

為創(chuàng)建上述VI，采用VI腳本技術(shù)設(shè)計(jì)一個新的VI: Field-XML描述。Field-XML描述框圖由“創(chuàng)建VI”、“創(chuàng)建輸入控制及局部變量”、“創(chuàng)建函數(shù)和連線”、“創(chuàng)建輸出控制和連線”、“運(yùn)行VI及獲取結(jié)果”等5個模塊組成，如圖8所示?！皠?chuàng)建VI”即創(chuàng)建一個新的面板和一個新的框圖。“創(chuàng)建輸入控制及局部變量”是為了創(chuàng)建一個文本框，包含面板中的字段名和字段內(nèi)容，以及框圖中的局部變量。“創(chuàng)建函數(shù)和連線”用于創(chuàng)建Flatted to XML函數(shù)，并將該函數(shù)與輸入文本框的局部變量連接?！皠?chuàng)建輸出控制和連線”用于在面板中創(chuàng)建輸出文本框，并將輸出文本框與Flatted to XML函數(shù)連接?！斑\(yùn)行VI及獲取結(jié)果”為了使創(chuàng)建的VI運(yùn)行并得到最終結(jié)果。

圖8 VI字段XML描述框圖vi

通過VI腳本設(shè)計(jì)VI是很復(fù)雜的。在2 GHz Intel i5 CPU、2 G內(nèi)存、Windows XP、LabVIEW 2012環(huán)境下運(yùn)行VI將花費(fèi)更多的時間(約80 ms)。而VI腳本實(shí)現(xiàn)了VI設(shè)計(jì)的自動化，提高了軟件的靈活性，可滿足不同需求。Field-XML描述VI使用了許多關(guān)于VI腳本的屬性和方法。鑒于篇幅有限，本文對這些性質(zhì)和方法未進(jìn)行詳細(xì)討論。

服務(wù)器框圖中的模塊2～4包括發(fā)送網(wǎng)絡(luò)數(shù)據(jù)和讀取網(wǎng)絡(luò)數(shù)據(jù)。為方便起見，創(chuàng)建兩個VI分別實(shí)現(xiàn)上述兩個功能，一個是TCP W(Write)，另一個是TCP R(Read)。在這兩個VI中，讀寫的字符串長度需要輸入。

在FMEA信息的XML描述全部發(fā)送后，在第3個模塊中，通過發(fā)送“發(fā)送結(jié)束”字符串幫助客戶端識別發(fā)送端。在第四個模塊中，客戶端收到所有數(shù)據(jù)后，服務(wù)器等待從客戶機(jī)發(fā)來的“接收結(jié)束”字符串。最后，關(guān)閉TCP連接。

2.2 客戶端

客戶端從網(wǎng)絡(luò)逐條接收XML記錄，提取并顯示該記錄所包含的故障信息，客戶端面板如圖9所示?！癛eceiving XML”文本框用于顯示接收到的XML描述記錄；“XML File”文本框用于顯示保存記錄的XML文件；“FMEA”表用于顯示從XML描述中提取的故障信息；“Port”端口控制用于輸入TCP通信的端口號；“Address”地址控制用于確定網(wǎng)絡(luò)連接地址，其內(nèi)容是連接客戶端的本地計(jì)算機(jī)名稱。由于客戶機(jī)使用包含隊(duì)列的供應(yīng)商和客戶模式，因此“No. of Elements in Queue”一欄顯示隊(duì)列中的元素?cái)?shù)；接收指示器“Receiving”顯示接收狀態(tài)；啟動按鈕“Start”用于運(yùn)行程序。

圖9 客戶端面板

客戶端如圖10～11所示，包括供應(yīng)商和客戶兩個獨(dú)立的循環(huán)。供應(yīng)商循環(huán)負(fù)責(zé)接收網(wǎng)絡(luò)數(shù)據(jù)并將數(shù)據(jù)放入隊(duì)列，客戶循環(huán)則負(fù)責(zé)從隊(duì)列中提取數(shù)據(jù)及故障信息。當(dāng)接收和處理數(shù)據(jù)的工作是按順序周期性進(jìn)行時，由于數(shù)據(jù)處理時間很長，因此，在供應(yīng)商和客戶模式下數(shù)據(jù)不完全接收的情況是一般不會發(fā)生的。

圖10 供應(yīng)商循環(huán)

圖11 客戶循環(huán)

供應(yīng)商循環(huán)的外部是響應(yīng)開始按鈕“Start”動作的循環(huán)事件結(jié)構(gòu)。該結(jié)構(gòu)運(yùn)行之前，需要為后續(xù)隊(duì)列操作創(chuàng)建隊(duì)列引用，隊(duì)列名稱是XML數(shù)據(jù)，隊(duì)列中的元素類型為字符串。循環(huán)事件結(jié)構(gòu)框圖包括3個模塊：1)打開TCP連接；2)接收XML；3)關(guān)閉TCP連接。要打開TCP連接，需要端口號和地址，隨后，開始接收來自網(wǎng)絡(luò)的數(shù)據(jù)。如果接收的數(shù)據(jù)沒有發(fā)送完，則數(shù)據(jù)將顯示在接收XML文本框“Receiving XML”中，并插入到隊(duì)列，以便客戶循環(huán)從隊(duì)列中提取故障信息。當(dāng)數(shù)據(jù)接收完畢時，表明服務(wù)器已將所有數(shù)據(jù)發(fā)送完畢，客戶端將項(xiàng)服務(wù)器發(fā)送“Receiving Over”信號。同時，該字符串將被插入到隊(duì)列，使用者退出程序，關(guān)閉TCP連接。若服務(wù)器接收到“Receiving Over”信號時，服務(wù)器退出程序，而不必等待客戶端處理數(shù)據(jù)。

在客戶循環(huán)中，隊(duì)列中的元素被逐一提取。如果提取的數(shù)據(jù)未接收完畢，則持續(xù)提取故障信息。首先，XML數(shù)據(jù)被保存為一個“*.xml”文件，以供客戶讀取。所讀取的數(shù)據(jù)為數(shù)組，元素格式與第2.2節(jié)中示例相同，這樣通過數(shù)組操作即可提取故障信息。然而，從“Receiving XML”文本框所示的原始數(shù)據(jù)中提取信息并不容易，因此可創(chuàng)建一個臨時文件“temp.xml”來保存數(shù)據(jù)。由于需要保存和讀取文件，客戶的一個循環(huán)周期很長，如果采用更復(fù)雜的方法來處理數(shù)據(jù)，循環(huán)周期將更長。當(dāng)數(shù)據(jù)提取結(jié)束時，程序退出客戶循環(huán)，釋放隊(duì)列引用，并刪除臨時文件。

2.3 仿真結(jié)果

假設(shè)在服務(wù)器中需要傳輸20條故障信息記錄。服務(wù)器和客戶端程序在本地計(jì)算機(jī)上運(yùn)行，端口號為2055。首先運(yùn)行服務(wù)器，客戶端隨后運(yùn)行，工作正常，其工作流如圖5和圖9所示。當(dāng)程序運(yùn)行一次時，客戶端隊(duì)列中的元素?cái)?shù)量如圖12所示。開始時數(shù)據(jù)量是0，接收到的數(shù)據(jù)可被及時處理。隨后，數(shù)據(jù)量逐漸增加。在18 s后達(dá)到最大值7，此時服務(wù)器上的所有數(shù)據(jù)都已完全發(fā)送，然后對隊(duì)列的元素逐個進(jìn)行處理，數(shù)據(jù)量逐漸減少。在2 GHz Intel i5 CPU、2 G內(nèi)存、Windows XP、LabVIEW 2012環(huán)境下，整個程序大約運(yùn)行花費(fèi)約32.5 s。

圖12 信息傳輸隊(duì)列中的元素?cái)?shù)

由仿真過程可以看出，采用XML進(jìn)行故障信息標(biāo)準(zhǔn)化描述，為實(shí)現(xiàn)故障信息跨平臺遠(yuǎn)距離傳輸與共享奠定了基礎(chǔ)；采用客戶端-服務(wù)器的網(wǎng)絡(luò)架構(gòu)可有效實(shí)現(xiàn)信息傳輸，有助于設(shè)備故障的遠(yuǎn)程監(jiān)控與診斷，增強(qiáng)故障診斷的實(shí)時性與靈活性。仿真結(jié)果與預(yù)期一致，進(jìn)一步驗(yàn)證了總體方案與技術(shù)的可行性。

3 結(jié)束語

為滿足網(wǎng)絡(luò)故障診斷中跨平臺、故障信息標(biāo)準(zhǔn)化描述、網(wǎng)絡(luò)傳輸?shù)男枰?，基于LabVIEW給出了設(shè)備故障信息標(biāo)準(zhǔn)化描述及網(wǎng)絡(luò)傳輸總體設(shè)計(jì)方案和實(shí)現(xiàn)方式。通過采用多種技術(shù)，驗(yàn)證了總體技術(shù)的可行性。本文研究成果有助于進(jìn)一步實(shí)現(xiàn)機(jī)電一體化設(shè)備遠(yuǎn)程跨平臺網(wǎng)絡(luò)化故障診斷系統(tǒng)和LabVIEW的相關(guān)開發(fā)工作，為開展復(fù)雜故障信息的描述與傳輸研究工作提供了思路。