以太網現場總線的跨平臺網絡通信
加入技術交流群
3、以太網總線的跨平臺通信研究
3.1、網絡通信模式
網絡中存在多種類型的機器，這些不同類型的機器表示數據的字節順序是不同的，即主機字節順序不同。而網絡協議中的數據采用統一的網絡字節順序，因為只有采用統一的字節順序，才能在不同類型的機器和不同操作系統間進行正確地發送和接收數據。進行跨平臺進程間的通信時必須要將字節序轉變成網絡字節序進行傳遞，并且套接字的建立需要雙方可見的IP地址和端口號。上位機同以太網現場總線控制器的通信在傳輸層可以選用TCP或UDP協議，TCP提供的是面向連接的、可靠的數據流傳輸，而UDP提供的是非面向連接的、不可靠的數據流傳輸。由于EAST極向場電源控制系統具有收發數據多為短消息 ，對響應速度要求較高的特點，故采用UDP 面向數據報方式。圖三為UDP協議傳輸下的客戶端/服務器示意圖.
3.2、Windows平臺的軟件實現
Windows平臺軟件用Visual C++6.0編程，運行在Windows2000環境下。Visual C++6.0的最大的特色就是提供對面向對象技術的支持，它利用類把大部分與用戶界面設計有關的Windows API函數封裝起來，通過MFC (Microsoft Foundation Class)類庫的方式提供給開發人員使用，大大提高了程序代碼的重用性，其功能幾乎包括了Windows應用的各個方面。Visual C++6.0還支持多任務、多線程的編程技術。
CBlockingSocket 是在Visual C++的Winsock API基礎上的一個簡單包裝，為輔助線程中的同步編程而設計的，其優點就是能進行對錯誤的異常處理和發送、接收數據的超時處理。這一點對極向場電源的實時控制反應能力尤為重要，應此Windows平臺軟件網絡部分程序采用CBlockingSocket編寫。采用UDP客戶機模式與現場總線通信，同時利用輔助線程進行具體的接收和處理數據；部分UDP客戶機模式代碼如下：
CBlockingSocket sClient；
CSockAddr saServer;
saServer =CSockAddr(ip,port2);
try{
sClient.Create(SOCK_DGRAM);//建立套接字
sClient.Connect(saServer);//連接服務器
AfxBeginThread(Server1ThreadProc, GetSafeHwnd());//啟動接受線程
}
//異常處理
catch(CBlockingSocketException* e){
AfxMessageBox(" error!");
sClient.Cleanup();//關閉套接字
e->Delete();
}
3.3、QNX平臺的軟件實現
QNX6.20是一個多任務、分布式、嵌入式、可擴展規模的符合POSIX標準的微內核實時操作系統；其內核提供4種服務：進程調度、進程間通信、底層網絡通信和中斷處理；網絡服務程序在內核外執行，為程序員提供了一個單一化的編程接口，忽略所涉及到的網絡結構和數量；QNX6.20系統可以動態的停止和啟動網絡服務程序。
QNX平臺軟件采用ANSI C語言、利用QNX6.20特有的函數和庫函數來編寫，運行在QNX6.20環境下。采用BSD Socket API作為套接字應用程序接口（Socket API）進行TCP/IP通信，部分代碼如下：
sock = socket(AF_INET, SOCK_DGRAM, 0); //得到一個UDP套接字
server.sin_family = AF_INET;
server.sin_addr.s_addr=inet_addr( HOST_FIELD_CTL );
server.sin_port = htons( PORT_FIELD_CTL ); //填充套接字結構
ioctl( sock, FIONBIO, on )；//設置非阻塞的UDP傳送
填充MODBUS/TCP幀結構，并調用sendto（）函數發送控制量，recvfrom（）函數接收狀態量即可。
3.4 最佳通信周期的確定
在EAST極向場電源控制系統中，現場總線總是同時與QNX控制層和WINDOWS監控層進行數據通信,一方面采集現場模擬量和開關量信號并轉換成數字信號傳輸到QNX實時層作為計算機的反饋輸入信號，接受來自QNX實時控制層的數據包，根據其內容控制現場的諸多開關、變壓器、整流器等器件；另一方面還要將采集到的現場模擬量和開關量信號并轉換成數字信號傳輸到WINDOWS監控層，用來監控現場設備的狀態。在通信過程中要保證實時通信的穩定性，不能出現較大的丟包率。為保證上位機與現場總線可靠的通信，同時盡量確保其實時性，必須找出適當的通信周期。
實驗方法：首先讓上位機分別在QNX與WINDOWS下運行通信程序，交替發送0、1數據包
到同一數字量輸出模塊，用示波器測量模塊的輸出值，以監測數據包丟失的情況。同時不斷更改發送周期，找出無掉包率的最小通信時間，即為最佳通信周期,測出QNX與WINDOWS單獨對現場總線通信時各自的最佳通信周期. 接著將兩臺上位機通過交換機實現與單個現場總線模塊的連接，讓一臺上位機在WINDOWS下不斷發送1信號，另一上位機在QNX下發送0信號到同一數字量模塊，重復單機情況下的步驟,找到最佳通信周期.（上位機均采用Pentium 4 1.8GHz , QNX6.20操作系統，WINDOWS2K系統，以太網現場總線采用WAGO 750系列，SWITCH采用3COM 17206）。
實驗分析：通過實驗發現以太網總線雖然通信速度很高100Mb/s，但由于它采用ISO/OSI標準化模型的七層完整結構，其協議復雜度比起CAN和PROFIBUS等工業控制總線要復雜得多，故其發送方和接收方開銷很大。當一臺上位機對總線模塊操作時，通信周期為4ms及以上掉包率為0；周期為3ms時掉包率小于0.1％；周期為2ms時統計掉包率為28.9％；可見通信周期必須在3ms以上才能保證通信正常。當兩臺上位機同時與總線模塊通信時，要保證控制量和狀態量數據的可靠性，不出現掉包，必然要加大通信周期，當然通信周期也必須盡可能的小以兼顧實時性。由于WINDOWS層負責監控，對實時性要求不如QNX實時控制層高，因此我們將QNX下通信周期固定為4ms,通過不斷調整WINDOWS下的周期來
分析總線模塊的丟包情況確定最佳通信周期，WINDOWS下通信周期為10ms以上時丟包率為0，周期為8ms時丟包率為2.2％，周期為6ms時丟包率為19.7％。綜合考慮系統可靠性和實時性的因素，將QNX層的最佳通信周期定為4ms,WINDOWS層定為10ms.圖4為最佳通信周期下的示波器監測圖。
4 結論
利用BSD Socket采用API 建立的套接字，使得QNX平臺同Windows平臺能同時與現場總線在基于TCP/IP協議的網絡上進行通信，并確定了最佳通信周期，滿足系統提出的實時性和可靠性要求，為EAST裝置的建立打下堅實的基礎。
參考文獻:
[1] 陽憲惠. 現場總線技術及其應用. 北京，清華大學出版社. 1999.6
[2] Rob krten. QNX Operating System Architecture. QNX Software system Itd.2000.2
[3] W.Richard Stevens. 陸雪瑩等譯.TCP/IP 詳解卷2. 機械工業出版社. 2000.
[4] 實時操作系統QNX中文網. http://hichun.nease.net.
[5] Kruglinski D J 潘愛民,王國印. Visual C++技術內幕(第四版).北京：清華大學出版社
評論