There are basically three ways to get data into a client (ignoring the 'old' IDataObject/IAdviseSink).
IOPCSyncIO::Read (from cache or device)
IOPCAsyncIO2::Read (from device)
IOPCCallback::OnDataChange() (exception based) which can also be triggered by IOPCAsyncIO2::Refresh.
In general the three methods operate independently without 'side effects' on each other.

There are two ways to write data out:
IOPCSyncIO::Write
IOPCAsyncIO2::AsyncWrite

Read operations can be performed on 'CACHE' or 'DEVICE'. It is expected that most servers will implement some sort of CACHE. The actual details of the implementation of this functionality is up to the server vendor. In most cases, access to CACHE data is expected to be 'fast' while access to the 'DEVICE is expected to be 'slow' but more accurate. CACHE data is affected by the Active state of the group and the items in the group while DEVICE data is not. Note again that although we sometimes make suggestions, this specification does not dictate any particular implementation or performance.

CACHE data, DEVICE data and TimeStamps

For the most part the terms CACHE and DEVICE are treated as 'abstract' within this specification. That is, reading CACHE or DEVICE data simply affects the described behavior of various interfaces in a well defined way. The implementation details of these capabilities is not dictated by this specification.
In practice, however, it is expected that most servers will read data into some sort of CACHE. Also, most clients will read data from this cache via one of several mechanisms discussed later. Access to DEVICE data is expected to be 'slow' and is expected to be used primarily for diagnostics or for particularly critical operations.
The CACHE should reflect the latest value of the data (subject to update rate and deadband optimizations as discussed later) as well as the quality and timestamp. 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. 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.
This is also true regardless of whether the physical device to system interface is exception based. For example suppose it is known that (a) an exception based device is checking values every 0.5 second and that (b) the connection to the device is good and (c) that device sent an update for item FIC101 three minutes ago with a value of 1.234. In this case the value returned from a cache read would be 1.234 and more important, the timestamp returned for this value would be the current time (within 0.5 second) since it is known that the value for the item is in fact still 1.234 as of 0.5 seconds ago.

Asynchronous vs. Synchronous Interfaces

Assuming that most clients want to access Cached data, there are several ways for a client to obtain that data from a server.

• It can perform a synchronous read from cache (simple and reasonably efficient). This may be appropriate for fairly simple clients that are reading relatively small amounts of data and where maximum efficiency is not a concern. A client that operates in this way is essentially duplicating the 'scanning' that the server is already doing.
• It can 'subscribe' to cached data using IAdviseSink or IOPCDataCallback which is more complex but very efficient. This is the recommended behavior for clients because it will minimize use of CPU and NETWORK resources.

The ACTIVE flags, Deadband and Update Rate

These attributes of groups and items can be used to reduce resource use by clients and servers. They are discussed in more detail later under GROUPS. In general, they affect how often the cached data and quality information is updated and how often calls are made to the client's IAdviseSink or IOPCDataCallback.

Active State Behavior

The following tables summarize the expected behavior of OPC servers and OPC clients with respect to the Group and Item Active flags, Reads and Subscriptions, and CACHE and DEVICE data.

The first column (Function) is the short hand notation for the external functions that an OPC client application calls and the OPC server implements.
The Source Column is the source from which the client wants the data to be obtained (either device or cache).
The Enable Column indicates the callback enable state as set by OpcGroup.SetEnable.
The Group Column is the active state of the group.
The Item Column is the active state of the Item.
The Behavior Column is the behavior for this configuration state.

Certain Quality values are identified in the table and reflect required behavior with respect to the active state of groups and items. In all other cases, the server may return quality values as appropriate to communicate the current state of the data to the client.

Additional Notes:
Refresh is a special case of subscription, where refresh forces an OnDataChange call for all active items.
It is expected that most clients will use either Reads or Subscriptions for a particular group but not both. If both are used then there is some interaction between Reads and Subscriptions in that anything sent to the client as a result of a 'read' is also considered to be the 'last value sent'.
A transition from Inactive to Active will result in a change in quality, and will cause a subscription callback for the item or items affected. A change (in the group or item) from Active to Inactive will cause a change in quality but will not cause a callback since by definition callbacks do not occur for inactive items. That is, if you later do an explicit read (sync or async) of an inactive group or item you will get a quality indicating that the item is inactive.

Synchronous Read

Asynchronous Read

Asynchronous Refresh

OnDataChange