OPC DA 2.05a定制接口规范：无缝协作开发指南

5星 · 超过95%的资源需积分: 50 36 浏览量更新于2024-07-31 收藏 675KB PDF 举报

OPC (Open Platform Communications) 是一种工业标准，旨在促进不同厂商的自动化系统之间的互操作性。OPC Data Access (DA) 规范是OPC体系结构中的一个重要组成部分，特别是OPC DA 2.05a Specification，它于2002年6月发布。这份文档是OPC Foundation（一个非盈利组织）制定的，主要针对OPC数据访问客户端和服务器的开发者，提供了一套详细的接口规格，以促进兼容性和无缝集成。该规范的核心内容包括了一个定制接口（Custom Interface Specification），它是OPC DA 2.04版本基础上的升级，旨在简化开发者的工作流程，确保不同厂商的产品能够按照统一的标准进行交互。它定义了服务器和客户端之间的通信协议、数据模型和数据交换方式，着重于数据访问功能，如历史数据的存储、实时数据的推送和订阅等。 OPC DA 2.05a Specification规定了运行环境的要求，必须在Windows 95或更高版本，如Windows NT 4.0或其后续版本上运行。它强调了非独家许可协议，这意味着任何开发者都可以遵循这一规范来创建自己的OPC DA客户端或服务器产品，只要遵守相关的商标使用规定，并尊重版权。通过学习和遵循OPC DA 2.05a Specification，开发者可以提高他们的产品兼容性，使得不同厂商的OPC DA解决方案能够在同一个平台上无缝协作，这对于工业自动化和物联网(IoT)应用至关重要。这份规范有助于降低技术门槛，提高整体行业的效率和标准化水平。 OPC DA 2.05a Specification是OPC开发者必备的学习资料，它详细规定了如何设计和实现一个通用的数据访问接口，以便在各种复杂的工业环境中实现高效、可靠的数据交换。了解和掌握这一规范对于构建高效、可扩展的工业自动化解决方案具有重要意义。

OPC Data Access Custom Interface Specification 2.05

2.4 Overview of the Objects and Interfaces

The OPC Server object provides a way to access (read/write) or communicate to a set of data sources..

The types of sources available are a function of the server implementation.

An OPC client connects to an OPC server and communicates to the OPC server through the interfaces.

The OPC server object provides functionality to an OPC client to create and manipulate OPC group

objects. These groups allow clients to organize the data they want to access. A group can be activated

and deactivated as a unit. A group also provides a way for the client to ‘subscribe’ to the list of items so

that it can be notified when they change.

Note: All COM objects are accessed through Interfaces. The client sees only the interfaces. Thus, the

objects described here are ‘logical’ representations which may not have anything to do with the actual

internal implementation of the server. The following figure is a summary of the OPC Objects and their

interfaces. Note that some of the interfaces are Optional (as indicated by [ ]).

IUnknown

IOPCCommon

IOPCServer

[IOPCServerPublicGroups]

[IOPCBrowseServerAddressSpace]

[IPersistFile]

Standard

OPC Server

Object

IConnectionPointContainer

Figure 2-7 - Standard OPC Server Object

OPC Data Access Custom Interface Specification 2.05

It is expected that this server address space is stable and is managed within the server. The clients will

define and manage the relatively small lists of items called ‘groups’ as needed from time to time. The

interfaces described here provide the client the ability to easily define, manage, and recreate these lists as

needed through the use of ‘OPCGroups’. The clients direct the server to create, manage and delete

these groups on their behalf (persistence of the groups is the responsibility of the client application).

Although it is possible, with the usage of public groups, that the server could provide persistent storage

of these type of groups, or treat them as server defined groups.

2.6 Application Level Server and Network Node Selection

OPC Data Access supports the concept of organizing client requests into groups within a server. Such

groups can contain requests for data from only one particular OPC Server object. In order to access

data, a client application will need to specify the following:

•

The name of the OPC Data Access Server (for use by CoCreateInstance, CoCreateInstanceEx,

etc.)

•

The name of the machine hosting the OPC Data Access Server (for use by

CoCreateInstanceEx)

•

The vendor specific OPC Item Definition (the name of the specific data item in the server’s

address space)

It is beyond the scope of this specification to discuss the implications of this on the architecture and

user interface of the client program.

