（交通運輸部水運科學研究院，北京 100088）原向東，亓 偉
                             
    原向東（1983-）男，碩士，現就職于交通運輸部水運科學研究所電氣自動與通訊工程部，任研究實習員，主要從事港口碼頭自動控制系統的開發研究工作。

    摘要：OPC是一個通用的工業標準，為多種多樣的自動化控制設備之間進行通訊提供了公用的接口。基于串口的OPC通訊在一些特定情況實際應用中遇到了數據丟失的情況，為了解決基于串口的OPC通訊問題，提出了幾點建議，并在實際應用中檢驗，滿足控制系統要求。

    關鍵詞：OPC；串口；數據優化

    Abstract: The OPC is a general industrial standard，and provides a communal communication interface among kinds of automatic control devices. However,data loss may appear in some of its specific practical applications. In order to solve the serial port based communication problem， some ideas are presented and applied in the practical system， which can meet the basic requirements of the control system.

    Key words: OPC; Serial Port; Data Optimization

    OPC全稱是OLE for Process Control，是過程控制業的新興標準，它的出現為基于Windows平臺的應用程序和現場過程控制應用建立了橋梁。OPC以OLE/COM/DCOM機制作為應用程序級的通訊標準，采用客戶/服務器模式，把開發訪問接口的任務放在硬件生產廠家或第三方廠家，以OPC服務器的形式提供給用戶，解決了軟、硬件廠商的矛盾，完成了系統的集成，提高了系統的開放性和可互操作性。目前，OPC通訊廣泛應用于工業控制系統中。港口電氣控制系統也廣泛采用OPC通訊，使系統集成更加方便快捷。

    OPC通訊一般基于工業以太網等速率較快的網絡，在快速網絡中的通訊速度也比較快，實時性基本可以滿足要求[1]。但是在實際應用中，有可能會出現通訊網絡接口采用串口的情況，由于串口速率相對比較低，在一些特定情況下，由此會導致出現OPC通訊故障的現象，例如讀寫數據出錯。本文以實際港口工程中的一個通訊系統為例，淺析基于串口的OPC通訊問題，并提出幾點解決問題建議。

    1 OPC通訊協議簡介

    OPC通訊采用客戶服務器模型，建立了一套在硬件供應商和軟件開發商之間相互遵循的標準。只要遵循這套標準，數據交換對于硬件和軟件雙方來說都是透明的，硬件供應商無需考慮應用程序的多種需求和傳輸協議，軟件開發商也無需了解硬件的實質和操作過程。不管現場設備以何種方式存在，客戶端都以統一的方式去訪問，從而保證軟件客戶端的透明性，使得用戶完全從底層的開發中脫離出來[2]。下圖描述了使用OPC技術后，工業系統的開發過程。
                      
                               圖1  基于OPC客戶/服務器模型的工業控制系統結構圖
    2 基于串口的OPC通訊

    本文以某港口實際工程中的一個通訊系統為例，介紹在該工程中遇到的基于串口OPC通訊應用過程中遇到的問題和解決方案。

    該控制系統由上位監控系統和下位現場控制系統組成。下位機采用AB 1769-L35CR PLC控制器及其相應I/O模塊，與上位機聯系的通訊模塊是AB 1761-ENI-NET，該通訊模塊實現串口轉以太網功能。上位機監控系統采用Cimplicity組態軟件6.0版本和AB RSLinx通訊軟件。上位機監控系統主要由3臺計算機組成，通過以太網交換機連接到通訊模塊1761-ENI-NET，再經過串口連接到PLC控制器通訊端口。整個控制系統的通訊網絡結構如下圖所示。上位機與下位機控制器通過OPC通訊協議互相交換數據。
                        
                                      圖2  通訊網絡系統結構圖
      該控制系統的通訊功能實現需要以下幾個步驟。首先，在上位計算機上安裝的RSLinx軟件中，配置相應的OPC服務器，使其與下位機控制器相對應。其次，在Cimplicity中定義一個端口（Ports），協議選擇OPC Client（OPC客戶），定義一個設備（Devices），選擇之前定義的OPC通訊端口，設置地址為“rslinx opc server”，Cimplicity會自動找到與其通訊的控制器，具體操作如圖3所示。經過上述相應操作，上位機與下位機的OPC通訊系統已經建立起來。
                    
                                    圖3  定義端口和設備示意圖
    3 基于串口的OPC通訊問題的引出

    該控制系統有兩個通訊接口：以太網口和串口，通過轉換模塊1761-ENI-NET實現連接。該轉換模塊兩端通訊速率有較大差別，以太網口的速率在100Mbps，而串口的通訊速率最高為幾十kbps。由此可見，整個系統通訊的瓶頸在串口。

    在OP C通訊中，傳輸的數據包括變量的名稱、數值以及校驗位等。對于變量名來說，一般一個變量名至少要包括3-7個字符，用以顯示變量的含義并區別于其他變量。而在數據傳輸中，變量名的一個字符要占據一個字節的數據量。這樣，變量名稱的傳輸要占據3-5個字節的數據量，甚至超過了真正所用數值所占用的數據量。該系統中所傳輸數值類型為BOOL型和DINT型。一個BOOL型數值傳輸所占數據量為1個字節，一個DINT型數值傳輸所占數據量為4個字節。由此可見，當所傳輸的數據增加時，傳輸的數據量在成倍增大。

    為了驗證基于串口OPC通訊的穩定性，對該通訊系統進行試驗。當OPC通訊傳輸數據量很小時，上位機監控系統讀寫數據正常；當系統傳輸的數據量逐漸增大時，上位機監控系統會偶爾出現寫數據失敗的現象；當傳輸的數據量增大到一定值后，上位機監控系統寫數據一直失敗，讀取數據也很慢。在該試驗中，數據變量名統一為5個字符，所測得通訊數據量極限值為3810個字節，超過此通訊數據量，通訊就會出現故障，上位機往下位機寫數據值失敗。在rslinx里的通訊事件記錄里可以查看到相應故障。如圖4所示。
                 
                                 圖4  rslinx通訊事件記錄
    由于通訊故障是傳輸的數據量增加引起的，而整個網絡的通訊瓶頸在于串口。因此，對該控制系統的串口設置進行重新檢查，轉換模塊1761-ENI-NET的串口設置為與PLC控制器自適應，這樣，只需檢查PLC控制器的串口設置狀態即可。PLC控制器1769-L35CR的串口設置窗口如圖5所示，默認狀態下通訊波特率為19.2kbps，通訊方式為無握手方式。該串口的波特率最高可設為38.4 kbps，通訊方式還有半雙工和全雙工兩種方式可以選擇。

    針對本控制系統中通訊數據量大，且需要雙向傳輸的特點，該串口應設置為38.4kbps和全雙工方式。但是，將串口設置修改后，整個控制系統的通訊問題仍然存在。由于實際中工程的工期很緊，為了能盡快解決通訊問題，決定在軟件編制方面尋求解決的方法。
                    
                                   圖5  PLC控制器串口設置窗口
    4 基于串口OPC通訊問題的解決方案

    由以上分析可知，當通訊傳輸的數據量減少到一定值后，基于串口的OPC通訊狀態即可恢復正常。因此，解決基于串口的OPC通訊問題，方法是在保證通訊信息完整的前提下，盡量減少通訊數據量。結合兩方面的考慮，嘗試采用通訊數據優化的方法。

    （1）數組優化

    OPC數據傳輸時要進行數據打包。對于零散的數據要分別打包，這樣傳輸的時候會占用額外的網絡資源。如果把數據分門別類，按類組建數組，OPC數據傳輸時數組數據是按整體打包，這樣占用網絡資源少。因此首先要做好數據規劃，盡量將數據分類，組成數組，提高通訊效率。

    （2）BOOL型變量轉換

    BOOL型變量占用1個字節，所表示的數值為0或1，實際上采用用DINT型變量中的某一位也可以實現數據傳輸功能。32個BOOL型數據占用32個字節，其所表示的含義用1個DINT型數據就可以代替，而1個DINT數據只占用4個字節，占用資源大大減少。32個BOOL型數據占用32個變量名，轉換為1個DINT數據后只占用1個變量名，由變量名所占用的資源也將顯著減少。因此，可以將大量的BOOL數據先轉換成DINT數據，再進行傳輸，減少網絡資源占用。

    （3）避免使用不兼容的數據

