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.