OPC XML-DA 1.01官方规范：跨平台Web服务接口详解

PDF文件

下载需积分: 10 | 3.64MB | 更新于2024-07-15 | 71 浏览量 | 4 评论 | 举报收藏

立即下载

"OPC XML-DA 1.01 Specification.pdf" 是OPC（开放平台通信）基金会发布的官方文档，该版本针对的是OPC XML-DA接口标准，这是一种基于Web服务的技术，旨在促进跨平台通信和互联网应用中的数据访问和交换。这份文档是专为开发者设计的，详细规定了XML-DA服务器应提供的服务以及XML-DA客户端如何使用这些服务，以便实现不同供应商之间的无缝集成。在1.01版中，该文档提供了清晰的概述，包括了规格的发布日期（2004年12月18日），版本信息，以及文档的格式（Microsoft Word）。作者为OPC基金会，强调了其作为行业标准规格的地位，这意味着它遵循了统一的标准和最佳实践，确保了所有符合规范的服务器和客户端能够协同工作。文档要求的运行环境基础是能够解析XML消息和支持大整数（64位）和浮点数（64位）操作的系统。实际上，虽然64位操作系统的支持更符合现代需求，但考虑到兼容性，建议的运行环境通常是32位操作系统，但这并不排除对64位支持的未来趋势。 OPC XML-DA标准的核心内容可能包括数据访问服务（Data Access Services）的定义，如历史数据访问、实时数据订阅、数据质量和安全机制等。此外，文档还可能涵盖服务接口的细节，如URI结构、HTTP或HTTPS协议的使用、XML消息格式，以及错误处理和异常管理等。通过学习这份文档，开发者可以了解如何设计和实现支持OPC XML-DA规范的服务器，以便与各种客户端集成，如工业自动化控制系统、SCADA（ Supervisory Control and Data Acquisition）系统，或者云端的数据分析平台。同时，对于客户端开发者来说，这是理解和利用OPC XML-DA进行设备监控、远程控制或数据分析的关键参考资源。 OPC XML-DA 1.01 Specification.pdf 是一个重要的工具，对于想要进入或扩展到OPC技术领域的人员来说，深入研究并遵循这个标准将极大地提升系统的互操作性和数据交换效率。

OPC XML-DA Specification

(Version 1.01)

F O U N D A T I O N

Released

•

A subscription contract will be considered abandoned if the client application fails to issue

SubscriptionPolledRefresh calls. The server is free to terminate the subscription any time after the

period specified by SubscriptionPingRate has elapsed since the last response to a refresh service call.

A server is free to return from the SubscriptionPolledRefresh call sooner than the requested

“Holdtime” in the case an error has occurred that needs to be reported back to the client.

A client application electing to make use of the simulated callback polling service outlined here must

take into account the extended time period during which it will be waiting on the server to respond.

Either asynchronous subscription refresh calls should be made or a dedicated refresh polling thread

should be used.

2.5.3 Data Management Optimization

By subscribing to data items the client identifies to the server that it is interested in those specific data

items. By entering into this loose contract with the server via the Subscribe service the client may

provide the server with suggestions on the time and data change characteristics of the data of interest.

These suggestions are meant to further optimize the relationship between client and server and the

server’s ability to manage its data. The suggestions are provided via the attributes:

RequestedSamplingRate

EnableBuffering

DeadBand

These attributes may or may not be useful to the server depending on how the server maintains the data

that is within its domain.

A typical scenario is a server which front ends some device, and is only able to periodically poll the

device to update the server’s data cache. The server may be limited by the device as to the periodicity

of the data polling: the fastest practical rate, the specific periods, and the total bandwidth of polling

requests. The server may arbitrarily balance these constraints, or it might be responsive to client

suggestions.

The client may specify a RequestedSamplingRate at the List level (described later in document) which

indicates the fastest rate at which the server should poll the underlying device for data changes.

Polling at rates faster than this rate is acceptable, but not necessary to meet the needs of the client. The

client may also specify 0 for RequestedSamplingRate which indicates that the server should use the

fastest practical rate.

How the server deals with the sampling rate and how often it actually polls the hardware internally is a

server implementation detail.

The client may also specify a RequestedSamplingRate at the Item level (described later in document).

By specifying a RequestedSamplingRate different than List level RequestedSamplingRate the client is

requesting that the server override the List level SamplingRate for purposes as the suggestion for the

server’s underlying device poll rate.

In many cases the RequestedSamplingRate(s) are giving the Server an indication of the fastest that a

client will be submitting SubscriptionPolledRefresh requests. The RevisedSamplingRate is in return

giving the client an indication of the fastest that a client should be submitting

SubscriptionPolledRefresh requests.

By specifying EnableBuffering = True, the server will save all value changes detected at the specified

rate in a buffer for return to the client at the next SubscriptionPolledRefresh request.

OPC XML-DA Specification

(Version 1.01)

F O U N D A T I O N

Released

