统一的访问传统OPC COM特性将不同的功能分布于多个COM服务器,通过接口连接代表不同特性的功能。OPC COM服务器提供报警但不持续连续的提供触发报警的数据的访问。例如,提供存储历史数据的OPC COM服务器不允许当前数据被读和更新。这种特性造成了集成的问题,因为单一系统的信息不能通过一致的方式访问。OPC UA解决了包含多种可用信息的通用地址通过单一服务访问的集成问题。更好的认证互操作性OPC UA特性通过和已取得成功的OPC COM认证程序一样提供的服务器和客户端测试工具。这些测试工具似得供应商可以验证他们产品是否符合特性的要求,改善产品的质量。OPC UA和OPC COM特性通过认证以后,可以获得相应的认证标志,通过使用OPC认证的产品可以减少最终用户的系统集成成本。设计的可靠性OPC UA是为搞可用性和冗余架构而设计。完整的可配置的超时,错误检测,和恢复特性使得OPC UA产品可以无缝处理出现错误或失败的情况(例如网络通信的丢失)。标准的支持冗余功能的OPC UA模块使得从不同厂商的应用部署成为可能。跨域防火墙和通过互联网OPC UA由客户端启动通信通道,这意味着不需要像OPC COM一样需要配置客户端以允许服务器的访问。OPC UA能通过标准的HTTP或UA TCP端口或任何管理员愿意开放的其他端口来进行通信。OPC UA使用基于安全的额消息,这意味着可以通过第三方的代理进行通信。通过信息模型减少配置时间OPC UA架构提供基本的应用,供应商可以提供特定应用的信息模型,这将大大降低配置和维护这些模块的成本。OPC基金会正和MIMOSA,FDI, PLCopen(IEC61131)组织协作开发 OPC UA信息模型。标准安全模型在过去,安全问题时最后才考虑的,很多供应商没有测试他们产品的安全许可。这意味着对于最终用户很难配置安全性,或根本不可能。OPC UA架构通过标准的,UA应用必须实施的安全模型解决了这个问题。这增强了互操作性和降低了配置和维护成本。OPC UA同时有利于适合任何平台的任何OPC UA产品的安全设置管理的标准工具的开发。从嵌入式系统到企业级的单一的解决方案轻量级的OPC UA可以作为有效的二进制通信协议,例如OPC UA 已经移植到很多嵌入式系统包括VxWorks,Linux和专有的RTOSs (Real Time Operating Systems)。顶级的OPC UA应用支持企业级标准的XML页面服务协议。通过一个公用的架构可以降低系统集成的成本。保护已有的OPC COM投资OPC UA COM的互操作组件可以使得供应商快速实现现有的OPC COM客户端和服务器应用支持OPC UA。 这些组件通过增加需要的OPC UA高级特性客户化。这意味着用户可以持续利用他们的OPC COM技术的投资开发新的OPC UA应用。历史事件OPC UA通过支持历史事件扩展了OPC COM历史数据访问(HDA)的能力。最终用户仙子啊可以通过选择的OPC UA客户端获得事件信息。不丢失性能的同时实现平台独立
OPC UA架构设计为提供最佳性能的同时提供平台独立。这意味着开发者可以使用他们熟悉的语言和操作系统开发基于OPC UA的应用,而不只有一种通过http使用SOAP/XML的选择。对于Windows用户来说,平台独立性也十分具有价值,因为允许应用迁移到下一代的微软通信技术。这也意味着OPC UA产品的供应商在以前的通信技术过时或有类似不可配置的较长的超时时间等技术问题时可以有更多的选择。高性能的通信协议
OPC UA特性定义基于TCP的二进制通信协议通过最小的开销提供最快的性能。对于企业环境SOAP/XML是通信协议中通常使用的。 OPC UA提供在打包到SOAP/XML兼容的消息中之前通过UA二进制编码消息,提升通常XML消息10倍以上的性能。这种架构的优点是提供使用SOAP/XML的格式,但是在发送之前降低其复杂性和XML的大小。Windows通信基础 (WCF)OPC .Net SDK使用WCF提供对XML Web服务的支持。这种架构意味着在企业应用中所有基于OPC UA .Net SDK应用可以继承微软的 XML Web服务的湖操作性。
通过OPC UA SDKs降低开发成本
基于OPC COM特性的开发者都知道要求创建互操作性的应用中,接口只是很小的不部分代码。基于这个原因,OPC基金会提供的OPC UA .NET SDK可以为开发者提供更多的选择,只需要很少的几百行代码就可以实现兼容于OPC UA 的应用。开发者还可以选择提供给OPC 基金会成员的商业化的SDK。这些 SDK将大大降低开发成本,供应商也将更多的精力关注在位客户提供更有价值的产品。最终用户同样可以从SDK中获益,因为采用的是公用的架构,将少了不同应用之间的互操作性问题。
采用方法和程序的增强特性
已经现有的OPC COM特性关注于数据或时间,但很多应用要求能减少单一数据值或事件的复杂操作。通过OPC UA方法,服务器允许客户端通过一序列参数触发复杂功能。通过触发事件汇报进程函数可以用来控制后台流程。
面向对象的信息模型的灵活性
已有的OPC COM在过去的10年一直作为OPC的通信标准,但是技术的发展要求更多的互操作性:
-〉微软逐步淡化COM,而跨平台的Web服务和SOA逐步加强
-〉OPC的供应商希望一套担心的服务实现OPC数据模块(DA,A&E,HDA….)
->OPC供应商希望在非微软的平台,包括嵌入式设备实现OPC功能-〉一些合作组织需要一个可靠的,有效地方式实现高水平结构数据的转移2
你先得确认那个OPC服务器是OPC DA的还是OPC UA的才行,如果是早期的OPC DA服务器,肯定是不支持OPC UA的。如果那个服务器支持OPC UA,那么只要你的客户端写的规范点,应该可以连接上。
OPC(OLE for Process Control), 用于过程控制的OLE,是一个工业标准。
OPC全称是Object Linking and Embedding(OLE) for Process Control,它的出现为基于Windows的应用程序和现场过程控制应用建立了桥梁。在过去,为了存取现场设备的数据信息,每一个应用软件开发商都需要编写专用的接口函数。
由于现场设备的种类繁多,且产品的不断升级,往往给用户和软件开发商带来了巨大的工作负担。通常这样也不能满足工作的实际需要,系统集成商和开发商急切需要一种具有高效性、可靠性、开放性、可互操作性的即插即用的设备驱动程序。
在这种情况下,OPC标准应运而生。OPC标准以微软公司的OLE技术为基础,它的制定是通过提供一套标准的OLE/COM接口完成的,在OPC技术中使用的是OLE 2技术,OLE标准允许多台微机之间交换文档、图形等对象。
扩展资料:
OPC有以下3个特点:
1、计算机硬件厂商只需要编写一套驱动程序就可以满足不同用户的需要。硬件供应商只需提供一套符合OPC Server规范的程序组,无需考虑工程人员需求。
2、应用程序开发者只需编写一个接口程序便可以连接不同的设备。软件开发商无需重写大量的设备驱动程序。
3、工程人员在设备选型上有了更多的选择。对于最终用户而言,可以根据实际情况的不同,选择符合实际的设备。
参考资料来源:百度百科-opc(工业标准OLE for Process Control)
参考资料来源:百度百科-OPC技术
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)