2.7 Synchronization and Serialization Issues

By ‘synchronization’ we mean the ability of a client to read or write values and attributes in a single

transaction. For example, most applications want to insure that the value, quality and time stamp

attributes of a particular item are in ‘sync’. Also, a reporting package might want to insure that a

group of several values read together as part of a ‘Batch Report’ are in fact part of the same batch.

Finally, a recipe download package would want to insure that all of the values in the group were sent

together and that the recipe was not started until all of the values had been received. These are just a

few examples where synchronization is important.

The short answer is that OPC itself cannot insure that all of these synchronization tasks can be

accomplished. Additional handshaking and flag passing between the client application and the device

server to signal such states as ‘ready’ and ‘complete’ will be required. There are also things that need

to be specified about the behavior of OPC servers to assure that OPC does not prevent

this sort of

synchronization from being done.

It will be seen later that OPC allows explicit reads and writes of groups of items or of individual items

as well as exception based data connections (OnDataChange). Without jumping ahead too far it is

possible to make some general observations about these issues and about server behavior.

1. In general, OPC Servers should try to preserve synchronization of data items and attributes that are

read or written in a single operation. Synchronization of items read or written individually in

separate operations is not required. Clearly, data read from different physical devices is difficult

to synchronize.

2. Reads and writes of data items which can be accessed by more than one thread must be

implemented to be thread safe, to the extent that data synchronization is preserved as specified in

this specification. Examples of where this is important might include: logic within a server where

one thread services method executions while a separate thread performs the physical

communications and writes the received data into a buffer area which is shared with the first

thread. Another example might be the logic in a handler or proxy where a ‘hidden’ RPC thread

servicing an OnDataChange subscription is writing data into a shared buffer which a thread in the

client might be reading.

OPC Data Access Custom Interface Specification 2.05

3. Threading issues are always important but this is especially true on SMP systems.

By ‘Serialization’ we mean the ability of the client to control the order in which writes are performed.

1. It is STRONGLY RECOMMENDED that write requests to the same device be handled ‘in-order’

by any server implementation. For example, an application might use a ‘recipe download

complete’ flag which is set by the application after the individual recipe items are sent. In this

case, the data must be transmitted to the physical device in the same order it was output to insure

that the ‘complete’ flag is not set before all the data has actually arrived. Where the server buffers

the outgoing data and implements a separate communications manager thread to send these

outputs to the physical device (as is often the case), the server implementation must take extra care

to insure that the order of the outputs is preserved.

2. Where a client can both read values explicitly or receive updates via a callback attention must be

given to defining exactly when a callback will or will not occur. This is discussed in more detail

later.

Many of these issues will be clarified in the detailed descriptions of the methods below.

2.8 Public (aka shared) Groups

The purpose of the public group concept is to provide a way to share data configuration information

across multiple client applications. Typically, in process control systems, multiple client applications are

configured to monitor or control the same process control data using the same applications or tools. A

public group can be created, such that only one application / end-user defines the items, and other client

applications access the information in the public group by connecting to it. This facilitates keeping the

definitions of the same data in sync, since only one client has to create and configure the attributes of

the data items.

Because the information is shared across multiple clients, some restrictions may be required to make

sure that the configuration information across multiple clients remains consistent.

2.9 Persistent Storage Story

OPC Servers may implement an optional interface to facilitate OPC clients telling an OPC server to

persistent (store) the OPC server configuration information. OPC Server configuration information

may include information about the devices and data source necessary to facilitate communication

between the data source and the OPC server. Client configuration information, including the groups

and items, are not persistently stored by an opc server.

Clients are responsible for the configuration and persistent storage of the groups and items that are

required by their application..

剩余195页未读，继续阅读

jasonh001

粉丝: 0
资源: 1

OPC DA 2.05a定制接口规范：无缝协作开发指南

OPC Data Access Custom Interface Specification 2.05

最全的opc官方文件

c++builder OPC client sample

OPC DA 2.05a Specificatio

OPCDA2.05aSpecification.rar_OPC客户端_opc_opcda协议_opc接口程序

OPC规范 （英文版）

opcda205_cust.doc

OPC技术资料

OPC技术介绍客户端VC源码(全)

OPC DA 2.0开发接口规范详解

最新资源

OPC规范（英文版）