OPC 数据存取定制接口规范3.0

2星需积分: 9 51 浏览量更新于2024-08-02 收藏 7MB PDF 举报

"OPC DA 3.0 Specification" OPC（OLE for Process Control）数据访问规范是工业自动化领域中一种标准接口，它允许不同的设备和软件之间进行数据交换。OPC DA（Data Access）3.0 版本是 OPC Foundation 推出的一种行业标准，旨在简化OPC客户端和服务器的开发，确保不同供应商的产品能够无缝协作。此规范详细定义了OPC数据访问自定义接口，这是开发OPC客户端和服务器的关键部分。它包含了开发者所需的所有信息，以便他们能够按照标准创建自己的接口，使得他们的应用程序能够与其他符合OPC DA 3.0规范的应用程序相兼容。这个接口设计过程涉及到了深入的分析和设计，以确保互操作性并降低开发复杂性。 OPC DA 3.0 规范适用于Windows 95及更高版本的Windows操作系统，如Windows NT 4.0或更新的版本。这表明该标准是为微软的桌面环境设计的，以支持在这些平台上运行的工业控制系统。此文档的发布日期为2003年3月4日，版本号为3.0，由OPC Foundation撰写并发布。文档采用Microsoft Word格式，且OPC Foundation声明了非独家许可协议，这意味着任何符合规范的开发者都可以使用这些接口设计来构建他们的产品，而无需获得特殊授权。 OPC DA 3.0规范的主要目标是提高工业自动化领域的互操作性，降低集成成本，并提供一种标准方法，使得不同厂商的硬件和软件可以共享和交换实时数据，如生产过程中的温度、压力、流量等关键指标。这一规范不仅对软件开发者至关重要，对于整个工业自动化行业的标准化和效率提升也具有重要意义。在实际应用中，OPC DA 3.0规范支持实时数据的读取和写入操作，提供了异步通信机制以适应快速响应的需求，并定义了错误处理机制，以确保在出现故障时能够正确处理。此外，还定义了数据质量和时间戳的概念，以准确记录每个数据点的状态和采集时间。 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页未读，继续阅读

yaoming1718

粉丝: 20
资源: 1

OPC 数据存取定制接口规范3.0

OPC DA 3.00 中文版PDF文档

OPCDAAuto.dll(v2.2.5.30) 测试好用的

OPCDAAuto.dll 文件,C#调用OPCDAAuto实现对kepserver读写

OPC DA 3.0

opc DA 3.0

opcDa3.0.pdf

OPC DA 3.0 英文原版

OPC DA 3.0技术标准详解

OPC DA 3.0 接口规范详解

OpcDa3.0_dll打包.zip

最新资源