XSLT存档  

不及格的程序员-八神
 查看分类:  ASP.NET XML/XSLT JavaScripT   我的MSN空间Blog
OPC协议

OPC协议解析-关于OPC协议的几个问题

 

1    什么是OPC协议？

为了便于自动化行业不同厂家的设备和应用程序能相互交换数据，定义了一个统一的接口函数，就是OPC协议规范。有了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)

2      OPC DA是什么？

OPC DA指代的是 OPC数据访问规范。它是由OPC基金会定义的其中一种通信规范, 定义了实时数据如何在数据源和数据接收体（比如PLC, HMI）之间, 在不知道彼此特定通信协议的情况下仍然进行交换、传输。

2.1     为什么OPC DA如此受欢迎？它和过去的通信协议有什么不同?

OPC DA客户端/服务器结构服务器结构是OPC基金会界定的首个结构。在OPC DA 之前, 供应商的产品（设备、PLCs、HMIs）要求与这些产品相连接的任何设备或应用程序要自带“特制驱动”, 以在第三方通信和所涉及的供应商产品之间进行数据传译。像这样基于“特制驱动”的通讯存在许多问题, 其中最常见的有：成本高、将用户限制在某一特定供应商、由于每一个特制驱动都有其独有的处理方式而造成配置和维护的困难、由于新设备和应用程序的层出不穷而造成难于更新。相比之下,OPC DA却可以与任何实时数据源相连接, 也不需要为数据源或数据接收端特制任何驱动程序。 因此, 数据接收器不需要了解数据源的本地协议或内部数据结构就可以进行读和写。

2.2     OPC DA规范是只有一种吗？

很难说是或不是。因为OPC DA规范由OPC基金会来维护, 它们已经经过多次修订。主要版本包括:

年份     版本     备注

1996    1.0       初始规范。

1997    DA 1.0a      数据访问（DA）, 该名称用于区分与其并行开发的其它规范。

1998    DA 2.0 - DA 2.05a   多处规范澄清和修改。

2003    DA 3.0 进一步补充和修改。

考虑到有不同版本的OPC 数据访问（OPC DA）规范, 关键问题是：这些版本反向兼容吗? 例如：OPC DA 1.0a 客户端是否可以与OPC DA 3.0 OPC服务器通讯？答案是：这取决于具体情况。

2.3     数据访问OPC客户端及OPC服务器反向兼容性

开发商编写反向兼容的OPC客户端及OPC服务器是值得推荐的, 同时这也是可以实现的。然而, 因为反向兼容性是可选功能, 而不是强制功能, 这意味着会有许多开发商选择（并且会继续）开发仅仅遵循一种或两种规范的OPC DA服务器, 而不是遵循所有规范。这样的话, 那些非反向兼容的OPC服务器及OPC客户端仍然向用户提供OPC所带来的些许优势, 但仅仅局限于特定版本的规范。好消息是MatirkonOPC不仅开发完全反向兼容的OPC服务器, 也提供OPC数据管理产品（如： OPC Data Manager及OPC Security Gateway）。这些产品在非向后兼容的OPC客户端及服务器之间, 通过及时地在 OPC DA不同规范之间转换实现彼此通讯。

3      如何使用OPC 数据访问规范 (DA)

3.1     何时使用OPC DA？

简单的回答就是：用于需要传输实时数据的任何时刻。对于需要考虑的多种情形, 下表介绍了最常见的几种类型, 简述了一些难点, 并给出了利用标准OPC组件加以解决的相关建议。

数据源

数据接收端（用户）

OPC解决问题

相关建议

控制器（外部PLC）

应用程序（HMI）

不同厂商的控制器均使用各自的通信协议。OPC省去了HMI 针对各控制器“定制驱动器”的需要。

- 控制器：使用 OPC 服务器 for 控制器 X
- 应用程序：通常有内置的OPC客户端。如果没有, 则可使用适用于该应用程序Y的OPC DA 客户端。

