OPC DA 3.0 接口规范详解

4星 · 超过85%的资源需积分: 45 124 浏览量更新于2024-07-26 1 收藏 6.97MB PDF 举报

"OPC DA 3.0 说明文档是关于OPC Data Access Custom Interface的3.0版本标准，由OPC Foundation于2003年3月4日发布。此规范定义了OPC Data Access客户端和服务器开发者的接口，旨在促进多个供应商之间的无缝协作，实现互操作性。该文档适用于Windows 95或更高版本的操作系统环境。" OPC DA（OPC Data Access）是OPC（OLE for Process Control）标准的一个重要组成部分，主要用于工业自动化领域，提供数据访问接口，使不同的硬件和软件系统能够有效地交换过程控制数据。OPC DA 3.0是这个标准的一个更新版本，它改进了之前版本的功能，并提供了更好的兼容性和性能。在OPC DA 3.0中，主要的知识点包括： 1. **接口规范**：OPC DA 3.0规范详细定义了客户端和服务器之间交互的接口，这包括了数据读取、写入、订阅和事件处理等操作的API。开发者可以根据这些接口来构建自己的OPC服务器或客户端应用。 2. **互操作性**：规范的主要目标之一是确保不同供应商的OPC服务器和客户端能无缝协同工作。这意味着无论选择哪个供应商的产品，用户都可以期待一致的数据访问和通信体验。 3. **设计过程**：OPC DA 3.0是经过分析和设计流程得出的标准，这个过程考虑了工业自动化领域的实际需求，以确保标准的实用性和广泛适用性。 4. **操作系统支持**：该规范要求的运行环境为Windows 95或更高版本的Windows NT操作系统，这表明OPC DA 3.0主要面向微软的Windows平台。 5. **版权和许可证**：文档提到了非排他性许可协议，这意味着OPC Foundation允许开发者和用户按照特定条件使用和分发OPC DA 3.0的规范。 6. **商标声明**：尽管没有列出所有商标，但文档强调大多数计算机和软件品牌都有其商标，这意味着在实现OPC DA 3.0时需要尊重并遵守相关的知识产权规则。 7. **开发和应用**：对于开发者而言，理解OPC DA 3.0规范意味着能够创建符合标准的OPC服务器，提供稳定的数据访问服务；对于用户来说，意味着他们可以选择多样的OPC客户端，与各种自动化设备进行高效的数据交互。通过遵循OPC DA 3.0规范，开发者可以确保他们的软件产品能够与其他OPC兼容产品顺利集成，从而在自动化领域实现更广泛的系统集成和数据交换。同时，这也促进了工业自动化行业的标准化进程，降低了系统集成的复杂性和成本。

OPC Data Access Custom Interface

Specification Version 3.0

F O U N D A T I O N

Released

IUnknown

IOPCGroupStateMgt

IOPCItemMgt

IOPCGroupStateMgt2

IOPCSyncIO

IOPCSyncIO2

IOPCAsyncIO2

IOPCAsyncIO3

IOPCItemDeadBandMgt

[IOPCItemSamplingMgt]

Standard

OPC Group

Object

Figure 2-8 - Standard OPC Group Object

2.6 The Address Space and Configuration of the Server

This release of the OPC specification assumes that a server configuration address space may be

managed and persistently stored using the IPersistFile interface. Only the server specific information

is persistently stored. All client configuration information (Group and Item Definitions) must be

persistently stored by the respective client application. All Handles that are defined in the system are

not guaranteed to have the same value between sessions of the client and server conversation.

It is important to distinguish the address space of the server (also known as the server configuration)

from the small subsets of this space that a particular client may be interested in at a particular time

(also known as the ‘groups’ and ‘items’). The details of how these client specific groups are

maintained are discussed in detail in this specification. The persistent storage of groups is the

responsibility of the respective clients. The details of how the server address space is defined and

configured are intentionally left unspecified. For example the server address space might be:

• Entirely fixed (e.g. for a dedicated interface to a particular device such as a scale).

• Configured entirely outside of the OPC environment (e.g. for an interface to an

existing external DCS system).

• Automatically configured at startup by an ‘intelligent’ server which can poll the

existing system for installed hardware or interfaces.

• Automatically configured on the fly by an ‘intelligent’ server based on the names of

the data items the client applications are currently requesting.

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

OPC Data Access Custom Interface

Specification Version 3.0

F O U N D A T I O N

Released

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).

2.7 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.8 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.

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.

剩余198页未读，继续阅读

爱凯特的威廉

粉丝: 11
资源: 28

OPC DA 3.0 接口规范详解

EasyOPC开发包的使用手册

解决OPCDAAuto.dll注册失败解决办法.zip

OPCdaauto3.0用户手册

opc DA 3.0

OPC DA 3.0

OPC Da 3.0 Specifiacation

OPC DA 3.0 英文原版

opcDa3.0.pdf

OPC_DA_3.0官方文档

如何在Windows NT环境下，根据OPC DA 3.0接口规范，开发一个具有数据读写和事件订阅功能的OPC服务器客户端应用？

最新资源