OPC UA

开放性，产业性，互联性，I OPC是通过开放的标准实现开放链接，由一系列的标准规范组成

OPC是一个工业标准，它定义了一个开放接口，在工业客户机和服务器之间进行数据交换

开放性：平台独立性；全能应用；完全链接

高效性：业界标准；独立于生产厂商；互操作性；可靠性

协作性：设备集成分析设备集成；智能电网；现场设备集成

OPC UA是OPC统一架构，是OPC基金会推出的新一代技术，用于实现将原始数据和预处理信息从生产厂商到 生产计划系统或ERP系统之间的安全、可靠、跨商家的数据传输。

OPC UA标准化通信的优势：

防止非法数据访问；数据安全性和可靠性；平台独立性和可扩展性

简化界面，拓展潜力，更多的应用选择，可以接入物联网和智能手机，用智能手机或是IPAD进行实时在线编程。

新一代的OPC UA统一标准在所有的平台（西门子、施耐德、三菱、NI等）上都可以实现快速、安全、灵活的通信。

OPC UA采用面向服务的技术，实现了平台独立性，使全新而经济的自动化理念得以实施。

嵌入式现场设备、过程控制系统、可编程逻辑控制器、网关和操作面板均可配置精简的OPC UA服务器方案，直接便携地与WINDOWS EMBEDDED,LINUX,VXWORKS,QNX,RTOS及其他各类操作系统连接。之前访问非WINDOWS平台设备上的数据，需特别配备一台单独WINDOWS PC作为OPC服务器，现在已经不再需要。

OPC UA组件也可在其他操作系统（如MICROSOFT WINDOWS,SOLARIS,HP-UX,AIX等）上广泛应用于ERP、IT、生产计划系统、控制软件和电子商务程序。

OPC UA组件功能具有可扩展性，从嵌入式设备的精简实施方案到整个企业范围内主机数据管理系统的完全配置均可实现。

OPC UA采用一套优化的基于TCP的统一架构二进制协议进行数据交换；同时支持网络服务（WEB SERVICES）和HTTP。在防火墙中只需打开一个端口即可。集成化的安全机制可确保在互联网上的安全通信。

OPC UA是OPC是OPC基金会推出的新一代技术，用于实现将原始数据和预处理信息从生产厂商到生产计划系统或ERP系统之间的安全、可靠、跨商家的数据传输。通过OPC UA，所有经授权的程序和个人可随时随地获取所需信息。该架构独立于程序生产厂家、编程语言和操作系统。

OPC UA具有的一些重要特性，如平台独立性、可扩展性、高可用性和互联网功能，是对现有OPC工业标准的有效补充。

OPC UA不在基于DCOM，而是建立在面向服务的架构（SOA）之上，因此可以便携地实现数据连接。

今天，OPC UA的数据交换可独立于MICROSOFT、UNIX或其他任何系统，已经成为连接企业级系统和嵌入式自动化组件之间的桥梁。

OPC UA技术的2013年深圳研讨会，我参与了！ 从PLC的通讯统一性看，OPC UA的平台紧跟网络的发展，考虑了安全性，可靠性以及通讯易用性，是一个PLC走向通讯统一平台的一个很好的方向。基于这个通用性，对于一些大的品牌，会有限支持，也有一些会全力支持。 某法国品牌在2013年开始推的全系列PLC，支持OPC UA，意味着直接通过手机等就可以实现PLC的通讯，监控。 欧系产品通讯网络，德国品牌的势力很大。日本的品牌协议研究弱一些。现在某些日本品牌支持了如Ethernet/IP、EtherCAT，也是对德国某品牌的一个联合狙击。但用户的习惯很难改变！呵呵

OPC UA 节点

OPC UA 节点定义：