The following table indicates the expected behavior for a server that front ends a device, which must

be polled for data and is able to respond to the client’s requests. The attributes SamplingRate (List),

and SamplingRate (Item) in the table represent the values requested by the client, and may not be

exactly equivalent to those that are returned by the server as “Revised” values. The client is describing

the desired behavior via the requested attributes. The server will attempt to honor the client’s desired

behavior.

SamplingRa

te (List)

SamplingRate

(Item)

Values Expected behavior

Missing Missing LCV Server will attempt to poll underlying device at some

server default rate and return the most accurate data

available.

(Fastest)

Missing LCV Server will attempt to poll underlying device at fastest

practical rate and return the most accurate data

available.

> 0 Missing LCV Server will attempt to poll underlying device at the

List level SamplingRate and return the most accurate

data available.

N/A 0

(Fastest)

LCV Server will attempt to poll underlying device at fastest

practical rate and return the most accurate data

available.

N/A > 0 LCV Server will attempt to poll underlying device at the

Item level SamplingRate and return the most accurate

data available.

Note:

LCV=Latest Changed Value

N/A=Not Applicable

As an example: RequestedSamplingRate=500 msec. The server can only support 1 second update

rates, so it returns RevisedSamplingRate=1 second.

In all cases above, if EnableBuffering is True, then the server will poll the underlying device at the

SamplingRate and return to the client all (or as many as resources allow) changed values (i.e., Latest

Changed Value and any buffered values) from the last SubscriptionPolledRefresh request. Although

the server may be sampling at a faster rate than the SamplingRate to support other clients, the client

should only expect values at the negotiated SamplingRate.

OPC XML-DA Specification

(Version 1.01)

F O U N D A T I O N

Released

The following table uses some pseudo VB code to describe the behavior of the server in responding to

“Requested” SamplingRate at the List (RqtSR-List) and Item (RqtSR-Item) level for polling type data.

If RqtSR-List Missing and RqtSR-Item Missing Then

RevisedSamplingRate-List = Minimum (Fastest Supported Item Sampling Rates) or Default

RevisedSamplingRate-Item = Minimum (Fastest Supported Item Sampling Rate) or Default

EndIf

If RqtSR-List > Minimum (Fastest Supported Item Sampling Rates) Then

RevisedSamplingRate-List = RqtSR-List

Else

RevisedSamplingRate-List = Minimum (Fastest Supported Item Sampling Rates)

EndIf

If RqtSR-Item Missing and RqtSR-List NOT Missing Then

RqtSR-Item = RqtSR-List

EndIf

If RqtSR-Item > Fastest Supported Item Sampling Rate Then

RevisedSamplingRate- Item = RqtSR- Item

Else

RevisedSamplingRate-Item = Fastest Supported Item Sampling Rate

EndIf

The server may be supporting data which is collected based on a sampling model, or generated based

on an exception based model. The Fastest Supported Item Sampling Rate may be equal to 0 which

indicates that the data item is exception based versus being sampled at some period. If the client

passes in a 0 for Requested SamplingRate, then the server may respond with either 0 or some value

which represents the fastest practical rate that would be of interest to the client. The client may use the

RevisedSamplingRate values as a hint for how often to initiate a SubscriptionPolledRefresh request.

Not all value changes are guaranteed to be returned if the client passes in Requested SamplingRate > 0,

and the data is exception based.

DeadBand specifies the percentage of full engineering unit range of an item’s value that must change

prior to the value being of interest to the client. “Uninteresting” value changes are those which are less

than the Deadband and are not maintained or saved by the server for return to the client in a

SubscriptionPolledRefresh as described below.

2.5.4 Buffered Data

As mentioned above, if EnableBuffering = True the server maintains a buffer of the changed values

detected in between SubscriptionPolledRefresh requests in addition to the cached value for an item.

The server may then return more than 1 value to a client for a buffered item in a

SubscriptionPolledRefreshResponse.

When buffering is OFF the server must deliver at most 1 value per item per

SubscriptionPolledRefreshResponse and that will be the latest value obtained (LCV). Where buffering

is ON the server may return the maximum number of values as determined by the associated sampling

OPC XML-DA Specification

(Version 1.01)

F O U N D A T I O N

Released

rate. The expected behavior for servers is that they deliver values in which the interval between

timestamps is as close to the SamplingRate as possible and where any missing values are the result of

deadband logic. The server may deliver fewer values than dictated by the sampling rate based on

EnableBuffering, Deadband and implementation constraints. The server will neither buffer nor deliver

values for a particular item if there have not been any changes related to that item in between the

SubscriptionPolledRefresh requests, except and only if ReturnAllItems is True.

Because the server may need to buffer an unknown amount of data, the server is allowed to constrain

the buffer to a fixed maximum amount of data. If the server determines that its maximum buffer

capacity has been reached, then it will push out the older data, keeping the newest data in the buffer.

The server is expected to maintain at least the most current value (LCV) for each item that it is

