什么是OPC协议？

为了便于自动化行业不同厂家的设备和应用程序能相互交换数据，定义了一个统一的接口函数，就是OPC协议规范（OLE for Process Control）。有了OPC就可以使用统一的方式去访问不同设备厂商的产品数据。

OPC基金会前前后后规定了不同的接口定义，如下：

OPC DA (Data Access, exchange of real-time values)

OPC A&E (Alarms & Events, exchange of alarms and events)

OPC HDA (Historical Data Access, exchange of historical values)

OPC XML DA (XML-based exchange of real-time values)

以上所有的接口定义，我们现在都统称为OPC。OPC是基于WINDOWS COM/DOM接口技术来规定的。

比如我们可以了解下OPCGroup的接口定义如下：

//*********************************************************
// IOPCGroup Interface
[
object,
dual,oleautomation,
uuid(28E68F96-8D75-11d1-8DC3-3C302A000000),
helpstring("OPC Group Object"),
pointer_default(unique)
]
interface IOPCGroup : IDispatch
{
// Properties
[propget,helpstring("Returns the parent OPCServer")]
HRESULT Parent([out, retval] IOPCAutoServer ** ppParent );
[propget]
HRESULT Name([out, retval] BSTR * Name );
[propput]
HRESULT Name([in] BSTR Name );
[propget,helpstring("True if this group is public")]
HRESULT IsPublic([out, retval] VARIANT_BOOL * IsPublic );
[propget,helpstring("True if this group is active")]
HRESULT IsActive([out, retval] VARIANT_BOOL * IsActive );
[propput]
HRESULT IsActive([in] VARIANT_BOOL IsActive );
[propget,helpstring("True if this group will get
asynchronous data updates")]
HRESULT IsSubscribed([out, retval] VARIANT_BOOL * IsSubscribed );
[propput]
HRESULT IsSubscribed([in] VARIANT_BOOL IsSubscribed );
[propget]
HRESULT ClientHandle([out, retval] LONG * ClientHandle );
[propput]
HRESULT ClientHandle([in] LONG ClientHandle );
[propget]
HRESULT ServerHandle([out, retval] LONG * ServerHandle );
[propget]
HRESULT LocaleID([out, retval] LONG * LocaleID );
[propput]
HRESULT LocaleID([in] LONG LocaleID );
[propget]
HRESULT TimeBias([out, retval] LONG * TimeBias );
[propput]
HRESULT TimeBias([in] LONG TimeBias );
[propget]
HRESULT DeadBand([out, retval] FLOAT * DeadBand );
[propput]
HRESULT DeadBand([in] FLOAT DeadBand );
[propget,helpstring("Rate data can be returned to an
application (in mSec)")]
HRESULT UpdateRate([out, retval] LONG * UpdateRate );
[propput]
HRESULT UpdateRate([in] LONG UpdateRate );
[id(0),propget,helpstring("Returns the OPCItems
collection")]
HRESULT OPCItems([out, retval] OPCItems ** ppItems );
// Methods
HRESULT SyncRead(
[in] SHORT Source,
[in] LONG NumItems,
[in] SAFEARRAY(LONG) * ServerHandles,
[out] SAFEARRAY(VARIANT) * Values,
[out] SAFEARRAY(LONG) * Errors,
[out,optional] VARIANT * Qualities,
[out,optional] VARIANT * TimeStamps);
HRESULT SyncWrite(
[in] LONG NumItems,
[in] SAFEARRAY(LONG) * ServerHandles,
[in] SAFEARRAY(VARIANT) * Values,
[out] SAFEARRAY(LONG) * Errors);
HRESULT AsyncRead(
[in] LONG NumItems,
[in] SAFEARRAY(LONG) * ServerHandles,
[out] SAFEARRAY(LONG) * Errors,
[in] LONG TransactionID,
[out] LONG * CancelID);
HRESULT AsyncWrite(
[in] LONG NumItems,
[in] SAFEARRAY(LONG) * ServerHandles,
[in] SAFEARRAY(VARIANT) * Values,
[out] SAFEARRAY(LONG) * Errors,
[in] LONG TransactionID,
[out] LONG * CancelID);
HRESULT AsyncRefresh(
[in] SHORT Source,
[in] LONG TransactionID,
[out] LONG * CancelID);
HRESULT AsyncCancel(
[in] LONG CancelID);
};

什么是OPC UA?

为了应对标准化和跨平台的趋势，为了更好的推广OPC，OPC基金会近些年在之前OPC成功应用的基础上推出了一个新的OPC标准-OPC UA。OPC UA接口协议包含了之前的 A&E, DA,OPC XML DA or HDA，只使用一个地址空间就能访问之前所有的对象，而且不受WINDOWS平台限制，因为它是从传输层Scoket以上来定义的，这点后面会提到，导致了灵活性和安全性比之前的OPC都提升了。

OPC UA的优势：

1、一个通用接口集成了之前所有OPC的特性和信息，A&E, DA,OPC XML DA or HDA

2、更加开放，平台无关性，WINDOWS,LINUX都能兼容

3、扩展了对象类型，支持更复杂的数据类型比如变量，方法和事件

4、在协议和应用层集成了安全功能，更加安全

5、易于配置和使用

核心的区别是因为OPC和OPC UA协议使用的TCP层不一样，如下：

OPC是基于DOM/COM上，应用层最顶层；OPC UA是基于TCP IP scoket 传输层。

其他一些区别：

OPC虽然通过配置COM/DOM来提供数据加密和签名功能，配置防火墙，用户权限来让数据访问变得更加安全，但是会增加额外的工作量，尤其是对非IT的工程师来说；对于OPC UA，数据加密和签名，防火墙等都是默认的功能。比如基于DOM的OPC使用的动态端口分配，端口不固定，让防火墙难以确定，而OPC UA的端口都是唯一的，比如SINUMERIK 840D是PORT 4840，SIMATIC S7是PORT 4845。DOM/COM也可以生成不同级别的事件日志，但日志内容不够详细，只会提供“谁连接上服务器”这种，而对于OPC UA来说都是默认的功能，生成的日志内容更全面。

后面会放上OPC UA的DEMO。

参考：https://blog.csdn.net/wfx7414/article/details/50629480

【前言】

OPC是一个工业标准，所属国际组织是OPC基金会，现有会员已超过220家，包括世界上所有主要的自动化控制系统、仪器仪表及过程控制系统的公司。

【经典 OPC】
经典OPC规范基于微软Windows系统提供的COM/DCOM技术，用于软件之间数据交换的规范。OPC规范定义了几种不同的，用于访问过程数据、报警信息以及历史数据的版本规范：
OPC实时数据访问规范（OPC DA）定义了包括数据值，更新时间与数据品质信息的相关标准。
OPC历史数据访问规范（OPC HDA）定义了查询、分析历史数据和含有时标的数据的方法。
OPC报警事件访问规范（OPC AE）定义了报警与时间类型的消息类信息，以及状态变化管理等相关标准。

【为什么要开发 OPC UA】
基于COM/DCOM的技术有着不可根除的缺点，因此随着技术的进步，以及数据交换各方面需求的提高，OPC基金会在2008年发布了新的规范：OPC UA。

【OPC UA 的技术特性】

OPC UA规范不再是基于COM/DCOM技术，因此OPC UA不仅能在Windows平台上实现，更可以在Linux，以及其他的嵌入式平台中实现。与传统OPC规范相同，OPC UA 同样有着相同的设计目标：1. 功能等价：所有的基于COM的OPC规范中的功能，都映射到了OPC UA中。2. 多平台支持：支持从嵌入式的微控制器到基于云的分散式控制架构。3. 安全：信息加密，互访认证以及安全监听功能。4. 扩展性：不影响现有应用程序的情况下，就可以添加新的功能。5. 丰富的信息建模：可定义复杂的信息，而不再是单一的数据。

【OPC UA相对于传统OPC的变化】

一、功能方面，OPC UA不仅支持传统OPC的所有功能，更支持更多新的功能：1. 网络发现：自动查询本PC机中与当前网络中可用的OPC Server。2. 地址空间优化：所有的数据都可以分级结构定义，使得OPC Client不仅能够读取并利用简单数据，也能访问复杂的结构体。3. 互访认证：所有的读写数据/消息行为，都必须有访问许可。4. 数据订阅：针对OPCClient不同的配置与标准，提供数据/消息的监控，以及数值变化时的变化报告。5. 方案(Methods)功能：OPC UA中定义了通过在OPCServer中定义方案（Methods），来让OPC client执行特定的程序。

二、平台支持方面，由于不再基于COM/DCOM技术，OPC UA标准提供的更多的可支持的硬件或软件平台。硬件平台诸如传统的PC机、基于云的服务器、PLC、ARM等其他微处理器；而软件平台可支持微软的Windows、苹果公司的OSX、安卓，以及其他的基于Linux的分布式操作系统。

三、安全性方面，最大的变化是OPC UA可以通过任何单一端口（经管理员开放后）进行通信，这使得OPC通信不再会由于防火墙受到大量的限制。

【OPC UA 的技术细节】

1、OPC UA在传输中可通过XML格式或者二进制格式来传输，并且可选择并兼容更多通用的IT通信协议，比如HTTPS。同时，在加密时，也能达到128或者256位的加密深度。在客户端与服务器的通信许可方面，OPC UA使用了OpenSSL许可证来规定哪些应用程序或系统可以使用OPC与另一端相连接。2、在建模方面，OPC UA将建模的架构由“数据建模”扩展为了“信息建模”。OPC UA规范中不仅仅提供了完整的面向对象的数据建模，同时也可定义复杂的多级结构体。数据类型或结构体都在配置文件（profiles）中定义，不仅可以定义已存在的传统OPC规范中的类型，还可以扩展加入其他的供应商或组织定义的新类型。

智能制造还有多远？--谈谈为什么要采用OPC UA？

前段时间与PLCopen主席严义老师探讨在PLCopen教育合作项目，据严老师前期的调研发现，与运动控制相关的教材非常少，甚至很多大学老师也是不了解PLCopen Motion的，这让人难以接受，因为，就我们讲“智能”而言，运动控制的精度与速度关乎产品的质量与生产效率，而且控制工程网版权所有，通过灵活的参数设置，运动控制可以让生产变得更为灵活。我们不管上层架构是如何进行智能分析与优化的，但是，到了制造执行层面，如果缺乏运动控制系统的精准、柔性的执行，那么无法达到所谓的“智能”-执行是智能的重要组成，就相当于企业战略很美好，却无法执行。

同样道理，我们总是探讨高大上的云平台、大数据分析、人工智能、物联网，但是，数据互联却是第一个障碍，而同样道理，OPC UA作为数据互联的基础标准与规范，却似乎很多人并不了解，甚至很多做所谓工厂集成的人也不是很清楚，在数据采集、传输与生产运营中，我们会需要对现场的机器状态、生产能耗、质量相关、生产相关参数进行采集，但是，如果缺乏统一的标准与信息模型，我们会遇到非常大的困境。

智能制造的美好前景需要底层的技术支撑，标准与规范先行，否则，我们就会离智能制造很远—远到超出我们的想像。

一、数据采集的困境

尽管大家都认为大数据分析将给我们带来巨大制造优化潜力，并改善我们的生产运营效率、资产管理水平，但是，在现实的智慧工厂互联的时候，却困难重重，无论是IIoT还是大数据分析各种概念都给我们以未来无限光明的愿景，但现实却那么骨感。

（1）.大量的连接工作耗费精力

凡是在做智慧工厂的公司、系统集成商都清楚，包括MES厂商，就光将现场数据采集实现，这个工作量有多大，为了一个不大的项目，要去连接各种通信总线、要配置各种机器的参数，很多参数还因为技术保密的原因不开放，因此，采集了很多价值量并不高的数据，很多从IT业过来掘金工业物联网的公司都很郁闷，因为这个钱赚的实在是太辛苦，以至于他们对这件事情产生了悲观情绪。做自动化的还好，原来就是遇到这些问题，但对IT就很惨了，因为，这太过消耗工程师资源。

（2）.采集什么数据不是很清楚

这是一个困难，对于如何运营生产系统，往往很多做IT的缺乏对机器的了解，对生产工艺、流程的了解，不能定义清楚需要采集什么样的数据？如何使用这些数据？

很多时候，大家只是说“先把数据采起来再说”，至于这个数据能干什么，那是以后的事情，先让数据不要流失、浪费，但是，如果不知道数据的用途，那么你怎么知道你采集的数据是对的？如果采集了一大堆数据在用的时候发现少了一个数据不能用于分析工艺对能耗的影响，那岂非你所有采集的数据就没有用了？

（3）.数据要做什么用不清楚

这又是一个尴尬，就是要这些数据干什么用？如何使用这些数据，而这个问题又不再是一个技术问题，而牵扯到公司的运营管理水平的问题，如果能够达到较高的数据精准化管理、并且有先进的管理模型，那么这件事情反倒易于理解，因为首先它知道哪些数据需要采集，而如果运营管理水平一般的情况下就会出现委托第三方系统集成商采集的数据不知道该怎么用，这牵扯到企业的数字化经营的策略问题。

二、为什么要采用OPC UA？

包括主流的自动化厂商，以及IT世界的华为、Microsoft、CISCO等都成为了OPC UA的支持者，以及协会组织如OMAC、Euromap、Automation ML、ISA、FDT/DTM、MTConnect、BacNet，以及全球主要的现场总线基金会如PI、EPSG、ETG、SERCOSIII均支持与OPC UA的融合与开发工作，为什么这些国际自动化、IT、基金会组织、行业协会都聚焦在了OPC UA上？

图4为结合OPC UA的标准文档，自行设计的图用于阐述采用OPC UA的八个原因。

工业通信分为互联（硬件接口的连接）、互通（软件层面的数据格式与规范）、语义互操作（语义的定义与规范）几个层面，而各种总线解决的是连接问题，而互通解决了应用层的匹配，而OPC UA则解决不同系统之间的语义的互操作-包括应用行为与动态功能。

独立性、安全、国际标准、建模与信息模型、即插即用这些都是从技术角度来分析OPC UA何以成为大家关注的焦点。

三、信息模型的建立

如何理解信息模型？

信息模型是什么？如果用OPC UA的技术来介绍可能不大易于理解，但是，如果我们想实现机器人与注塑机进行协同的工作的时候，我们必须清楚，他们之间需要哪些数据来保证他们之间的工作一致性呢？这就是数据的应用问题，而同样道理，我们希望实现OEE的统计，那么OEE的计算就是一个信息模型，我们需要与之相关的数据，而垂直行业的信息模型则在于具体的包装、塑料、印刷行业所采集的对象定义不同。

图5-让数据变得规范与标准

简单理解信息模型就是为了实现特定任务，而对数据所进行的标准封装，OPC UA提供了一个如何封装信息模型的标准，除了已经纳入到OPC UA架构下的PackML、MTConnect、Euromap、Automation ML等之外，OPC UA还支持行业自定义的信息模型，OPCUA采用面向对象的思想，使得这些开发变得简单。

图6-OPC UA架构

图6是OPC UA的架构，它包含了基础信息模型、行业信息模型，也包括制造商自定义的信息模型，提供传输服务、发现功能是基础的，而信息模型是跨平台、跨行业的应用需求。

四、OPC UA的应用好处有哪些？

4.1对于系统集成而言，OPC UA有哪些好处？

我们必须确保针对质量、效率、能源、维护等参数具有统一的模型，这样可以让我们做到以下几点：

（1）.软件复用：通过数据建模形成的应用模块，如PackML可以让我们针对包装机与MES相互关联的数据统一封装，可以通过一个模块的调用即可实现相关数据的调用。这就像贝加莱的mapp中的PackML、Euromap软件模块一样。

在程序开发中也存在这样的问题，当HMI与应用程序之间出现一方修改时，另一方也得修改，另外一方面，针对不同的屏幕尺寸需要采用不同的画面设计。对OEM厂商而言，这便意味着为了个性化的机器，必须反复的修改画面和程序、并对不同尺寸规格的HMI进行重新设计。

图7-mappVIEW借助于OPC UA实现关注点分离

图7所示的mappVIEW技术即通过OPC UA实现了HMI与程序的关注点分离，使得修改HMI画面的组态界面、流程与应用程序无关，而应用程序的修改也不会影响HMI的画面。并且，任意尺寸规格的HMI、智能终端均可自适应的访问机器数据。

当然，关注点分离也是模块化软件实现的主要方式，这与软件模块化可以列入同一优点描述。

（3）.大量的节约工程时间：由于采用了标准的数据模型，使得数据仅需配置，而无需大量的编程操作www.cechina.cn，另外，标准的数据包一次性让与任务相关的数据被读取，而无需很多次的调用不同的参数，这也节省了工程时间。

（4）.最大化数据应用：设计与生产、维护等能够在同一架构下进行数据交换，实现企业的数据共享与数据价值的最大化发挥。就像Automation ML一样，从工程设计平台到工艺辅助平台、MES、控制层数据可以实现统一的标准下的连接和分享。

OPC UA在整体上使得在工厂的各个环节的横向与纵向数据实现了透明交互，并且，配置效率更高，程序与应用模块化更强，使得工厂组织更为便利，即使面对复杂的变化，也可以实现快速的切换。

4.2行业信息模型带来快速数据配置与采集

（1）.无关PLC是谁家的：如果我不用在乎谁家的控制器开发的注塑机、机械手的系统，而是直接通过数据的标准配置即可访问到机器，那是否很方便的呢？

显然，这是今天做工厂集成项目的人的最美好想法，可现实中却并非如此，也是可以连接的，他们需要针对不同的控制器配置不同的软件程序、而且还需要不同的接口模块来支撑，但是如果无论你采用何种品牌控制器、采用何种现场总线，只要你采用OPC UA，我们就可以相互访问和配置机器的参数，那么这是否会让工厂的集成人员变得工作简单很多呢？

Euromap 77是基于OPC UA的标准设计的注塑机通信模型，包括了注塑机信息、配置、状态、模具、驱动的数据对象，也包括Job、数据集管理的数据模型，如图8所示。

图8-Euromap 77基于OPC UA的注塑机信息模型开发

对于PackML而言，其旨在提供相应的能力去连接MES与质量数据，其实，对于PackML而言，图9的机器状态使得机器的时间统计变得简单，而PackML正是遵循了OPC UA的标准与规范。

图9-PackML的设备状态

通过图9所示的状态与显示画面，每个按键按下都会记录时间，最终与设备OEE统计相关的时间将被用于实现生产运营效率的统计分析。

（3）.实现OICT融合的数据融合

OICT的融合，必然使得跨平台的IT与OT系统在语义方面需要融合，每个人必须懂得另一个人所说的每局话的含义，采用统一的标准数据格式、单位标准（公斤、瓦特、米、秒、小时）、能源采集的标准与数据集的统一。

边缘计算正在连接现场设备，实现数据应用，而OPC UA则是一个标准与规范，用于实现IT与OT的互联，如图10，注塑机的参数通过Euromap标准被管理、分析系统读取并通过OPCUA将生产任务下达至机器。

图10-基于OPC UA实现注塑机新工厂与老工厂的集成

事实上，各个行业都在大张旗鼓的推进着智能制造，但是，就基础的而言，OPC UA、PLCopen等标准化工作是必须先行的，当然也包括基于IEC 61508的功能安全技术标准、机器人的ISO 10218等。

这就是想说的“智能制造离我们还有多远？”—我们应该基础工作做好。不仅产业里www.cechina.cn，包括大学里的课程，关于互联互通这些问题还停留在久远的现场总线，而无视产业已经大量的采用实时以太网技术，而新的TSN也将在不久与OPC UA融合成为可以预见的未来互联集成方案。

转自：https://blog.csdn.net/xiaoliu0515_0515/article/details/89442498

OPC与OPC UA

智能制造还有多远？--谈谈为什么要采用OPC UA？

猜你喜欢