public interface INode
{
    /// <summary>
    /// The node identifier.
    /// </summary>
    /// <value>The node identifier.</value>
    ExpandedNodeId NodeId
    {
        get;
    }
    /// <summary>
    /// The node class.
    /// </summary>
    /// <value>The node class.</value>
    NodeClass NodeClass
    {
        get;
    }
    /// <summary>
    /// The locale independent browse name.
    /// </summary>
    /// <value>The name of the browse.</value>
    QualifiedName BrowseName
    {
        get;
    }
    /// <summary>
    /// The localized display name.
    /// </summary>
    /// <value>The display name.</value>
    LocalizedText DisplayName
    {
        get;
    }
    /// <summary>
    /// The identifier for the TypeDefinition node.
    /// </summary>
    /// <value>The type definition identifier.</value>
    ExpandedNodeId TypeDefinitionId
    {
        get;
    }
}

NodeId 是节点的唯一编号，

BrowseName用于浏览，

DisplayName 是节点的名称，

TypeDefinitionId是类型定义的唯一编号。

Group

Each "variable" in your post (also called "tag", the actual proper OPC term would be "OPC item") represents a value in the underlying device or system. As such, the same variable, if used at multiple places, is generally expected to have the same value - that's the whole purpose of it.

OPC groups are the way the OPC client tells the OPC server which OPC items it is interested in. They exist mainly for performance reasons: All OPC items in the same OPC group share some common characteristics, such as update rate, whether they are actively updated, and so on. This way, once the group is created and items added to it, the client does not have to address each item individually and repeat the data if it wants to "do something" to the whole group (such as change the update rate, or unsubscribe all the items).

OPC clients have full freedom in how they create the OPC groups, and which items they put into them. Not only you can have the same item in multiple groups; in fact you can even have the same item multiple items in the same group (though I doubt it is useful for anything). Therefore the answer to your questions is negative, at least as far the OPC server is concerned: You cannot "isolate" the groups; if you put an item into one group, the server must (to be compliant) allow you to put it into other groups as well (remember that there may be are also other clients that create their groups, too - and they should not be influenced either).

If you were writing an OPC client, then, of course, you could impose any limitations you like to what it allows the user to do or not.

is possible to 'programatically' create variables (OPC Items) on the OPC Server? I am using OPCDA.NET

It is not possible in any standardized way through the interfaces of the OPC Data Access spec. Specific servers may have some ways to achieve it, but even then it would be relatively rare. I can recall that (I think) Kepware servers, with their driver-model, at least for register-based devices, have Item IDs that basically have pre-defined syntax, which contains the register type and register number. It is then possible to "create" the variable simply by reading/writing/subscribing to a properly-formed Item ID, without it being preconfigured. But it is done beyond/aside the OPC standard.

参见

• List of Open Source OPC UA Implementations

• OPC UA简介

• OPC UA官方文档翻译Part 1 --待续

• OPC UA官方文档翻译Part 2--待续

• open62541 is an open source C (C99) implementation of OPC UA

• When to use OPC UA Variables, Methods, Programs

Introduction to OPC UA

To reach the defined goals, the OPC Unified Architecture builds on different layers shown in the following figure

The fundamental components of OPC Unified Architecture are transport mechanisms and data modeling.

The transport defines different mechanisms optimized for different use cases. The first version of OPC UA is defining an optimized binary TCP protocol for high performance intranet communication as well as a mapping to accepted internet standards like Web Services, XML, and HTTP for firewall-friendly internet communication. Both transports are using the same message-based security model known from Web Services. The abstract communication model does not depend on a specific protocol mapping and allows adding new protocols in the future.

The data modeling defines the rules and base building blocks necessary to expose an information model with OPC UA. It defines also the entry points into the address space and base types used to build a type hierarchy. This base can be extended by information models building on top of the abstract modeling concepts. In addition, it defines some enhanced concepts like describing state machines used in different information models.

The UA Services are the interface between servers as supplier of an information model and clients as consumers of that information model. The Services are defined in an abstract manner. They are using the transport mechanisms to exchange the data between client and server.

This basic concept of OPC UA enables an OPC UA client to access the smallest pieces of data without the need to understand the whole model exposed by complex systems. OPC UA clients also understanding specific models can use more enhanced features defined for special domains and use cases. The following figure shows the different layers of information models defined by OPC, by other organizations, or by vendors.

