这段时间一直在做工业自动控制方面的项目,PLC使用的是
Siemens,当时上位机用的是Siemens的
WinCC,其使用的改的不伦不类的C,让我实在无法忍受,缺少事件驱动,简直不能称之为现代软件。在Siemens的
BBS上潜水多日以及跟北京的工程师浪费无数口水之后,终于找到了我认为是将来自控软件应用的方向,
OPC。
OPC分两大部分,一是OPC Server,一是OPC Client。OPC Server是基于DCOM的组件对象,负责连通PLC,类似一个Adapter,各个PLC厂家分别有针对自己PLC的OPC Server,也有第三方提供的。
OPC Client其实只是根据OPC协议而自己实现的应用程序。目前有很多第三方厂商提供For .Net或者Delphi的OPC Client的Components。应用开发者只需使用组件读取OPC Server提供的数据即可。
所以OPC类似ADO所起的作用,只是分成了Client和Server而已。应用程序通过ADO可以方便的Connect各种数据库,而不必考虑连接的具体实现。同样的,只要配好了OPC Server至PLC的连接,应用程序的撰写者便无需考虑该调用什么Lib去连PLC,只需通过标准的OPC Client去连OPC Server即可。
结果有一天因为要用到工控界面组件,所以下载了
ioComp,结果意外的发现ioComp也实现了OPC的Client,看来即使在略显保守的工业控制行业,新技术以及标准化的步伐仍然是抵挡不住的。
使用OPC的好处有如下几点:
1、因为通过OPC连接PLC,所以应用程序的开发可以使用任何开发工具,例如Delphi,C#,VB等,而无需局限在PLC厂商提供的蹩脚的开发工具,从而降低程序员的学习成本和公司的用人成本。
2、由于OPC是一个Adapter,所以如果PLC发生了变化,上位机与PLC的互连只需更换一个OPC Server即可。
毫不夸张的说,OPC代表了下位机与上位机互连的方向,有了OPC,我们可以按自己喜好选择上位开发工具,生产力的提高是显而易见的。
OPC解决了什么?
OPC诞生以前,硬件的驱动器和与其连接的应用程序之间的接口并没有统一的标准。例如,在FA(FactoryAutomation)——工厂自动化领域,连
接PLC(Programmable Logic Controller)等控制设备和SCADA/HMI软件,需要不同的FA网络系统构成。根据某调查结果,在控制系统软件开发
的所需费用中,各种各样机器的应用程序设计占费用的7成,而开发机器设备间的连接接口则占了3成。此外,在PA(Process Automation)——
过程自动化领域,当希望把分布式控制系统(DCS——Distributed Control System)中所有的过程数据传送到生产管理系统时,必须按照各个供
应厂商的各个机种开发特定的接口,例如,利用C语言DLL(动态链路数据库)连接的DDE(动态数据交换)服务器或者利用FTP(文件传送协定)的文
本等设计应用程序。如由4种控制设备和与其连接的监视、趋势图以及表报3种应用程序所构成的系统时,必须花费大量时间去开发分别对应设
备A,B,C,D的监视,趋势图以及表报应用程序的接口软件共计要用12种驱动器。同时由于系统中共存各种各样的驱动器,也使维护运转环境
的稳定性和信赖性更加困难。
而OPC是为了不同供应厂商的设备和应用程序之间的软件接口标准化,使其间的数据交换更加简单化的目的而提出的。作为结果,从而可以向用
户提供不依靠于特定开发语言和开发环境的可以自由组合使用的过程控制软件组件产品。