技术论坛

 0219 【万泉河】论OPC UA协议对工控行业的重要性

返回主题列表
作者 主题
万泉河
至圣

经验值:28644
发帖数:10887
精华帖:131
楼主    2022-02-19 18:37:26
主题:0219 【万泉河】论OPC UA协议对工控行业的重要性 精华帖 

0219 【万泉河】论OPC UA协议对工控行业的重要性

 

OPC UA协议已经推出来大约10多年了。 然而具体的年数不清楚,因为对于使用者来说, 推出协议没啥用,重要的是需要有支持这个协议的产品。而且需要市面上支持的产品足够多,产品之间互相通讯的时候可以选择这个协议,然后才会重视它使用它。

 

所以,尽管OPC UA已经诞生10多年,但在产业界,支持的产品力度还不够的情况下,工控同行不重视它,甚至即便有使用过,但仍然不重视,也是正常的。

 

然而,我在这里要跟大家推荐的是, 对工控行业来说OPC UA会越来越重要,同行们需要逐渐认识到它的重要性, 甚至有能力有前瞻性的工程师,从现在开始就要逐渐铺垫积累,提前布局掌握它了。而更有能力的产品开发者,软件开发者,则更可以从中发现商机,提前布局了。

 

关于OPC是什么,以及之前的OPC DA的概念,同行们应该很熟悉了。 新入门的新手不懂的话可以自己从网上找相关文章看一看。

 

而关于OPC UA, 网上其实也早就有了很多概念性的介绍, 其中许多还是以通俗、简介等目的介绍的。大家也不妨关键字搜索后逐篇过一下。了解个大概。

 

我这里绝不照抄所有网上已有文章内容,只发表自己的观点。请读者独立思考,客观判断, 有选择地接受,谬误之处,则请毫不留情的批评,拒绝。

 

UA是Unified Architecture 的简写,中文字面含义是统一架构。

 

然而,如果从字面理解统一架构,仅仅把他当作已有所有OPC概念的升级版或者大一统,就彻底的错了,就看不到其重要性了。

 

UA统一架构的不是OPC自己,而是对操作系统平台的统一。即,它是支持所有操作系统平台之间的直接通讯。

 

操作系统就是除了微软的WINDOWS系统, 其它所有的平台都可以支持。 包括了各种我们现在耳熟能详的LINUX,  ANDRIOD ,  IOS,CODESYS, 以及微软自己的WINCE等等。以及未来可能出现并流行的所有的操作系统。

 

为什么讲它可以通用于所有操作系统平台?因为协议本身只定义了通讯协议的内容。那么各厂家,各操作系统,只要能满足协议规定的规范的内容,则都可以实现。 所以具体的开发工作OPC基金会并不负责。 所以他当然可以宣称对所有平台都支持,从而成为跨平台的协议。因为他所定义的协议不依赖于操作系统。

 

而与此对应的是老的OPC DA协议, 是严重依赖DCOM协议的,而DCOM协议是微软推出的用于电脑间通讯的协议,微软也曾经参与了OPC DA的制订,造成的后果便是,所有非微软的操作系统平台全部无法使用OPC DA协议,甚至微软自己的WINCE。因为它们没有能力支持DCOM。

 

进一步造成的后果是,以往, 所有的人机界面设备在跟PLC通讯的时候, 如果不包含PLC品牌的驱动, 而需要走OPC协议的时候,就必须在电脑上安装一个OPC SERVER的软件中间件。 这个中间件作为一个后台系统服务,一方面负责跟就地的PLC通讯,另一方面向本地或网络内的其他电脑设备提供OPC数据服务。

 

这个OPC SERVER软件通常是由PLC厂家提供,比如西门子的 SIMATIC NET, 三菱的MX OPSERVER等等。同时也有一些通用于各厂家协议的专业的OPC SERVER软件, 最著名的即大名鼎鼎的 KEPSERVER。

 