控制器/设备

控制器或控制设备

备 OPC服务器为您解决了控制器之间的通信, 因为各产品均采用各自厂商的通信协议, 不同于控制器与应用软件间的通信。

- 数据源端、数据接收端的控制器X和Y分别需使用OPC DA服务器 for X和OPC DA 服务器for Y。
- 使用 OPC Data Manager, 在两控制器间实现有关实时数据的智能化传输。

控制器/设备

关系数据库

关系数据库利用“结构化查询语言”（SQL）通过“开放数据库互联”（ODBC）协议进行通信；而控制器和控制设备则利用各自的自定义协议。找到一个贯穿两者的数据桥并非易事, 通常需要一定的技术经验才能建立起来。

- 利用 OPC DA Client for ODBC 从OPC服务器中获取实时OPC数据, 通过SQL/ODBC将其准确地传输到数据库。
- 利用 OPC DA 服务器 for 设备 X 公开数据。

- 注：OPC DA为双向式通信, 因此在必要时, 也可将实时数据从数据库写入设备或控制器中, 或将应用程序的数据写入OPC客户端。

控制器/设备

 过程历时数据库（Historian）

过程历史数据库采集的是实时数据, 它们通常有自己的通信协议和自定义驱动来收集各种设备或应用程序的数据。这里的难点是找到一个历史数据库不仅支持现有设备还要支持将来可能出现的数据源。

历史数据库有其自己的标准协议, 且几乎所有的historian都有内置OPC DA客户端。 OPC Desktop Historian 就是这种有内在OPC接口历史数据库的其中一个。

- 对于数据源：用一个用于数据源X的 OPC DA服务器即可。

冗余的设备

控制器/应用程序

按照传统的方式, 如果控制器或应用程序不支持设备级冗余, 为保证设备的冗余性, 额外的硬件是需要的。

- 对控制器：需要用于控制器X的OPC服务器。
- 不同的设备可以使用不同的OPC服务器。
- 使用 OPC Redundancy Broker (ORB) 来实施冗余机制。
- 对应用程序（如：HMI或Historian）：可以用 OPC客户端用于应用程序X。

远程设备（数据采集与监视控制系统）SCADA:例如，远程终端控制系统RTU

应用程序/控制器

由于通讯故障和低频带宽, 与远程设备和数据来源之间的通信一般较为复杂, 同时也更昂贵。而自定义驱动程序的问题在于不同通信渠道的稳定性难以保障

远程设备应该选择SCADA类的OPC服务器。跟一般现场应用的OPC服务器不同, 这类OPC服务器是专门为适应复杂的SCADA工作环境而设计的。（例如, MatrikonOPC Server for SCADA Modbus)

 

3.2     可以用OPC DA传输历史数据吗？

不能。任何OPC DA都是专用于传输当前数据的。一旦当前数据已经被读, 下一数据的读取就会开始, OPC DA没有为OPC DA客户端提供历史数据的接口。如果要传输历史数据, 需要使用同样基于 OPC客户端-服务器结构 的OPC历史数据存取规范（OPC HDA）。

3.3     同一供应商生产的OPC DA客户端程序可与不同供应商的OPC服务器搭配工作吗？

一般情况下是可以的, 在OPC DA客户端与服务器都支持同样版本的OPC DA规范（见上文）或者至少其中一个能够反向兼容的条件下。

4      OPC客户端-服务器结构

OPC 通信结构是指包含一个或多个OPC客户端与服务器相互通信的集合。最简单的理解方式, 便是读懂如下这张数据流程图。它显示了数据由数据源从下至上到达数据接收体的过程。

 

OPC 服务器：在这个例子中, 如果数据源有一个内在的OPC客户端, 那么外在的OPC客户端就不是必须的了。

