故障信息標準化描述及網絡傳輸方法研究

陳希祥，申宇皓

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

0 引言

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

網絡化故障診斷系統的實現包括跨平臺、故障信息標準描述、網絡傳輸等關鍵基礎技術。跨平臺技術可提高診斷系統在不同操作系統中的部署能力及針對不同開發平臺的適應能力，提高檢測診斷系統的通用性；故障信息標準描述增強了不同開發平臺之間的信息共享能力；網絡傳輸是實現故障檢測信息與診斷決策信息遠程傳輸及交互的關鍵。

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

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

1 總體方案設計

本節從跨平臺、故障信息標準描述、網絡傳輸等方面探討如何選擇和優化相關技術，實現總體設計。

1.1 確定開發平臺

跨平臺是軟件開發中一個重要的概念，是指程序設計語言、應用軟件或硬件設備可在多個操作系統中工作。由此可見，跨平臺既不依賴于操作系統，也不依賴硬件環境，可提高軟件的重用性。

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

1.2 信息描述語言及其實現方法

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

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

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

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

1.3 常見故障信息及其動態描述方法

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

在設計程序時，要能夠對標準的FMEA信息進行處理，并使其具有可擴展性。通常FMEA表信息的字段名和內容不是固定的，本文采用動態的方式實現了LabVIEW中常用的表信息的XML描述，將VI腳本技術應用于創建VI、控件、函數、運行程序以及結果輸出。VI腳本依賴于本地LabVIEW VI服務器所提供的的服務，客戶端則是本地LabVIEW 程序。

1.4 網絡通信協議選擇

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

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

1.5 總體規劃設計

通過以上分析，對演示仿真系統進行規劃設計。該仿真系統由服務器端和客戶端組成，服務器實現故障信息FMEA的XML描述，并將描述結果傳送到網絡；而客戶端與服務器連接，用于接收服務器傳送的網絡數據，提取并顯示故障信息。

圖1 服務器工作流

圖2 客戶端工作流

圖3 服務器與客戶端的交互工作流

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

仿真系統技術框架如圖4所示。如前所述，整個系統采用LabVIEW開發，支持跨平臺。服務器通過XML-LABVIEW模式和VI腳本技術，利用XML實現典型故障信息FMEA的描述，客戶端根據供應商和客戶模式技術接收網絡數據，提取并顯示傳輸的故障信息，兩者之間通過TCP協議進行通信。

圖4 仿真系統技術框架

2 具體實現方法

本節對總體方案中的關鍵技術及其實現方法進行探討。

2.1 服務器

服務器控制面板如圖5所示。“FMEA”表顯示將要發送的故障信息，“Sending XML”文本框顯示FMEA表中數據信息的XML描述結果，“Port”端口控制用于輸入TCP通信的端口號，“Sending”指示器用于顯示發送狀態，“Start”啟動按鈕用于運行程序。服務器利用XML來描述FMEA的數據信息，并逐條將描述結果發送到網絡。

圖5 服務器面板

服務器框圖如圖6所示。框圖的外部是響應啟動按鈕“Start”動作的循環事件結構。圖的內部由5個模塊組成：1)創建TCP連接;2)XML描述和發送數據;3)發送“發送結束”字符串;4)等待“接收完成”字符串;5)關閉TCP連接。

圖6 服務器框圖

在第一個模塊中，程序創建一個偵聽器，等待來自客戶端端口上的TCP連接，等待時間為1分鐘。在第二個模塊中，FMEA表是數據源，由XML逐條記錄、逐個字段分別描述，在一條記錄被描述并發送到網絡之后，開始描述下一條記錄。

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

圖7 通過VI腳本創建VI

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

圖8 VI字段XML描述框圖vi

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

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

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

2.2 客戶端

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

圖9 客戶端面板

客戶端如圖10～11所示，包括供應商和客戶兩個獨立的循環。供應商循環負責接收網絡數據并將數據放入隊列，客戶循環則負責從隊列中提取數據及故障信息。當接收和處理數據的工作是按順序周期性進行時，由于數據處理時間很長，因此，在供應商和客戶模式下數據不完全接收的情況是一般不會發生的。

圖10 供應商循環

圖11 客戶循環

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

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

2.3 仿真結果

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

圖12 信息傳輸隊列中的元素數

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

3 結束語

為滿足網絡故障診斷中跨平臺、故障信息標準化描述、網絡傳輸的需要，基于LabVIEW給出了設備故障信息標準化描述及網絡傳輸總體設計方案和實現方式。通過采用多種技術，驗證了總體技術的可行性。本文研究成果有助于進一步實現機電一體化設備遠程跨平臺網絡化故障診斷系統和LabVIEW的相關開發工作，為開展復雜故障信息的描述與傳輸研究工作提供了思路。