所以, 以往在实现OPC DA的通讯的配置中,貌似以为上位机软件与PLC进行OPC通讯, 其实不然。 其实电脑上跟PLC通讯的还是PLC的协议,如西门子的S7协议。 如果只有一台电脑, 那么所谓的OPC通讯,只是电脑上的两个程序进程之间的通讯而已。 比如WINCC或者IFIX或者组态王跟 OPC SERVER之间的通信。

 

所以,那个时候,电脑跟PLC的通讯网络各种各样,基本都基于各厂家自己的协议和网卡, 有少部分以太网,但大部分是基于RS485的网络。

 

然而,当所有主流PLC都支持以太网的时候,电脑和PLC之间,以及触摸屏和PLC之间都是通过交换机接到以太网的链接的时候, 通讯还要靠OPC来实现协议转换, 第三方的触摸屏如果没有开发出针对特有品牌的通讯协议驱动的时候,有没有通用协议?

 

没有。这就很尴尬了。

 

而OPC UA的出现,解决了这个问题。

 

既然UA协议不依赖于平台, 那么各厂家的PLC在自家平台上大展神通, 只要其PLC有提供以太网口, 只要在以太网口上实现了OPC UA SERVER功能, 那么所有的OPC 客户端都可以直接来访问,而不再依赖于一个特定的OPC SERVER 中间件。

 

如此可以实现:

1,  触摸屏通过OPC UA协议直接访问PLC。

2,  不同的PLC之间通过OPC UA协议访问。

3,  上位机电脑SCADA上位机软件直接与PLC通讯。

 

这些功能扩展都是以前OPC DA协议时不可能实现的。

其中,1和2是完全全新的配置模式,而3的变化比较少,仅仅少了OPC SERVER中间件。

 

这对各PLC厂商无所谓, 他们反而可以省了开发OPC SERVER 软件的人力,不过这部分研发人员转向其自身嵌入系统的OPC UA SERVER的功能开发,大致可以相当于不亏不赚。

 

然而对专业售卖OPC SERVER的软件公司,比如KEP和MATRIK等来说,几乎是灭顶之灾。因为没有他们的生存空间了。若干年后,当所有品牌PLC和HMI, SCADA都支持了OPC UA之后,就没人再需要他们了。

 

所以,站在专业OPC SERVER软件的角度, 描述OPC UA的态度就会很暧昧,就会很言不由衷,比如会不会有意无意发表一些误导同行的观点。

 

比如许多同行所理解的OPC UA,谈到优点的时候仅仅是在电脑之间做通讯的时候不需要配置DCOM,而过去据说DCOM配置起来相当麻烦,非常难以成功。

 

从我个人的经验,DCOM完全没有传说中的那么难。 给一个简单的提示, 如果一台电脑完全安装好需要的所有控制软件后, 直接克隆到另一台,之后对方仅仅更改电脑名,即两台电脑的操作系统、软件环境完全一致, 用户名和密码等全部都一致的情况下, OPC DA通讯可以直接成功,不需要为DCOM做任何的配置,甚至完全可以无视。

 

所以,当我看到许多人对OPC UA的错误言论的时候,首先猜测他们是不是因为受到了一些刻意的误导。

 

然而,我所列出的上述的 OPC UA的优点好像并不能引起很多人的兴趣。也更不觉得有何重要性而言。

 

是的,一直以来我也这么认为的。因为到目前为止, 不管是触摸屏还是上位机软件,当下都有通讯实现方案,也不觉得有多少痛点。

 

 

而真正的重点在后面。

 

进入重点之前, 先看一篇我2年前写过的一篇文章:

《【万泉河】PLC编程:我梦寐以求的符号寻址》

http://www.ad.siemens.com.cn/club/bbs/PostStory.aspx?a_id=1565815&b_id=80


 

当时我苦苦追求的符号寻址,后来发现, 解决方案竟然是OPC UA。

 

西门子WINCC和S7-1500之间的通讯自然有固有的方法, 然而换一些品牌,比如把WINCC换为触摸屏, 甚至第三方品牌触摸屏的时候, 逐渐发现OPC UA才是最完美的解决之道,而且因为UA的统一架构, 那么会成为所有品牌的统一解决方案。

 