OPC 通信：因为OPC基金组织定义了多种 OPC通信规范 保证可以传送不同形式的数据信息, 所以OPC开发商和用户必须理解OPC服务器和客户端的通信有时候不局限于单一的数据访问形式。这个概念的理解之所以重要, 是因为同一种OPC服务器往往会支持多于一种的OPC数据访问规范。

OPC协议解析-OPC UA OPC统一架构

 

1    什么是OPC UA

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

2    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来说都是默认的功能，生成的日志内容更全面。

3    OPC UA

OPC统一架构（OPC Unified Architecture）是OPC基金会（OPC Foundation）创建的新技术，更加安全、可靠、中性（与供应商无关），为制造现场到生产计划或企业资源计划（ERP）系统传输原始数据和预处理信息。使用OPC UA技术，所有需要的信息可随时随地到达每个授权应用和每个授权人员。

 

OPC UA 独立于制造商，应用可以用他通信，开发者可以用不同编程语言对他开发，不同的操作系统上可以对他支持。OPC UA 弥补了已有 OPC 的不足，增加了诸如平台独立、可伸缩性、高可用性和因特网服务等重要特性。

OPC UA 不再基于分布式组件对象模型（DCOM），而是以面向服务的架构（SOA）为基础。OPC UA 因此可以连接更多的设备。

今天，OPC UA 已经成为连接企业级计算机与嵌入式自动化组件的桥梁 - 独立于微软、 UNIX 或其他操作系统。

4     OPC 统一架构 - 标准化通信

通过因特网和通过防火墙的标准化通信 - OPC UA 使用一种优化的基于TCP的二进制协议完成数据交换；另外支持Web服务和HTTP。现在允许在防火墙中打开一个端口，集成的安保机制确保了通过因特网也能安全通信。

防止非授权的数据访问 - OPC UA 技术使用一种成熟安保理念，防止非授权访问和过程数据损坏，以及由于不小心地操作带来的错误。OPC UA安保理念基于World Wide Web 标准，通过用户鉴权、签名和加密传输等项目来实现。

数据安全性和可靠性 - OPC UA使用可靠的通信机制、可配置的超时、自动错误检查和自动恢复等机制，定义一种可靠坚固的架构。对OPC UA客户机与服务器之间的物理连接可以进行监视，随时发现通信中的问题。OPC UA具有冗余特性，可以在服务器和客户机应用中实施，防止数据的丢失，实现高可用性系统。

在简化接口方面进行了很多改进 -新 OPC UA 在所有平台上的通信更快速、更安全和更灵活。

平台独立和可伸缩性 -  由于使用了基于面向服务的技术，OPC UA 具有平台独立的属性，可以实施全新的、节省成本的自动化理念。嵌入式现场设备、过程控制系统（DCS）、可编程逻辑控制器（PLC）、网关或者操作员面板（HMI）可以依靠OPC UA服务器，直接连到操作系统，诸如嵌入的Windows、Linux、VxWorks、QNX、RTOS 或者其他系统。使用一台独立的Windows PC 用做 OPC 服务器，提供对非Windows设备数据访问的模式今天已经淘汰。当然，OPC UA 组件也可以在Unix操作系统的信息技术（IT）系统中使用，诸如：Solaris、HPUX、AIX、Linux等，可以是企业资源计划（ERP）系统，可以是生产计划（MES）和监控软件（SCADA），还可以是电子商务应用。OPC UA 的组件功能是可以是伸缩的：小到一个嵌入式设备的瘦应用，大到公司级别大型计算机的数据管理系统。

简单一致 - OPC UA 定义了一种集成的地址空间和信息模型，可以显示过程数据、报警、历史数据以及完成程序调用。信息项被定义成不同类型的对象，彼此之间可以建立关系。 在此基础上，OPC UA 支持使用复杂数据结构。这使 OPC UA可以完整地描述复杂过程和系统。

对传统的三种不同类型OPC服务器的访问 - 数据访问（DA）、报警和事件（AE）、历史数据访问（HDA） -比如，要获得一个温度传感器的当前值、一个高温度事件和温度的历史平均值，要依次使用不同的命令执行。而使用OPC UA，仅用一个组件就非常容易地完成了。配置和工程的时间也因此可以大大缩短。

