数据和信息是DCS监督控制的基础，不仅来源于DCS现场控制层，还可来源于第三方设备和软件。一个好的DCS监控应用软件应能提供广泛的应用接口或标准接口，可方便地实现将DCS控制器、第三方PLC、智能仪表和其他工控设备的数据接入到系统中。一般监控系统都把数据源看做外部设备，驱动程序与这些外部设备交换数据，包括采集数据和发送数据/指令。
在com/tags/OPC" title="OPC" target="_blank">OPC出现以前，应用程序开发商（DCS厂商）需要不断地开发这些设备的驱动程序，不但带来了大量重复性劳动，也带来了很多问题。如硬件供应商在硬件上作出一些小小的改动，应用程序就可能需要重写；同时由于不同设备甚至同一设备的不同单元驱动程序可能不同，很难同时对这些设备进行优化操作。传统的过程控制系统是一对一的系统，任何一种DCS、SCADA、MES等上位监控软件或其他应用软件在使用某种硬件设备时都需要开发专用的驱动程序，系统构建完成后的最终结果是：
(1) 一种软件要使用N类硬件设备需要开发N个驱动程序。(2) M类软件要使用N类硬件设备需要开发M×N个驱动程序。(3) 每增加一个新的应用软件需要另外开发N个硬件设备的驱动程序。(4) 每增加一个新的硬件设备需要为M个软件开发新的设备驱动程序。
图1是传统工业控制驱动程序的开发示意图。

为了解决传统工业控制开发中的问题，硬件制造商一直试图开发出一种可以被任何客户应用程序使用的超级“设备驱动”程序。但是由于设备通信协议的不一致性，这项工作一直较为困难。
在此背景下,本文提出了一种基于OPC的DCS第三方设备数据采集系统(COMMOPC)的设计与实现方法。本方法在高度抽象各种通信方式和通信协议的基础上，实现了DCS与各种第三方设备的通信功能。
1 OPC技术简介
OPC[1](OLE for Process Control)是用于过程控制的OLE(Object Linking and Embedding)技术,它是世界上多个自动化公司、软硬件供应商与微软合作开发的一套工业标准，是专为在现场设备、自控应用、企业管理应用软件之间实现系统无缝集成而设计的接口规范。这个标准使得COM技术适用于过程控制和制造自动化等应用领域。OPC以OLE、组件对象模型COM(Component Object Model)及分布式组件对象模型DCOM(Distributed COM)技术为基础，定义了一套适于过程控制应用，支持过程数据访问、报警、事件与历史数据访问等功能的接口，便于不同供应商的软硬件实现“即插即用”的连接与系统集成[2]。
OPC规范采用客户/服务器模型，建立了一套在硬件供应商和软件开发商之间相互遵循的规则。只要遵循这套规则，数据交换对两者来说都是透明的，硬件供应商无需考虑应用程序的多种需求和传输协议，软件开发商也无需了解硬件的实质和操作过程。图2为使用OPC技术后工业程序的开发过程。

基于OPC技术的系统构建完成后的最终结果是：
　 (1) M类软件要使用N类硬件设备只需要开发N个驱动。
　 (2) 每增加一个新的应用软件不需要另外开发硬件设备的驱动程序。
　 (3) 每增加一个新的硬件设备只需要为开发一个新设备的驱动程序。
由此可见，任何一种设备只需要提供一种驱动就可以供任何软件系统使用。
2 COMMOPC系统简介
基于OPC技术及多年驱动程序的开发背景，和利时公司开发了拥有自主专利的基于OPC的DCS第三方设备数据采集系统——COMMOPC。该系统是DCS、MES和RealMis等应用系统与现场设备之间的通用数据接口，实现对现场设备实时数据的访问，可广泛应用于企业自动化应用系统与现场设备之间的信息集成；可以把现场设备数据转化成标准OPC数据，供OPC Client访问，实现对现场数据的集中管理，并以OPC接口的方式供上层应用软件访问。只要具有OPC Client功能的应用软件即可实现对现场设备数据的访问，通用性好。
COMMOPC系统结构如图3所示，各个部分功能相对独立又相互协作，形成一个统一的整体。