即, OPC UA可以实现对PLC的符号寻址。

 

对所有品牌PLC。 甚至对S7-1200/1500,都不再需要数据块非优化。即,即便是优化的数据块, 也可以通过OPC UA直接进行数据通讯,因为这种通讯已经不需要绝对地址了。

 

有了OPC UA, 如果触摸屏也支持了(现在已经开始有品牌支持),那么只要选择OPC UA通道,对PLC的数据就可以直接建立访问。

 

然而,需要客户端软件有完备的浏览变量功能。

 

通过在线浏览变量,就可以选择并在数秒内建立所有需要的变量。

 

这相当便捷。

 

所以,去年我在开发其他品牌的标准化架构的时候,最看重的是这个品牌的PLC是否已经支持了OPC UA,因为只要支持,只要把UA通讯打通, 那我就不需要再学别的通讯方案了。 工作量也大为简化了。 原有的WINCC程序可以直接无缝对接移植过来。

 

如果是真实的工程项目,这种无缝移植带来的高效率自是无可比拟的。 所耗费的时间简直忽略不计啊!

 

而更进一步, 如果所有的上位机软件如果也支持OPC UA, 那只要再做一套上位机的项目程序模板,在项目开发、程序移植各环节的工作量,也全部非常简单。从wincc到上位机, 从一个项目的上位机到下一个项目的上位机。都会带来异乎寻常的高效率体验。

 

甚至, 在OPC UA的协议规范中,还特别涉及了对面向对象的支持。可以把一个设备对象的数据打包整体对接,这些工作到目前为止,都还在幻想蓝图里,还没有落地成为现实,所以绝对值得我们每个人期待。。。。

 

我在前面一篇文章推荐过的上位机开发工具PCHMI.DLL,

 

《0210【万泉河】用组态触摸屏程序的方法生成上位机EXE软件》

https://mp.weixin.qq.com/s/5hfgLZrWNvnt0TqopDDQcg


 

这个工具里面包含了对OPC UA的支持,然而我研究后发现,其支持力度还很弱, 甚至作者对OPC UA的理解都很浅,当然也是因为不重视, 不感兴趣,因而更不支持变量浏览功能。所以要达到实战功能, 能实现我们要求的符号寻址,都还有很长的路要走。

 

所以暂时放弃了UA路线, 还是先能实现与BST的对接为目标,先实现弹出式窗口的设计操作模式。变量效率的提高方面,可以作为将来的话题。

 

然而,我发现工控同行中的大多数,通常思想懒惰,没有上进心。

 

当遇到各种功能实现不了效率低下的时候,不会首先审视是不是自己的能力和水平的原因,而是只会自顾个儿的在那儿抱怨,更不会想到自己挖掘其中的需求,找到好的解决方案,除了能提高自己的工作效率,同时说不定还能为自己储备积累一些资源。

 

我上周与一位有C#经验的朋友交流开发需求的时候, 对方竟然指点我去找某某高手去定制开发, 完全没有看到这其中存在的机会。

 

当所有人都在抱怨这个行业脏苦累的时候,有没有想过这其中反而蕴藏了无限的机会, 你只要能做出一点点创新, 帮助别人有一点点效率的提高, 都有可能为你自己带来丰富的回报。

 

越是落后的行业,机会越多。 如果你时常抱怨这个行业落后,那说明机会就摆在你面前。

 

就看你有没有能力抓住机遇。

 

最后,上文中征集PCHMI二次开发合作项目继续进行中,目前响应者了了。说明这个行业具备这项能力且工作之余有闲暇进行技术开发的人还太少了, 说明了什么, 说明这里面都是机会啊!


微信公众号:PLC标准化编程,ZHO6371995
您收到0封站内信:
×
×
信息提示
很抱歉!您所访问的页面不存在,或网址发生了变化,请稍后再试。