性能强劲 - 通过自身的不断发展，依靠基于TCP UA 二进制协议，使用高效的数据编码，OPC UA 提供了非常高效的数据传输，满足了更高性能的要求。

更多的应用选项 - OPC UA 技术的广泛适用性使全新的垂直集成理念能够完全实施。对OPC UA 组件进行串级，从车间现场设备到制造执行系统（MES）或企业资源计划（ERP）系统，信息能够安全和可靠地传输。在现场设备级的嵌入式UA 服务器，在自动化级的UA 组件，在企业级ERP系统中集成的UA 客户机，可以进行串级连接。各自的UA 组件可以在地理上是分布的，而且容易使用防火墙让彼此分开。

 

为把这种信息模型作为一种推广的技术，OPC UA 与其他标准化组织合作，希望把UA 服务提供给各行各业使用。今天，OPC 基金会已经与不同的标准化组织进行了合作，诸如：PLC开放组织（PLCopen）、国际自动化协会（ISA）和电子设备描述语言（EDDL）合作团队（ECT）建立合作标准。

5 　OPC UA - 平台独立，结构伸缩，保护投资

OPC UA 将在一个比较长的时期里替换传统的OPC。在这个过渡期中，基于DCOM的OPC产品会与UA 产品共存。OPC基金会的迁移战略可以让传统的OPC 和OPC UA产品很好结合。用这种方式，已经安装使用的几百万套、上千种传统的OPC产品可以与新的OPC UA产品共同使用。这为用户提供了优势，因为他们能够从不同的制造商-传统的OPC 和 OPC UA 厂家，选用任何需要的产品。

 

　开放

　　- 超过 450 个成员；

　　- 平台中性；

　　- 应用普遍；

　　- 所有连接。

　特色

　　- 工业标准；

　　- 独立于制造商；

　　- 互操作能力；

　　- 可靠性。

　协同

　　- 设备集成；

　　- IEC 61131-3 / PLCopen；

　　- 分析设备集成；

　　- 企业 - 控制系统集成（ISA-95），批处理（ISA-88）；

　　- 智能电网；

　　- 现场设备集成；

　　- EDDL 与现场设备技术（FDT）。

　安全

　　- X509 认证

　　- OpenSSL 加密

　　- 用户名 / 密码

　　- 每种属性的访问权限

　合作伙伴

　　- PLCopen

　　- ISA

　　- MIMOSA

　　- FDT

　　- ECT

您现在使用的中文变体可能会影响一些词语繁简转换的效果。建议您根据您的偏好切换到下列变体之一：大陆简体、香港繁體、澳門繁體、大马简体、新加坡简体、臺灣正體。（不再提示 | 了解更多）
 
 
 
中文维基百科Facebook粉丝专页正式上线，邀请大家一同关注。
 [关闭]
 

OPC UA[编辑]

维基百科，自由的百科全书
 
 
 
跳到导航跳到搜索
此条目需要精通或熟悉相关主题的编者参与及协助编辑。 (2018年3月1日)
请邀请适合的人士改善本条目。更多的细节与详情请参见讨论页。
Ambox scales.svg
 此条目偏重在某些见解、事件或争议上。 (2018年3月)
请协助建立更平衡的陈述以符合比例原则。在移除本提示前请先讨论并解决相关问题。

OPC UA的全名是OPC Unified Architecture（OPC统一架构）。是OPC基金会应用在自动化技术的机器对机器网络传输协议。有以下的特点：

  • 著重在资料收集以及控制为目的的通讯，用在工业设备以及系统中
  • 开源标准：标准可以免费取得，实作设备不需授权费，也没有其他限制
  • 跨平台：不限制作业系统或是程式语言
  • 面向服务的架构（SOA）
  • 强健的信息安全特性
  • 整合的信息模型，是资讯整合中，基础设施的基础，制造商以及组织可以将其复杂的资料在OPC UA命名空间上建模，利用OPC UA面向服务的架构的优点。

