計算機監控接口技術(shù)研究
圖1 典型的計算機監控系統硬件結構
無(wú)論是串行通訊還是網(wǎng)絡(luò )通訊,都不能保證其數據傳輸平穩流暢,即數據有間斷性。應該根據具體的情況,將一定時(shí)間內的不連續的數據合并成一個(gè)完整的數據包,進(jìn)行校驗分析。將屬于一個(gè)數據包的不連續的數據分開(kāi),或將不屬于一個(gè)數據包的數據合并處理都是錯誤的,這是由于軟件處理不當所造成的嚴重的通訊故障。實(shí)際的數據流示例如圖2所示。受控機的軟件一般采用低級語(yǔ)言編寫(xiě),這可以通過(guò)設置循環(huán)次數來(lái)收集數據,如果在設置的最大的時(shí)間片內沒(méi)有新的數據到達,則當前數據為一個(gè)數據包,作為整體進(jìn)行處理。在主控機端則可以簡(jiǎn)單地通過(guò)定時(shí)器來(lái)實(shí)現。對于串行通訊,等待的時(shí)間片由字節數來(lái)計算,并考慮波特率和具體的串口類(lèi)型。
圖2 實(shí)際數據流
由于計算機一般配備網(wǎng)口(RJ45)和串口(RS232),所以,用軟件來(lái)實(shí)現網(wǎng)口和串口之間的數據轉換,是一個(gè)安全、可靠和方便的手段,避免了硬件串行網(wǎng)關(guān)的設備故障的可能性??梢酝ㄟ^(guò)Visual Basic語(yǔ)言,采用串行通訊控件MsComm32.OCX和網(wǎng)絡(luò )通訊控件WinSock.OCX[3][4]來(lái)實(shí)現,兩個(gè)控件的收發(fā)數據的變量類(lèi)型都應設置為變體Variant,因為在數據包中存在“00”字節是常有的事,如果設置為字符串String,“00”字節后面的數據將被截去。MsComm控件是通過(guò)Input和Output屬性來(lái)收發(fā)數據的,應將接收閾值設為1,即一有數據,立即響應,當發(fā)生數據到達事件comEvReceive時(shí),通過(guò)Input屬性直接讀取數據,然后通過(guò)Winsock的SendData立即轉發(fā)(見(jiàn)圖3-1所示)。對于WinSock控件,當發(fā)生DataArrival事件時(shí),用GetData函數讀取,然后通過(guò)MsComm控件的Output屬性立即轉發(fā)(見(jiàn)圖3-2所示)。
5 遠程測試模型及分析
對計算機監控系統進(jìn)行測試的最理想的地理位置,一般是現場(chǎng),因為只有在現場(chǎng),才能觀(guān)察各種復雜的因素。有的監控模塊可以通過(guò)撤換法進(jìn)行查錯,然而,大型設備,如大型柴油發(fā)電機組,難以搬遷,也無(wú)法替換。如何采用一種簡(jiǎn)潔高效的方式,對現場(chǎng)監控系統和設備進(jìn)行檢測?文獻[5]介紹了一個(gè)“智能設備的通用測試”軟件,通過(guò)串口進(jìn)行測試,只能在近距離或現場(chǎng)進(jìn)行。借助上文的串口和網(wǎng)口的轉換軟件,可以實(shí)現遠距離現場(chǎng)測試。遠程測試模型如圖4所示,服務(wù)器和客戶(hù)機都是普通的PC機,均運行RS232/RJ45轉換軟件。
圖4 遠程測試模型
對于測試結果,如果屬于軟故障,即非設備故障,工程師可以通過(guò)電子協(xié)作指示用戶(hù)對系統加以調整或維護;如果是硬故障,即設備故障,工程師可以根據具體情況,有準備地去現場(chǎng)解決問(wèn)題,節省人力物力。
6 結束語(yǔ)
計算機監控系統廣泛應用于眾多領(lǐng)域,接口的可靠性則關(guān)系到系統的生命。本文充分研究了各種常用接口的硬件性能和相關(guān)的軟件特性,以及接口之間的硬件轉換和軟件轉換,最后設計了一個(gè)遠程測試模型,并在局域網(wǎng)上通過(guò)了測試,取得了良好的效果。通過(guò)因特網(wǎng)進(jìn)行遠程測試,可以節省大量的人力物力,不失為一種高效的測試手段。
參考文獻
[1] 大漠電子?http://www.demo.com.cn/,2003
[2] 馬玉春,趙躍華?高山無(wú)人站監控系統設計與開(kāi)發(fā)?電腦開(kāi)發(fā)與應用[J]?13(9):35, 2000
[3] 汪曉平,鐘軍等?Visual Basic網(wǎng)絡(luò )高級編程[M],北京:人民郵電出版社,2001
[4] MSDN Library Archive?http://msdn.microsoft.com/archive/,2003
[5] 王建明,馬玉春?智能設備的通用測試?工業(yè)控制計算機[J]?15(12):10, 2002(end)
評論