（交通运输部水运科学研究院，北京 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年第六期