历史[编辑]

OPC UA和其前身开放平台通信（OPC）是由同一个组织所开发，但两者有显著不同。基金会开发OPC UA的目的是发展比原来OPC通讯架构（只使用Microsoft Windows的进程交换COM/DCOM）更理想的架构，也更符合正在发展中的工业自动化[1]

OPC UA的规格开发了三年，之后花了一年实现通讯协定，OPC UA的第一个版本在2006年问世。

到2015年10月10日为止，OPC UA最近的版本是1.03。除了client/server通讯协定外，新版的OPC UA也加入了publish/subscribe的机制。

创新[编辑]

开放平台通信（OPC）和COM/DCOM的结合虽让开放平台通信可以顺利推展，但有以下的缺点：

  • 频繁配置DCOM的问题
  • 没有可以规划的逾时机能
  • 只适用于Microsoft Windows
  • 资料安全性较低
  • 没有针对DCOM的控管（COM/DCOM类似黑盒子，开发者无法取得源代码，因此需要处理一些相关的问题或是未充份实现的问题）

因为这些缺点以及许多其他的考虑因素，使得OPC基金会决定开发一个针对全新而且独立的OPC UA通讯协定栈来取代COM/DCOM。其优点有：

  • 多平台实现，包括可携式的ANSI C、Java及.NET框架。
  • 可扩展性，从智能传感器、智能致动器一直到大型计算机。
  • 支援多线程，也有单线程/单任务的模式，以便将此通讯协定栈放在嵌入式系统中。
  • 基于新标准的资料安全性
  • 每个设备都有可以规划的逾时机能
  • 大容量资料报文的组块

通讯协定栈反映了架构创新的基础，OPC UA架构是服务导向架构（SOA），以许多不同逻辑层级为其基础。

OPC基础服务是抽象形别的叙述，和通讯协定无关，是OPC UA机能的基础。传输层将方法转换为通讯协定，将资料序列化（或反序列化），再传送到网路上。 为了上述目的，定义了两种通讯协定，其中一个是以效率进行过最佳化的二进制TCP讯定，另一个则是Web服务导向的协定。

OPC资讯模型是所谓的全网状网络（Full Mesh Network），以节点为基础。节点类似物件导向程式设计（OOP）中的物件，可以包括各种的元资料。节点可以有属性让其他设备读取（DA、HDA），有方法可以呼叫（Commands），也有可以启动传输的触发事件（AE、DataAccess、DataChange）。节点包括过程资料，也包括其他种类的元资料。OPC命名空间中包括了形态模型。

客户端软体可以确认伺服器支援哪些行规（profile），有需要获得这些资讯，知道伺服器是否只支援DA，或是还支援AE和HDA。而且可以得到伺服器是否支援特定行规的讯息。OPC UA还有以下重要的新机能：

  • 支援冗馀（Redundancy）
  • 双方向连结的心跳报文（Heartbeat）（确定另外一端是否“活著”），这表示客户端和伺服器都可以识别中断。
  • 传输资料及acknowledgement的缓冲（Buffering），连结遗失不会造成资料遗失，可以重新获取之前遗失的资料报文。

OPC UA 是在2006年10月在慕尼黑举行的 OPC UA DevCon 中首次公开其协定，在Beckhoff 的 PLC 上已有许多的 UA 伺服器，在 Euros 嵌入式测试电路板中也有UA伺服器。Beckhoff PLC 的底层是 Windows XP嵌入式系统，而嵌入式控制器执行的作业系统是实时操作系统 Euros。Embedded Labs Ltd 公司在他们执行在单晶片ARM控制器（64kb RAM） C++ UA Stack 上展示了 OPC-UA。2012年10月时德国的 Fraunhofer-Application Center IOSB-INA 以及工业信息技术研究所（Institute for industrial Information Technologies, inIT）证实了OPC-UA伺服器可以只使用15 kB RAM以及10 kB ROM，因此是晶片等级可以使用的通讯架构[2]。

