OPC统一架构：信息模型规范详解

需积分: 2 145 浏览量更新于2024-07-16 收藏 2.01MB PDF 举报

"OPC Unified Architecture.pdf 是 OPC Foundation 发布的关于 OPC 统一体系架构的技术规范文档，重点关注 OPC 信息模型。该文档是 Industry Standard 规范，版本为 Release 1.03，日期为2015年7月10日。内容涵盖了 OPC 统一体系架构的范围、术语定义、节点标识、浏览名称、通用属性以及标准对象类型等核心概念。" OPC Unified Architecture (OPC UA) 是一种开放的、平台无关的工业通信标准，旨在统一不同厂商和系统的数据交换。它不仅包括了OPC传统的数据访问功能，还扩展到了安全、服务导向的架构，支持基于Web服务的技术，并提供了信息模型来描述和组织系统中的数据和功能。 1. **范围**：这部分描述了 OPC UA 的整体目标和应用领域，包括如何在不同设备和系统之间进行数据交换，以及如何通过 OPC UA 实现互操作性。 2. **规范引用**：列出与 OPC UA 相关的标准和技术文档，这些参考文献构成了 OPC UA 设计的基础。 3. **术语、定义和惯例**：定义了用于描述 OPC UA 的关键术语，缩写和符号，以及描述节点时遵循的约定，确保所有开发者和用户对概念有统一的理解。 4. **节点标识和浏览名称**：节点是 OPC UA 信息模型的基本构建块，每个节点都有唯一的 NodeId 和直观的 BrowseName，用于标识和导航。 5. **通用属性**：详细介绍了节点的通用属性，如所有节点的通用属性，对象节点、变量节点和变量类型节点的特定属性。 6. **标准对象类型**：定义了一系列标准的对象类型，如 BaseObjectType、ServerType 和 ServerCapabilitiesType，这些类型提供了服务器的基本功能和能力描述，便于客户端理解和交互。 OPC UA 的信息模型是一种结构化的方法，用于组织和表示系统中的数据和功能。它允许开发者定义自定义的数据模型，以适应特定的应用场景。通过 OPC UA，不同的设备和服务可以共享复杂的信息，增强了自动化和工业4.0环境中的集成能力。此外，OPC UA 强调安全性，通过内置的安全机制保护数据传输过程，确保了工业网络的安全性。

OPC Unified Architecture, Part 5 xvi Release 1.03

Mantis

Summary

Resolution

3110

Clarification on table descriptions

Modified Table 2 clarifying that DataType is

only used for Variables, not for Objects.

3119

Clarification on should/shall in the

audit events section

In several places of the document “should”

was used when “shall” was intended. This

has been fixed.

Release 1.03 2 OPC Unified Architecture, Part 5

ClientUserId

string that identifies the user of the client requesting an action

Note 1 to entry: The ClientUserId is obtained directly or indirectly from the UserIdentityToken passed by the Client

in the ActivateSession Service call. See 6.4.3 for details.

3.2 Abbreviations and symbols

UA Unified Architecture

XML Extensible Markup Language

3.3 Conventions for Node descriptions

Node definitions are specified using tables (see Table 2).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the

TargetNode and its NodeClass.

 If the TargetNode is a component of the Node being defined in the table the Attributes

of the composed Node are defined in the same row of the table.

 The DataType is only specified for Variables; “[<number>]” indicates a single-

dimensional array, for multi-dimensional arrays the expression is repeated for each

dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions

is set as identified by <number> values. If no <number> is set, the corresponding

dimension is set to 0, indicating an unknown size. If no number is provided at all the

ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar

DataType and the ValueRank is set to the corresponding value (see Part 3). In addition,

ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension,

the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the

ValueRank is set to the corresponding value (see Part 3) and the ArrayDimensions is

set to null or is omitted. Examples are given in Table 1.

Table 1 – Examples of DataTypes

Notation

Data-

Type

Value-

Rank

Array-

Dimensions

Description

Int32

−1

omitted or null

A scalar Int32.

Int32[]

Int32

omitted or {0}

Single-dimensional array of Int32 with an

unknown size.

Int32[][]

Int32

omitted or {0,0}

Two-dimensional array of Int32 with unknown

sizes for both dimensions.

Int32[3][]

Int32

{3,0}

Two-dimensional array of Int32 with a size of 3 for

the first dimension and an unknown size for the

second dimension.

Int32[5][3]

Int32

{5,3}

Two-dimensional array of Int32 with a size of 5 for

the first dimension and a size of 3 for the second

dimension.

Int32{Any}

Int32

−2

omitted or null

An Int32 where it is unknown if it is scalar or array

with any number of dimensions.

Int32{ScalarOrOneDimension}

Int32

−3

omitted or null

An Int32 where it is either a single-dimensional

array or a scalar.

 The TypeDefinition is specified for Objects and Variables.

 The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified

Node points with a HasTypeDefinition Reference to the corresponding Node.

 The ModellingRule of the referenced component is provided by specifying the symbolic

name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use

a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the

DataType shall be used.

OPC Unified Architecture, Part 5 3 Release 1.03

Nodes of all other NodeClasses cannot be defined in the same table; therefore only the used

ReferenceType, their NodeClass and their BrowseName are specified. A reference to another

part of this document points to their definition.

Table 2 illustrates the table. If no components are provided, the DataType, TypeDefinition and

ModellingRule columns may be omitted and only a Comment column is introduced to point to

the Node definition.

Table 2 – Type Definition Table