COMMOPC系统IO驱动部分共有36种不同通信协议的第三方设备的设备驱动(由设备驱动开发包生成)，由OPC Server与外部设备及应用系统交换数据，包括采集数据和发送数据/指令，实质上是实现各种通信协议向OPC标准协议的转换功能。这样，DCS就不需理会具体的设备和应用类型，而只通过OPC Client与OPC Server的数据交换就能实现与外部设备和应用系统的数据交换。
3 COMMOPC的主要功能
COMMOPC系统主要提供三个功能：
(1)界面功能。包括:特殊操作控制，控制密码可修改；点名、路径两种标签浏览方式，默认为点名方式；界面配置；对组配置信息的导入导出；保存配置信息；OPC客户端调试工具；串口监视工具；监视通信过程信息；监视实时通信数据；显示树型列表；手动控制单个通道通信启停；托盘显示当前运行状态；提供测试版(测试版最多运行10小时)；运行版，测试版通过授权后自动转为运行版；版本显示；配置备份及恢复；安装时自动注册OPC服务器功能。
(2)通信功能。包括:支持OPC DA 1.0、DA 2.0规范，满足应用同步、异步、订阅任一种访问方式OPC客户端实现数据通信；支持OPC客户端重连接；提供各通道、各设备状态信息，这些信息点作为有效点供OPC客户端访问；提供通道冗余；提供通信诊断；36种驱动，驱动满足：采集设备的开关量、模拟量功能；对设备遥控、设定值功能；可进行特殊配置；支持串口通信方式，可挂接串口设备；支持以太网TCP通信方式，可挂接以太网TCP设备；支持以太网UDP通信方式，可挂接以太网UDP设备；提供OPCServer、通道、设备的状态供OPC客户端访问。
(3)日志功能。包括:日志信息种类可配置功能；日志自动生成、维护功能。
4 COMMOPC的系统设计方法
4.1模块组成及逻辑
COMMOPC系统由OPC接口模块、数据管理模块、数据显示模块、通信管理和调度模块、规约处理模块、通信测试和诊断模块、日志模块等组成。其系统逻辑图如图4所示。

4.2 OPC地址空间的设计
　OPC服务器中包含了很多可供客户访问的资源，这些资源在OPC中被称为项(Item)。为了方便客户访问，这些项应该按照一种合理的方式进行组织。服务器中的每个项都有一个全局有效标识名FID(Full qualified ID)。有了FID，客户就可以找到该项，因此称该全局有效标识名为该项的服务器地址(简称地址)。这种具有服务器地址的项按照一定的方式组织在一起，就形成了服务器的地址空间。服务器地址空间就是服务器上包含的可以供客户访问的资源的集合。服务器地址空间是由服务器确定和管理的，其描述了服务器中包含了哪些项，以及这些项是按照什么形式进行组织的。
本文地址空间设计为4层目录结构，如图5所示。

根对象(CRoot::m_Root)是4层目录结构的根，维护通道列表(ChannelList),所有的通道都可以通过m_Root找到；通道对象(CChannel::m_branches)是本系统地址空间的第1层，维护设备列表(DeviceList)，每个通道都可以有n个设备；设备对象(CDevice::m_branches)是第2层，维护组列表(GroupList)，组可以将标签分为不同的类型；组对象(CGroup::m_tags)是第3层，维护标签列表(TagList)；标签(CExTag)是最后一层地址空间，标签对应具体设备的点。
在OPC接口内含有地址空间的根，用户通过配置通道、设备、组及选择组内的点之后即可完成地址空间的建立。当地址空间建立后，OPC Client可以通过OPC接口访问地址空间内任意标签点的值。标签的地址格式为：ChName.DevName.GrpName.TagName。
4.3 设备驱动开发包的设计
设备驱动开发包采用动态链接库形式，不同通信协议的设备驱动程序都在开发包框架内编写。这样可以提高设备驱动的开发效率，同时方便维护升级，设备驱动的修改不会影响软件主体部分。
利用设备驱动开发包可以开发各种通信协议的设备驱动模块。规约处理是设备驱动模块的核心任务，不同的通信协议对应着不同的设备驱动模块。根据需求，设备驱动模块以DLL的形式生成，模块修改或者添加功能后，只需要覆盖原模块，不需要重新编译主程序。设备驱动模块的主要功能是从主程序得到所要请求的标签的信息，然后打包发送给设备，从设备读取应答、解析数据，将相应的数据发送到数据管理和显示模块。如果OPC客户端有控制命令，会发送给OPC服务器，OPC接口模块将消息发送给设备驱动模块，由设备驱动模块进行打包，将命令报文发送给设备。
设备驱动开发包生成的DLL形式的设备驱动模块，如图3驱动部分所示。

本文在充分研究各种通信协议的基础上,设计了COMMOPC系统，对第三方设备的数据采集进行了统一及标准管理，该方法有很好的灵活性和扩展性。通过实际应用证明，该方法设计的数据采集系统，不仅完全满足了第三方设备数据采集的需求，还具有良好的稳定性、灵活性和可维护性。
参考文献
[1] The OPC of data access custom interface standard version 2.05, Dec 17,2001.OPC基金会，www.opcfoundation.org.2001.
[2] 潘爱民. COM原理与应用[M]. 北京:清华大学出版社，1999:50-63.