怎样去开发OPC Data Access 2.0服务器

　　这里主要讨论的是OPC Data Access 2.0服务器的开发，在掌握了这个最常用的OPC服务器开发之后，对其它类型的OPC服务器，如A&E、HDA等就可以触类旁通了。
　　一个OPC服务器的开发，主要包括两大部分的工作：OPC接口的实现和设备驱动部分的开发。
　　OPC接口的实现，实质上就是按照OPC标准进行COM接口开发，对于大多数的OPC服务器开发者来说，我认为没有必要涉足。目前市场上有很多OPC服务器开发工具，国内外都有，当然价格也不尽相同，调研一下的话应该会找到适合自己的。有必要进行OPC接口开发的大致有这几种情况：1、有实力的大公司，OPC相关产品较多，需要对OPC技术进行深入了解；2、OPC服务器开发工具厂商；3、对OPC技术感兴趣的个人、院校及研究机构。除此之外，一般没有必要一头扎进COM的泥沼，去和内存分配、线程管理等繁琐的事务打交道。
　　所以，当决定为设备/程序开发OPC服务器时，首先要选择一款OPC服务器开发工具。（目前流行的OPC DA 2.0服务器开发工具的结构大同小异，kevin所在的公司也有这类产品，为避免广告之嫌，这里就不做详细介绍了。）
　　为了更好地理解OPC服务器开发工具的结构并合理使用，最好先了解OPC服务器的结构模型，这里简单说一下。OPC（DA 2.0）里主要定义了两个对象：OPCServer 和 OPCGroup。OPCServer对象是OPC服务器的核心，它提供的接口函数主要包括对OPCGroup对象的管理、OPCItem属性查询、连接点管理、以及地址空间浏览（可选）等。OPCGroup 对象的主要作用是管理一组数据项（Item），包括数据项的同步/异步访问、添加删除、属性查询等。从客户程序角度看，访问一个OPC服务器的过程大致是首先创建一个 OPCServer 对象，然后通过它创建一个 OPCGroup，在其中添加想要访问的数据项，之后利用订阅回调机制周期性获取动态数据或通过读写接口直接访问数据项。
　　在OPC服务器的实现中，组对象的管理是关键，不同客户程序可能创建多个组对象，每个组对象包含的数据项、更新周期都由客户程序决定，不尽相同，需分别处理。所幸的是大部分OPC服务器开发工具都已实现了这一部分，并进行了封装。用户开发OPC服务器时可把主要精力放在现场数据的读写上。目前大部分的OPC服务器开发工具都提供了一些类对象或API形式的函数，用户只需调用这些函数即可完成从现场数据到OPC服务器（通常是内部缓冲区）的数据更新。
　　在开始开发一个OPC服务器之前，用户还要确定服务器的运行形式。OPC服务器做为一个COM组件，运行方式主要包括进程内（DLL）、进程外（EXE）以及服务（Service）。这里的进程内/外是相对于客户程序说的，当OPC服务器是进程内组件时，它运行在客户程序的进程里（远程连接时是宿主程序（host）的进程），而我们通常接触到的OPC服务器一般都是进程外组件。选择哪一种形式要看具体的应用需求，进程内形式适合轻量级的小型服务器，特别是当底层设备具有较高的性能，支持并发多连接访问，OPC客户及服务器程序处于同一计算机上时，可采用进程内形式。其它情况下进程外形式可能更适合一些。简言之，当你不清楚到底那种更合适时，就选择进程外方式。服务形式主要是和进程外形式比较的，它在后台运行，没有用户界面。当OPC服务器计算机可能在没有用户登录，或者需要经常切换登录用户时，服务形式的OPC服务器是最合适的。无论那种形式，都与设备驱动开发的关系不大，大部分的OPC服务器开发工具都带有每种形式的服务器例程，用户可在开发时参考。
　　开发一个OPC服务器时，首先通常要确定地址空间结构。OPC DA 2.0规定了两种地址空间的组织形式：Flat（平坦的） 和 Hierarchical（分等级的）。可以理解为我们通常所说的“列表型”和“树状型”。虽说OPC DA 2.0里把IOPCBrowseServerAddressSpace接口定义为Optional，即可选的，但目前大部分OPC服务器开发工具都实现了这个接口，树状地址空间有利于客户程序浏览查询，特别是当数据项总数较多时，Flat 形式不利于数据项的分类、管理。所以建议定义树状地址空间。具体的空间结构因底层设备的特性而异，OPC没有严格要求。借用OPC标准里的例子，比如：
　　《ROOT》
　　PLC_STATION_1 （branch）
　　ANALOG_VALUES （branch）
　　40001 （leaf）
　　40002 （leaf）
　　。..
　　DISCRETE_VALUES （branch）
　　。..
　　设计好地址空间结构之后，就要实现最主要的数据读写功能了（以后继续）。
　　BTW，有朋友曾在论坛里提到“通用”OPC服务器，我想可能是指Kepware之类的OPC服务器套件，支持当前很多主流的设备。但这也是包含了多家厂商设备驱动的结果。或者其它的针对某些通用、公开的协议，比如Modbus，开发的服务器，但显然它不能适应所有的设备。可以说，只要有私有协议的存在，就没有真正意义上的通用OPC服务器。OPC标准的根本目的是提供设备驱动程序（软件）与客户软件之间的互操作性。