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.
8
我的内容管理
展开