To cover all successful features known from Classic OPC, information models for the domain of process information are defined by OPC UA on top of the base specifications. DA defines automation-data-specific extensions such as the modeling of analog or discrete data and how to expose quality of service. All other DA features are already covered by the base. Alarm & Conditions (AC) specifies an advanced model for process alarm management and condition monitoring. Historical Access (HA) defines the mechanisms to access historical data and historical events. Programs (Prog) specifies a mechanism to start, manipulate, and monitor the execution of programs.

Other organizations can built their models on top of the UA base or on top of the OPC information model, exposing their specific information via OPC UA. Examples for standards already working on mappings to OPC UA are Field Device Integration (FDI) combining Electronic Device Description Language (EDDL), and Field Device Tool (FDT) both used to describe, to configure, and to monitor devices and PLCopen, a standard for PLC programming languages.

Additional vendor-specific information models will be defined using directly the UA base, the OPC models, or other OPC-UA-based information models.

To continue the OPC introduction you can read OPC UA Specifications.

OPC首字母缩写词代表什么？

从2000年初以来，我们就一直在使用OPC软件互操作性标准，而那些正准备踏入和想要踏入工业自动化领域的人们却对这些含义感到困惑。

所以在本中，我将系统地为你梳理OPC知识。

OPC首字母缩写词代表什么？

问一个OPC老手，他们或许会笑，因为他们知道有很多含义！在经典的且程序化的说法是：O LE for P rocess C ontrol(用于过程控制的OLE)。OLE 或对象链接和嵌入是Windows的基本早期构建块，允许应用程序在它们之间共享复杂的信息。我记得Windows 3.0的第一个演示中，人们将 Excel电子表格嵌入到 Microsoft Word文档中，以及更新电子表格，打开Word和更新文档的重要性。原始OPC标准源自该技术和 COM 或 Windows 组件对象模型。 从那以后，我们会听到很多其他的一些定义，但是比较出名的是现在官方OPC基金会所给出的说法是：它的含义是O pen P latform C ommunications(开放平台通信)。其实无论它的定义是什么，其目标保持不变：消除自动化软件和硬件平台之间互操作性的障碍，为用户提供选择。

OPC质量

在 OPC 之前，当你的 HMI 或 SCADA 软件用内置驱动程序读取数据之前，它要么得到数据要么没有数据。 如果你没有得到数据，你就无法知道最后一次获得数据是什么时候。 两者之间没有差别。

使用OPC服务器，它们可以缓存或保留从设备读取的最后一个值。它们还会在缓存中为数据加时间戳(TImestamps)，通常使用OPC服务器从设备读取值的时间。某些设备存储上次更改数据的时间戳，并可使用设备特定的通信协议将其传递给OPC服务器。如果设备支持该设备并且OPC服务器支持它，那么则可以使用设备时间戳。(如：支持该功能的协议的设备时间戳的Software Toolbox产品包括TOP Server DNP，IEC 61850和IEC 60870驱动程序。)

OPC质量是OPC服务器告诉OPC客户更多关于它们提供价值的一种方式。这样做的方法是传递一个数字以及值和时间戳。在OPC中我们称之为VQT或"Value，Quality，Timestamp"(“价值，质量，时间戳”)。OPC质量编号实际上是通过设置字位来确定的，这会导致产生不同的值。值192表示“良好”质量，这意味着OPC服务器最后一次轮询设备它能够成功获取数据，因此OPC客户端可以信任该值。值为0表示质量不佳，通常表示OPC服务器与其轮询的设备之间存在通信故障。OPC服务器可以使用一系列其他值来表示质量差的原因，但目前它们并未得到广泛实施。我之前有发过一篇关于OPC数据质量的文章，感兴趣的朋友可以去看看。

其实最重要的是OPC客户端应用程序通常可以配置为更改它们在操作员屏幕或历史数据库中向用户显示值的方式，以便人们知道该值不值得信任和不值得信任原因。

参见

1. opc客户端读取数据品质是bad_听说看了这篇文章就彻底搞懂了什么是OPC（上）