OPC（OLE for Process Control）技术是指为了给工业控制系统应用程序之间的通信建立一个接口标准，在工业控制设备与控制软件之间建立统一的数据存取规范。它给工业控制领域提供了一种标准数据访问机制，将硬件与应用软件有效地分离开来，是一套与厂商无关的软件数据交换标准接口和规程，主要解决过程控制系统与其数据源的数据交换问题，可以在各个应用之间提供透明的数据访问。

近段时间，遇到不少人都被OPCClient与OPCServer之间的通讯搞得头大，通过几次远程协助后，总结了OPCClient和OPCServer在Windows上运行方式的恩怨，希望对各位有用。 
目前市场上的OPCClient和OPCServer软件在Windows上的运行方式有Windows 桌面程序和Windows NT服务。本来也没啥。但由于OPCCLient是一个厂家的软件，而OPCServer是另外一个厂家的软件，由于软件的多样性，也就导致了如下一些现象：
1. OPCCLient连接目标OPCServer，发现无法连接，但在OPCServer计算机上明明看见OPCServer进程已经启动。
2. OPCCLient连接目标OPCServer，能连接，也能看见测点，但无法获取到数据。
经过多次现场的积累后，发现此类问题多出现在OPCClient和OPCServer软件在Windows上的运行方式不同导致的。也就是说，OPCClient和OPCServer软件的运行方式不一样。譬如，OPCCLient是Windows NT服务方式，而OPCServer是桌面程序方式（多是组态软件的OPCServer都是桌面程序方式吧！！）。而当OPCCLient是Windows 桌面程序方式，OPCServer时Windows NT服务时，发现上面的现象基本不出现。这是为什么呢？
原因如下：
OPCClient和OPCServer都是基于DCOM的应用，DCOM的特点是OPCServer无需先运行或启动，等待OPCCLient请求时，由操作系统在将OPCServer拽起来。这种机制的好处就是随用随启。但这种机制如果处理不好吧，就会导致一些问题。当OPCCLient是Windows NT服务时，OPCServer被拽起来后，是运行在System这个系统账户下面的。相对于Windows的桌面用户来说，是另外一个隔离开的空间。因此当桌面运行类型的OPCServer被Windows NT服务方式的OPCCLient拽起来后，被运行在System这个系统账户的空间。而如果这个OPCServer程序又做了全局唯一进程运行的限制或与数据库只允许一个TCP连接时，上述的两种现象基本就会出现。这就是这段时间好几个朋友遇到的OPC通讯故障现象。
如果让自己开发的OPC程序兼容性更好呢？
1. 当开发OPCCLient程序时，最好使用Windows桌面程序方式，这种方式可兼容OPCServer程序运行在Windows桌面程序方式和Windows NT服务方式。
2. 当开发OPCServer程序时，最好使用Windows NT服务方式，这种方式可兼容OPCClient程序运行在Windows桌面程序方式和Windows NT服务方式。
如果很不幸遇到了Windows NT服务的OPCClient去采集Windows 桌面程序的OPCServer（加上OPCServer本身的全局唯一限制），那么你可以去Windows NT服务的管理器中将Windows NT服务的OPCClient更改为指定的系统用户运行，大多数情况下可以解决问题