在應用程序中采用的float 和int、 char和 varchar、 binary和barbinary相互之間是不兼容的，因此要保證上位機監控軟件所用變量類型要和下位機的變量類型相一致。

    （4）簡化通訊傳輸的變量名稱

    在保證不影響變量名稱含義及識別的基礎上，變量名稱盡量縮短、簡化，以減少通訊的數據量。比如，變量名control在保證不影響識別的基礎上，可以縮寫為ctr，這樣，變量名減少了四個字符，數據傳輸量就減少了4個字節，有效的減少了通訊的數據量。

    經過數據傳輸的優化調整，整個系統的OP C通訊正常，達到了控制應用要求。為了保證上位機監控避免出現遺漏操作的現象，在上位機Cimplicity程序中編寫腳本，如果有通訊故障發生時，彈出報警提示對話框，要求操作人員重新操作。腳本如下所示。

    Sub OnMouseUp(x As Long， y As Long， flags As Long)

    On Error GoTo errorhandle ‘通訊故障診斷

    PointSet "KEY_S_NUMB1"，&H00000000&

    PointSet "KEY_S_NUMB2"，&H00000000&

    r%=answerbox("確定要啟動電機？"，"確定"，"取消")

    If r%=1 Then

    PointSet "KEY_S_NUMB3"，&H00080000&

    PointSet "KEY_S_START"，1

    PointSet "KEY_S_START"，0

    End If

    Exit Sub

    errorhandle: ‘通訊故障處理

    msgbox "出錯!請重新操作!"，ebOKOnly Or ebExclamation，

    "提示框"

    Exit Sub

    End Sub

    5 結語

    經工程實際應用驗證，通過采用上述幾種方法，基于串口的OPC通訊問題得到了有效的解決，可以滿足控制系統要求。OPC通訊已經在工控行業中廣泛應用[3]，OPC通訊問題，尤其是OPC通訊數據優化問題需要引起工控人員的注意，做好更進一步的研究。

    參考文獻：

    [1] 李宏宇. OPC技術在工控組態軟件中的研究及應用[D]. 大連理工大學，2005.

    [2] 汪輝. OPC技術實現及應用[D]. 合肥工業大學，2003.

    [3] 盧宏，汪金良，曾青云. 基于OPC技術的WinCC實時數據采集[J]. 自動化博覽，2006，(8).

     摘自《自動化博覽》2010年第六期