陳希祥，申宇皓

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

0 引言

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

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

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

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

1 總體方案設(shè)計

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

1.1 確定開發(fā)平臺

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通過以上分析，對演示仿真系統(tǒng)進行規(guī)劃設(shè)計。該仿真系統(tǒng)由服務(wù)器端和客戶端組成，服務(wù)器實現(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對故障信息進行描述，并發(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ā)送與接收同步進行，交互的工作流情況如圖3所示。

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

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

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

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

2.1 服務(wù)器

服務(wù)器控制面板如圖5所示?！癋MEA”表顯示將要發(fā)送的故障信息，“Sending XML”文本框顯示FMEA表中數(shù)據(jù)信息的XML描述結(jié)果，“Port”端口控制用于輸入TCP通信的端口號，“Sending”指示器用于顯示發(fā)送狀態(tài)，“Start”啟動按鈕用于運行程序。服務(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è)計一個新的VI: Field-XML描述。Field-XML描述框圖由“創(chuàng)建VI”、“創(chuàng)建輸入控制及局部變量”、“創(chuàng)建函數(shù)和連線”、“創(chuàng)建輸出控制和連線”、“運行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ù)連接?！斑\行VI及獲取結(jié)果”為了使創(chuàng)建的VI運行并得到最終結(jié)果。

圖8 VI字段XML描述框圖vi

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

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

在FMEA信息的XML描述全部發(fā)送后，在第3個模塊中，通過發(fā)送“發(fā)送結(jié)束”字符串幫助客戶端識別發(fā)送端。在第四個模塊中，客戶端收到所有數(shù)據(jù)后，服務(wù)器等待從客戶機發(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)容是連接客戶端的本地計算機名稱。由于客戶機使用包含隊列的供應(yīng)商和客戶模式，因此“No. of Elements in Queue”一欄顯示隊列中的元素數(shù)；接收指示器“Receiving”顯示接收狀態(tài)；啟動按鈕“Start”用于運行程序。

圖9 客戶端面板

客戶端如圖10～11所示，包括供應(yīng)商和客戶兩個獨立的循環(huán)。供應(yīng)商循環(huán)負責接收網(wǎng)絡(luò)數(shù)據(jù)并將數(shù)據(jù)放入隊列，客戶循環(huán)則負責從隊列中提取數(shù)據(jù)及故障信息。當接收和處理數(shù)據(jù)的工作是按順序周期性進行時，由于數(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)運行之前，需要為后續(xù)隊列操作創(chuàng)建隊列引用，隊列名稱是XML數(shù)據(jù)，隊列中的元素類型為字符串。循環(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”中，并插入到隊列，以便客戶循環(huán)從隊列中提取故障信息。當數(shù)據(jù)接收完畢時，表明服務(wù)器已將所有數(shù)據(jù)發(fā)送完畢，客戶端將項服務(wù)器發(fā)送“Receiving Over”信號。同時，該字符串將被插入到隊列，使用者退出程序，關(guān)閉TCP連接。若服務(wù)器接收到“Receiving Over”信號時，服務(wù)器退出程序，而不必等待客戶端處理數(shù)據(jù)。

在客戶循環(huán)中，隊列中的元素被逐一提取。如果提取的數(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)周期很長，如果采用更復雜的方法來處理數(shù)據(jù)，循環(huán)周期將更長。當數(shù)據(jù)提取結(jié)束時，程序退出客戶循環(huán)，釋放隊列引用，并刪除臨時文件。

2.3 仿真結(jié)果

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

圖12 信息傳輸隊列中的元素數(shù)

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

3 結(jié)束語

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