支持。除了Modbsu和MQTT之外，OPC UA还广泛应用于大多数物联网场景，尤其是工业现场。OPC UA旨在简化企业级集成。为了实现PLC与OPC之间的通信，要么PLC自身支持，要么在上位机上编写程序，然后通过透明传输实现。据了解，目前三菱的大部分PLC不支持OPC UA，而且由于大部分中小企业广泛应用三菱PLC，因此编写主机程序花费时间和巨大成本并不是首选。即使编写了程序，也需要通过硬件进行数据传输，PLC不能直接与上位机连接。那么三菱PLC如何实现OPC UA呢？有最快的方法，可以通过OPC协议网关解决这个问题。
什么是opc通讯
首先声明，是zz的，我对原文的观点是：分布式系统的规范不是那么容易搞出来的。所以OPC-DA暂时是不可替代的，OPC-XMLDA是跨防火墙的新技术，但是实时性差一点。这篇文章的出处是另一篇批评opc的文章的评论。（原文的链接是http://blog.cechinamag.com/sup_zoux/9284/message.aspx#3648，被评论的文章标题是OPC——资本和崇洋豢养的病态协议）zz文章如下：
楼主似乎对OPC相当的熟悉，但似乎又不是很懂OPC。
首先OPC是一种协议，OPC协议里只是定义了接口，OPC的不好是由于他建立在了DCOM的基础之上，大多数的诟病来源于DCOM本身而不是OPC协议本身，至少这篇文章对OPC的不满也几乎都来源于DCOM。那么楼主更应该骂微软，或是OPC基金会妥协与微软，而不是OPC协议本身。楼主是希望把OPC协议制定成为像modbus之类的协议，还是提出要建立一套分布式框架替代DCOM呢。这两者完全不是一个层面上的东西。如果是前者，我劝楼主应该站在更高的层次上，而不是盲目的准备去做无用功，如果是后者本人倒是颇感兴趣，本人才疏学浅，分布式框架只知道DCOM 、Cobra 、JMI、.Net Remoting、SOAP。其中JMI和.Net Remoting目前还是依赖于平台，而Cobra则是看起来很美，SOAP像是以后的发展方向，目前OPC 3.0协议已经是基于SOAP的了，性能问题导致他还不能大规模推广。
第二，OPC协议存在也有不少年头了，站在现在的观点对一个陈旧的东西妄加批评似乎有点过分和小肚鸡肠。就像我们不能现在说DDE是一种多么简陋的IPC技术啊，毕竟他是一个时代的产物，在OPC产生的年代，windows上的主流技术难道不是DCOM吗，除非一开始就脱离微软。
第三，“资本和崇洋豢养”这个词显得楼主太过于愤青，如果说用OPC就是“资本和崇洋豢养”，那么我们绝大多数用电脑的人都是“资本和崇洋豢养”，因为我们用的windows、linux、unix、solaris都是洋人给我们的，假如有一天真的有一种真正好的替代OPC的协议产生我第一个支持，如果目前还没有出来，还是希望楼主遵循“多谈些问题，少谈些主义”的原则，真正的能够为中国的自动化协议做些贡献。
最后送给楼主一句话，“师夷长技以治夷”，治夷之前是师夷而不是鄙夷
原文如下：
OPC——资本和崇洋豢养的病态协议
虽然目前大部分的厂商均支持OPC协议，并将其视为开放的标准。我曾长期从事实时数据库研发，并对OPC协议有深入研究。到目前为止，除了悲哀，只有一席不得不说的话。OPC真的很先进么？对于过去还一直靠编写串口协议研发非标产品的一些同仁来说，似乎刚刚感受到其带来的优点，为了接项目而编写一些OPC接口等等，也许感觉其神秘而高不可攀。其实，OPC就是基于微软DCOM技术的一套接口定义而已，在其设计的时候并没有考虑诸多工控必须的硬件条件因素，仅仅是将微软DCOM技术原封不动地搬到了工控领域而已。这几年，每年都有一些同仁公司联系SUPCON SOFT，希望能够获得解决OPC接口的问题，作为OPC基金会的首批会员和国内OPC基金会的倡导者，SUPCON对OPC十分了解，拥有大量可以开发OPC接口的程序员。但这并不意味着SUPCON会承接这些接口问题的服务。作为一个企业，其专业性在于提供自己专业的产品和核心价值所在的服务，而非其它。但这也从另一个侧面看出国人对OPC接口的误解和盲从。OPC真的很美么？从其应用至今，OPC带来的痛大过其带来的利益。DCOM是一套依赖微软技术极深的服务，仅一个OPC,就限制了目前工控领域操作系统的多样性。这也没什么，如果处于爱国，中国还真没有可圈可点的操作系统。但OPC的问题是在太多了：
※安全性配置复杂：对于对操作系统并不专业的工控人员，OPC的安全性配置已经过于专业和复杂了。这导致了好多实例中，OPC都不是通过系统启动后自激活的，而是需要有交互式用户去登录，这给系统带来了极大的不安全性。即每次系统重启都可能需要人为干预。虽然经过合理的DCOM配置可以避免，但不幸的是大部分工控从业同仁对此并不掌握；
※远程激活困难：如果两台计算机不再一个带有强烈微软技术特色的“域”里的时候，远程激活OPC就是一个噩梦，在很多项目上，仅这个配置就另很多工程人员痛心疾首。知道大部分项目中不同域之间的激活是怎么做到的吗？呵呵，好多同仁选择了两台机器通过相同的用户名和密码登录来破坏安全性；另一些掌握一些编程技术的同仁则通过在一台计算机中保存另一台计算机的用户名和密码；这些安全因患之所以不能排除，原因就是该死的OPC协议，这个吸附在微软的DCOM技术上的毒瘤；
※开发复杂：虽然笔者对DCOM技术掌握得较为熟练，但至今还能回忆起年轻时学习DCOM编程的黑暗日子，DCOM是一种经过一段时间痛苦，然后顿悟，发现原来所有写DCOM教材的人都在故弄玄虚，人为增加复杂度。同时,DCOM的内存管理和调用技术，往往需要较多经验，使本来容易的通讯开发，变得焦灼不堪。所以才有目前很多业界同仁委托其它公司开发OPC接口的事情；
※跨平台困难：连跨微软的多个操作系统，都会有些小问题，能在Linux和UNIX上使用OPC的人，更是寥寥；我至今只是闻名，未尝亲见这类高人；
那么为什么这么一个诟病甚多的协议会成为今天普遍接的标准呢？原因有二，一是时机，二是资本。当工业以太网时代还出于鸿蒙初开，各大自动化厂商还在为未来的总线争论得喋喋不休得时候，微软，这个操作系统的厂商，利用一种基于自己操作系统的分布式技术，在DCOM仿佛能够解决一切分布式问题的丧失理智的时代，推出了一种民不见经传的OLE for Process Control，没有引起任何一个自动化厂商的足够重视，而正是因为这种低调的入场，加上各大自动化厂商惯常的保守和对工业以太网技术发展前景的短视，OPC成长了起来。谁会将一个操作系统的厂商作为竞争对手呢？所以，OPC的开始是比较顺畅的。另一个强有力的吹鼓手是微软，他并没有鼓吹OPC无所不能，但它过分地鼓吹了DCOM，最终这种资本运作带来了浮躁，大家索性都不再研究其他开放的工业以太网传输协议了，OPC就是万能灵丹。历史再不断重演，今天的我们，又要被IBM等厂商所谓的SOA和Web2.0技术蒙住双眼。
另一个原因，就是崇洋，曾几何时，洋东西好得不得了，我还记得当时曾经定义一个内部的基于TCP数据传输协议，就有保守派在我耳边喋喋不休：协议这东西都是国外大公司制定得，如何如何神奇，如何如何专业，总之，中国人连制定一个企业的TCP传输协议的能力都没有了。不过最终证明，不但能够制定，只要对工业数据传输得需求把握得好，中国人可以制定出一样优秀得开放数据传输协议。但问题似乎总是出现：你制定了，谁拥护啊？你制定了，好吧，虽然是开放式协议，为啥是你A公司制定，不是我B公司制定？国人的问题多得不得了。中国目前也出了十多家有一定规模的自动化厂商，有没有成立一个多个企业的标准委员会，讨论一下国有开放标准？没有！这就是现实。我们不还以被美国仪器仪表协会承认而自豪么？我们不还为了能够达到欧洲标准而欣慰么？所以，在这样的土壤上，本土的种子难得开花结果。
其实，最适合工业使用的以太网数据交互协议，绝对不是OPC，而应该是一种基于TCP/IP的，平台无关传输协议。这种协议得制定，只要兼顾了实时值、历史值、主动变化通知，考虑了批量数据读写和并发连接，考虑了不同设备处理速度得不同，就会变得即鲁棒又实用。而我们国人完全有能力制定自己的开放协议！
我深深的知道，问题虽然明显，但明天早晨，我仍然必须接受这个洋品牌和洋标准充斥的世界。OPC虽然不好，但未来5年恐怕还会被趋之若骛。我的力量虽有限，但有幸的是我在一家民族自动化企业就职，还可以一点点地身体力行以尽绵薄，希望国内业界同仁达成共识，有朝一日，可以共同推动由中国人制定的开放工业以太网实时数据传输标准，到那个时候，这个自动化的行业，才能因开放的标准而变得简单高效，四通八达。就脱离微软。
现在的工业以太网使用什么通讯协议，MODBUS和OPC-UA哪个好？
OPC全称是Object linking and Embedding（OLE） for Process Control，它的出现为基于Windows的应用程序和现场过程控制应用建立了桥梁。
在过去，为了存取现场设备的数据信息，每一个应用软件开发商都需要编写专用的接口函数。由于现场设备的种类繁多，且产品的不断升级，往往给用户和软件开发商带来了巨大的工作负担。
通常这样也不能满足工作的实际需要，系统集成商和开发商急切需要一种具有高效性、可靠性、开放性、可互操作性的即插即用的设备驱动程序。
在这种情况下，OPC标准应运而生。OPC标准以微软公司的OLE技术为基础，它的制定是通过提供一套标准的OLE/COM接口完成的，在OPC技术中使用的是OLE 2技术，OLE标准允许多台微机之间交换文档、图形等对象。
扩展资料
OPC是世界上最受欢迎的基于标准的数据通信方法。它旨在解决自动化行业中的最大的挑战：如何摆脱传统的基于特制驱动器的通信方式，在不同设备、控制器、和/或应用程序之间实现通讯。
OPC之所以能够成功地创造真正独立于供应商的通讯是因为，OPC从双方提取了数据发送设备（例如PLC）和数据接收端（例如HMI）的执行细节，因此可以在它们之间进行数据交换而不需要了解彼此的本地通信协议和内部数据组织形式。
这与特制驱动器的要求满足只针对于通信方两端的编写方法形成了鲜明的对比。OPC可以代表为一个位于数据发送端和数据接收端之间的“提取”界面，这个界面允许在数据发送端和数据接收端之间交换数据而不需要对对方有任何了解。
OPC的“设备细节提取”是通过运用两个称为OPC客户端和OPC服务器的OPC构件得以实现的。其中每一个构件将在以下章节予以描述。需要注意的是，数据发送端和数据接收端能够彼此通过OPC进行通讯并不意味着它们各自的本地协议就不需要了，或者是被OPC取代了。
相反，这些本地协议和/或接口仍然存在，但只是与两个OPC构件的其中某一个通讯。然后，OPC构件之间进行数据交换，从而结束数据传递。数据也可以从应用程序端被传输至设备，而不需要彼此直接联系。
参考资料来源：百度百科-opc
如何将modbus转换成OPC协议
OPC最初是作为一种标准协议开发的，可以与诸如可编程控制器（PLC），SCADA系统（监控和数据采集）以及许多其他工业控制系统和设备之类的设备进行通信。使用OPC，有一台服务器以其本机语言/协议与设备通信，然后以标准OPC格式公开该数据。然后，OPC客户端可以使用该数据。OPC DA最初设计为传输相当简单的数据类型，例如模拟量（温度，压力，流速等）和离散量（机器/设备状态，例如泵开/关，阀门打开/关闭，电动机运行/停止等）。传感器数据，而OPC UA允许传感器数据以及其他数据（如警报和事件）以及其他数据类型。OPC UA是OPC DA的后继产品。因此，Predix OPC UA组件是OPC UA服务器的客户端应用程序，OPC UA服务器将是与控制系统实际通信的软件。Modbus是另一种已多年成为行业标准的协议。它最初由Modicon开发，用于与Modicon PLC通信，但已被其他供应商采用作为与这些其他设备进行通信的协议。像OPC一样，Modbus只是提供了一种相对简单的机制来与支持Modbus协议的设备（例如PLC，远程终端设备或RTU等）进行通信，然后将该数据提供给需要该数据的应用程序。例如，GE iFIX软件是一个HMI应用程序，它允许您构建实时显示，以可视化来自OPC，Modbus和其他使用这些协议进行通讯的类似工业控制器系统的传感器数据。最重要的是，OPC UA和Modbus是用于与工业控制器/系统进行通信的协议。我们与这些系统进行通信，以便检索传感器数据（温度，压力，流速，振动数据，状态信息，例如泵是否运行等），然后将该数据转发到GE的Proficy Historian和/或进入云中的Predix时间序列数据库。
将modbus转换成OPC协议的两种方法如下：
第一：你可以用MatrikonOPC Genie 产品，不需要软件编程就可以实现。
第二种：软件编程。现在很多做OPC软件的厂家都有提供一种SDK，大家在这个平台上可以做自己想要的OPC服务器。
OPC(OLE for Process Control, 用于过程控制的OLE)是一个工业标准，管理这个标准国际组织是OPC基金会，OPC基金会现有会员已超过220家。遍布全球，包括世界上所有主要的自动化控制系统、仪器仪表及过程控制系统的公司。基于微软的OLE(现在的Active X)、COM （部件对象模型）和DCOM （分布式部件对象模型）技术。OPC包括一整套接口、属性和方法的标准集，用于过程控制和制造业自动化系统。
Modbus是由Modicon在1979年发明的，是全球第一个真正用于工业现场的总线协议。
ModBus网络是一个工业通信系统，由带智能终端的可编程序控制器和计算机通过公用线路或局部专用线路连接而成。其系统结构既包括硬件、亦包括软件。它可应用于各种数据采集和过程监控。
以上就是关于三菱plc5U支持opcua通信吗全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