tracking, i.e., its cache value.

The following is an example of a server receiving changed values for Items 1-4, and how it would keep

these values in its data cache, and its data buffer. The notation used for the values are:

Item, Timestamp, (Value index), Buffer/Cache.

Item 1, 00:01, (1), Buffer

Item 1, 00:02, (2), Buffer

Item 4, 00:01, (3), Cache

Item 2, 00:01, (4), Buffer

Item 1, 00:03, (5), Buffer

Item 2, 00:02, (6), Buffer

Item 1, 00:04, (7), Cache

Item 2, 00:03, (8), Buffer

Item 2, 00:04, (9), Cache

Item 3, 00:03, (10), Cache

If the buffer can only hold 6, and the following items come in

Item 3, 00:04, (11)

Item 3, 00:05, (12)

Item 3, 00:06, (13)

The Server would flush (1), (2), and (4). The Server would maintain (3) because it is the latest

changed (cache) value for Item 4.

The server is required to return values for any particular item in chronological order. Values from

different items may be interspersed but values for any specific item must be ordered by time for that

item. There is no requirement for values from different items to be in any order. The values which are

returned will always return at least the current value for a changed item. A sequence of values which

would meet these requirements are that all of the buffered items are returned followed by the most

current items which have changed in the period since the last polled refresh. The example presented

could return:

Item 1, 00:03, (5), Buffer

Item 2, 00:02, (6), Buffer

Item 2, 00:03, (8), Buffer

Item 3, 00:03, (10), Buffer

OPC XML-DA Specification

(Version 1.01)

F O U N D A T I O N

Released

Item 3, 00:04, (11), Buffer

Item 3, 00:05, (12), Buffer

Item 1, 00:04, (7), Cache

Item 2, 00:04, (9), Cache

Item 3, 00:06, (13), Cache

Item 4, 00:01, (3), Cache

Buffering of data may result in unexpected behavior when using a deadband limit and the server

encounters a resource limitation on the number of values that can be maintained. It is realistically

possible that multiple samples of a value exceed the item’s deadband limit, and the server thus buffers

one or more of these samples. It is also then possible that all of the samples that were buffered are

flushed out due to memory limitations. The current value could be either identical to the previous

value sent to the client or within the deadband limit. The client will thus get the current value which

does not exceed the deadband limit of the previous value it received, but will not get the transient

buffered values.

Refer to the OPC DA Custom Specification for additional details on this topic.

2.5.5 Timestamps

The servers will provide the most accurate timestamp to associate with a value(s). The Timestamp

should indicate the time that the value and quality was obtained by the device (if this is available) or

the time the server updated or validated the value and quality in its CACHE.

If the Item Value is an array, then there is a single Timestamp which will be associated with all array

elements. The server is responsible for determining/returning the most accurate timestamp.

Note that if a device or server is checking a value every 10 seconds then the expected behavior would

be that the timestamp of that value would be updated every 10 seconds (even if the value is not

actually changing). Thus the time stamp reflects the time at which the server knew the corresponding

value was accurate.

For SubscriptionPolledRefresh requests the changing exception based data will exhibit a Timestamp

which will correspond to the time that the value changed, and not likely correspond with any requested

sampling rate period. The caveat for this behavior is when the client has specified ReturnAllItems =

True. For those items which the value has not changed, the server will include the last exception

generated value, but use the current Timestamp. This behavior is identical to that expected if a Read

had been done for those non changed items at that time.

The following tables present examples of the associated Timestamp for sampled, and exception based

values. The behavior of a Read is included as a comparison.

剩余105页未读，继续阅读

资源评论

ali-12

2025.08.19

这份文档是学习OPC XML-DA的重要资料。

Mrs.Wong

2025.07.16

面向跨平台和互联网应用的开发者。

泡泡SOHO

2025.05.13

适合初学者和专业人士查阅。

张博士-体态康复

2025.03.05

OPC XML-DA规范的权威英文版。🎊

cathyyokou

粉丝: 0

OPC XML-DA 1.01官方规范：跨平台Web服务接口详解

OPC资料大全-1

OPC HDA 1.20 Specification.pdf

OPC XMLDA 1.01 规范：OPC开发指南

OPC DX 1.00 Specification.pdf

OPC UA 1.03 Specification.zip

OPC_XMLDA_1.01_Specification_opc_opcclient_

OPC和DCOM配置.pdf

OPC应用程序入门.pdf

OPC通讯配置详解.pdf

opc接口技术说明.pdf

OPC技术及其应用.pdf

OPC通讯协议介绍.pdf

OPC DCOM 问题处理.pdf

OPC UA For Devices 1.00 Companion Specification.pdf

opc-da-3-specification.pdf

OPC基金会与OPC统一架构—.pdf

ABB以太网OPC中文版定义.pdf

远程访问OPC服务器设置汇编.pdf

win7_OPC访问 DCOM配置.pdf

cybrid-api-organization-java-v0.123.564-sources.jar

最新资源