Attribute

Value

Attribute name

Attribute value. If it is an optional Attribute that is not set “--“ will be used.

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

ReferenceType

name

NodeClass

of the

TargetNode.

BrowseName of the

target Node. If the

Reference is to be

instantiated by the

server, then the

value of the target

Node’s

BrowseName is “--“.

DataType

of the

referenced

Node, only

applicable

for

Variables.

TypeDefinition of the referenced

Node, only applicable for

Variables and Objects.

Referenced

ModellingRule of

the referenced

Object.

NOTE Notes referencing footnotes of the table content.

Components of Nodes can be complex, that is containing components by themselves. The

TypeDefinition, NodeClass, DataType and ModellingRule can be derived from the type

definitions, and the symbolic name can be created as defined in 4.1. Therefore those containing

components are not explicitly specified; they are implicitly specified by the type definitions.

4 NodeIds and BrowseNames

4.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Part 6 defines

the actual NodeIds.

The symbolic name of each Node defined in this standard is its BrowseName, or, when it is part

of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In

this case “part of” means that the whole has a HasProperty or HasComponent Reference to its

part. Since all Nodes not being part of another Node have a unique name in this standard, the

symbolic name is unique. For example, the ServerType defined in 6.3.1 has the symbolic name

“ServerType”. One of its InstanceDeclarations would be identified as

“ServerType.ServerCapabilities”. Since this Object is complex, another InstanceDeclaration of

the ServerType is “ServerType.ServerCapabilities.MinSupportedSampleRate”. The Server

Object defined in 8.3.2 is based on the ServerType and has the symbolic name “Server”.

Therefore, the instance based on the InstanceDeclaration described above has the symbolic

name “Server.ServerCapabilities.MinSupportedSampleRate”.

The NamespaceIndex for all NodeIds defined in this standard is 0. The namespace for this

NamespaceIndex is specified in Part 3.

Note that this standard not only defines concrete Nodes, but also requires that some Nodes

have to be generated, for example one for each Session running on the Server. The NodeIds

of those Nodes are server-specific, including the Namespace. However the NamespaceIndex

of those Nodes cannot be the NamespaceIndex 0, because they are not defined by the OPC

Foundation but generated by the Server.

4.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this standard is specified in the

tables defining the Nodes. The NamespaceIndex for all BrowseNames defined in this standard

is 0.

Release 1.03 4 OPC Unified Architecture, Part 5

5 Common Attributes

5.1 General

For all Nodes specified in this standard, the Attributes named in Table 3 shall be set as specified

in Table 3.

Table 3 – Common Node Attributes

Attribute

Value

DisplayName

The DisplayName is a LocalizedText. Each server shall provide the DisplayName identical to

the BrowseName of the Node for the LocaleId “en”. Whether the server provides translated

names for other LocaleIds is vendor specific.

Description

Optionally a vendor specific description is provided.

NodeClass

Shall reflect the NodeClass of the Node.

NodeId

The NodeId is described by BrowseNames as defined in 4.1 and defined in Part 6.

WriteMask

Optionally the WriteMask Attribute can be provided. If the WriteMask Attribute is provided, it

shall set all Attributes to not writable that are not said to be vendor-specific. For example, the

Description Attribute may be set to writable since a Server may provide a server-specific

description for the Node. The NodeId shall not be writable, because it is defined for each Node

in this standard.

UserWriteMask

Optionally the UserWriteMask Attribute can be provided. The same rules as for the WriteMask

Attribute apply.

5.2 Objects

For all Objects specified in this standard, the Attributes named in Table 4 shall be set as

specified in Table 4.

Table 4 – Common Object Attributes

Attribute

Value

EventNotifier

Whether the Node can be used to subscribe to Events or not is vendor specific.

5.3 Variables

For all Variables specified in this standard, the Attributes named in Table 5 shall be set as

specified in Table 5.

Table 5 – Common Variable Attributes

Attribute

Value

MinimumSamplingInterval

Optionally, a vendor-specific minimum sampling interval is provided.

AccessLevel

The access level for Variables used for type definitions is vendor-specific, for all other

Variables defined in this standard, the access level shall allow a current read; other settings

are vendor specific.

UserAccessLevel

The value for the UserAccessLevel Attribute is vendor-specific. It is assumed that all

Variables can be accessed by at least one user.

Value

For Variables used as InstanceDeclarations, the value is vendor-specific; otherwise it shall

represent the value described in the text.

ArrayDimensions

If the ValueRank does not identify an array of a specific dimension (i.e. ValueRank <= 0) the

ArrayDimensions can either be set to null or the Attribute is missing. This behaviour is

vendor-specific.

If the ValueRank specifies an array of a specific dimension (i.e. ValueRank > 0) then the

ArrayDimensions Attribute shall be specified in the table defining the Variable.

5.4 VariableTypes

For all VariableTypes specified in this standard, the Attributes named in Table 6 shall be set as

specified in Table 6.

剩余122页未读，继续阅读

故事的尛黄花

粉丝: 0
资源: 7

OPC统一架构：信息模型规范详解

OPC UA最新官网PDF文档资料（全）

OPC Unified Architecture Specification

opc.ua.client.dll 接口

csharp中Opc.Ua.ApplicationConfiguration是做什么的

tf6100-opc-ua.4.3.44.0.exe

opc.ua.client.dll

nordig-unified ver. 3.1

opc ua 统一架构 pdf

opc ua pdf

OPC UA java 代码示例

最新资源