通讯协定[编辑]

OPC UA支援两种通讯协定[3]，这两种通讯协定的差异只有URL的不同，二进位通讯协定是opc.tcp://Server，而Web服务的通讯协定是http://Server，其他情形下，OPC UA对应用程序接口的作业完全透明，其他作业不受OPC UA的影响。

二进位通讯协定的效率最高，其overhead也最少，让需要的资源最小化（不需要XML解析器、SOAP及HTTP，对嵌入式系统格外重要），提供最佳的互操控性（在实现时，二进位通讯协定提供较少的自由度），使用任意选取的TCP通道，可以较容易的进行隧道协议，也可以从透过防火墙开启。

Web服务（SOAP）通讯协定可以支援许多不同的工具（包括Java环境或是.NET环境的工具），使用标准HTTP(S)埠，可以和防火墙共同使用。

所有的实现方式都支援二进制通讯协定，但只有用.NET实现的设备才支援SOAP。

规范[编辑]

OPC UA规范属于多部份的规范，包括了以下部份：

  1. Concepts
  2. Security Model
  3. Address Space Model
  4. Services
  5. Information Model
  6. Mappings
  7. Profiles
  8. Data Access
  9. Alarms and Conditions
  10. Programs
  11. Historical Access
  12. Discovery
  13. Aggregates
  14. PubSub

OPC UA规范和其他以COM为基础的规范不同，OPC UA规范不是单纯的应用规范。其中会描述典型的UA内部机制，这些会在通讯协定栈中处理，因此一般只有要将通讯协定栈导入特定硬体的人，或是要开发通讯协定栈的人才会对这些内容有兴趣。

OPC UA应用程式的开发者需要撰写程式和OPC UA API沟通，因此主要只需要用到API的说明文件。不过应用程式开发者也可能会对其中的第3、4、5部份感兴趣[4]。

UA通讯协定栈[编辑]

UA应用程式在伺服器端或是客户端，其架构上都有分层的结构。

有些部份和以往的COM Proxy/Stubs相等，由OPC协会提供。可移植性级别（portability level）是新的，简化了引入UA ANSI C通讯协定栈的程序，也简化了移植到其他平台的的难度。OPC协会也提供了针对Window及Linux的port layer。

UA安全性[编辑]

UA安全性包括了认证、授权、加密以及透过签名实现的资料整合性。针对Web服务会使用WS-SecureConversation，可以和.NET和其他以SOAP实现的软体相容。若是二进制的版本，也会依循WS-SecureConversation的演算法，转换为二进制的版本，称为 UA Secure Conversation。

有另外一个混合的版本，程式是二进制的，而其传输层是用SOAP。这是在二进制的效率以及对防火墙友善的传输之间的妥协。因为是二进制的程式，会需要使用UA Secure Conversation。 其认证只使用X.509认证，是靠程式开发者决定UA应用程式要使用哪一个证书存储区。例如，也可能使用Active Directory中的公开金钥基础建设（PKI）。

OPC UA API[编辑]

在许多程式语言中都有UA的API。在C、C++、Java及.NET中有商业的SDK。而至少在C、C++、Java、Javascript(node)及Python中有其开源的通讯协定栈。

C++下的OPC UA[编辑]

.NET下的OPC UA[编辑]

.NET版本的实现在底层用ANSI C，其馀部份使用.NET。因此只有网路端点的处理以及消息分块的取得是从ANSI C的通讯栈处理的。反序列化直接在.NET中进行，会直接转换为.NET的结构及物件。因此其效能会比先反序列化成C语言结构，再复制到.NET结构的效率要好。

Java下的OPC UA[编辑]

有许多Java语言的通讯栈，类似.NET，Java语言的通讯栈分为三种：

  1. 用Java本地接口封装完整的ANSI C通讯栈，这样不利于可携性。虽然通讯栈可以移殖到不同的作业系统，但需要个别的编辑这些程式。而且资料也需要复制到Java本地接口的边界，不过在反序列化时会有C语言的效能。
  2. 直接撰写网路层的代码（类似目前.Net的实现），用Java进行反序列化，省去了一次的资料复制，但仍会受到C堆叠的影响。
  3. 撰写原生的Java OPC UA通讯栈，这个是可携性最好的，但是工程师需花费的心力也是最多的。Eclipse Milo专案提供一个纯Java开源OPC UA实现，是依照UA 1.03客户及伺服器规范[6]。

也有一些简单的变体只支援WebService协定，此情形下，需要有可以支援WS-Security的SOAP Toolkit。

Python下的OPC UA[编辑]

FreeOpcUa（页面存档备份，存于互联网档案馆）专案提供了以Python程式语言实现的OPC UA（和Python 2, 3 及pypy相容），也提供了OPC-UA客户及伺服器的高层次抽象化，可以用在客户的应用中，或是渐渐延伸到客户的应用。

IEC 62541[编辑]

IEC 62541是OPC UA的标准

IEC 62541简介
ID发布日期标题
IEC/TR 62541-1 02/2010 OPC Unified Architecture - Part 1: Overview and Concepts
IEC/TR 62541-2 02/2010 OPC Unified Architecture - Part 2: Security Model
IEC 62541-3 07/2010 OPC Unified Architecture - Part 3: Address Space Model
IEC 62541-4 10/2011 OPC Unified Architecture - Part 4: Services
IEC 62541-5 10/2011 OPC Unified Architecture - Part 5: Information Model
IEC 62541-6 10/2011 OPC Unified Architecture - Part 6: Mappings
IEC 62541-7 07/2012 OPC Unified Architecture - Part 7: Profiles
IEC 62541-8 10/2011 OPC Unified Architecture - Part 8: Data Access
IEC 62541-9 07/2012 OPC Unified Architecture - Part 9: Alarms and Conditions
IEC 62541-10 07/2012 OPC Unified Architecture - Part 10: Programs

相关条目[编辑]

脚注[编辑]

  1. ^ Mahnke, Wolfgang; Leitner, Stefan-Helmut https://library.e.abb.com/public/75d70c47268d78bfc125762d00481f78/56-61%203M903_ENG72dpi.pdf （页面存档备份，存于互联网档案馆） OPC Unified Architecture - The future standard for communication and information modeling in automation], 3/2009 ABB Review 3/2009, page 56-61 （页面存档备份，存于互联网档案馆）
  2. ^ The world's smallest OPC-UA server comes from Germany. [2018-01-09]. （原始内容存档于2018-01-09）.
  3. ^ Leitner, Stefan-Helmut; Mahnke, Wolfgang OPC UA – Service-oriented Architecture for Industrial Applications （页面存档备份，存于互联网档案馆）, 11/2006 Softwaretechnik-Trends （页面存档备份，存于互联网档案馆） ISSN 0720-8928
  4. ^ Massaro, Simone What is OPC UA and how does it affect your world? （页面存档备份，存于互联网档案馆）, 5/15/2008 planetengineering.com （页面存档备份，存于互联网档案馆）
  5. ^ ASNeG – open source OPC UA Application Server. [2015-09-11]. （原始内容存档于2015-10-02）.
  6. ^ OPC Unified Architecture (UA) client and/or server functionality in any JVM-based project. [22 Aug 2016]. （原始内容存档于2018-03-01）.

 

posted on 2023-06-29 16:52  不及格的程序员-八神  阅读(72)  评论(0)  编辑  收藏  举报
Powered by:
博客园
Copyright © 2024 不及格的程序员-八神
Powered by .NET 8.0 on Kubernetes