I’ve been getting positive feedback on this posting series both on-line and off, so I’ll continue on.

4.3 OPCSERVER OBJECT     Page 28

Blogger Note:  Now we are hitting the nitty gritty stuff of OPC server implementation.  These sections outline object interfaces, parameter types, return codes and other programming fun.   Since the focus of these blog posts are to answer the question “Why would I use OPC?” (not how would I…) my commentary will deal with what and why of things are done.

4.3.1 Overview     Page 28

The OPCServer object is the primary object a server exposes.  It manages other objects used for data management, discovery and access.

4.3.2 IUnknown     Page 29

Microsoft says you gotta have one.

4.3.3 IOPCCommon     Page 29

So called because handles common functionality shared among various OPC specifications like OPC A&E, HDA, etc.    Deals with stuff like localization and error strings.

4.3.4 IOPCServer     Page 30

The main object.  Compliance says this must be provided, and all functions implemented as specified.

4.3.4.1 IOPCServer::AddGroup     Page 30

As you would guess by the name, lets clients add groups.   Groups are the logical mechanism that  OPC clients organize and manipulate data collection for multiple related data items.  Some key facts on Groups.

1.  Groups are private to a client, and are identified by a unique name.  That is Client A can not add two groups of the name MyGroup, but both clients Client A and Client B could create groups of that name.

2.  Items of the same group have the same Update Rate, Deadband and Localization.

3.  If a server cannot meet the update rate requested by the client, it is permissible for the server to return a revised update rate.   During operation it is allowed for a server to return data slower than the requested rate, due to network or system slowdowns.  However it is not allowed for a server to return data to the client faster than the set update rate.

4.  Group management is the responsibility of the client.  A server should not remove a group until requested by the server.  Of course a server can release interfaces if higher level interfaces are released, such as during shutdown.  Well behaved OPC clients will properly clean up when disconnecting.

4.3.4.2 IOPCServer::GetErrorString.     Page 33

As it says, it handles error strings.  Stuff like memory handling and localization.

4.3.4.3 IOPCServer::GetGroupByName     Page 34

Although given a unique human readable name, servers and clients use interface handles when dealing with groups.  This function allows a client to re-establish previous connections based the group names.

4.3.4.4 IOPCServer::GetStatus     Page 35

Returns OPC Server Status information.   Before the KeepAlive mechanism was introduced in DA 3.0, repeatedly calling this interface was a common way for clients to determine a server was connected and available.

4.3.4.5 IOPCServer::RemoveGroup     Page 36

Groups are not truly deleted until the client calls the RemoveGroup interface.   This allows for a client to reconnect using the GetGroupByName method even if all interfaces had been previously released by the server.   Well behaved clients would complete any outstanding synchronous data operations or asynchronousds callbacks before calling this interface.

4.3.4.6 IOPCServer::CreateGroupEnumerator     Page 38

Deals with enumerating groups.  Version 1.0 of the DA specification described slightly different behavior for enumerating connected vs non-connected groups, that has since been found to be difficult or impossible to implement in practice.   Yet another reason to ensure your OPC vendor is keeping pace with the OPC specifications.

4.3.5 IConnectionPointContainer (on OPCServer)     Page 40

This interface provides access to the connection point for IOPCShutdown.  Rules of engagement outlined by Microsoft.

4.3.5.1 IConnectionPointContainer::EnumConnectionPoints     Page 41

OPCServers must return an enumerator that includes IOPCShutdown. Additional vendor specific callbacks are also allowed.

4.3.5.2 IConnectionPointContainer:: FindConnectionPoint     Page 42

Find a particular connection point between the OPC Server and the Client.  Never know when a client will need to do something like this.

4.3.6 IOPCBrowse     Page 43

All shiny and new with OPC DA 3.0.   It duplicates, yet simplifies and enhances the behavior of the DA 2.0 BrowseServerAddressSpace interface.  This interface mirrors the behavior of the OPC XML-DA specification and the behaviour that migrated on to OPC UA.

4.3.6.1 IOPCBrowse:: Browse     Page 43

This interface simplifies the FLAT and HIERARCHICAL address space models.  It also provides functionality to directly browse Item properties (instead of using a separate interface) and better handle very large address spaces.  Clients can now more easily determine address spaces with items, branches or null sets without having to recursively browse levels.

4.3.6.2 IOPCBrowse::GetProperties     Page 46

As I said DA 3.0 Browsing lets clients directly access Property information.

4.3.7 IOPCItemIO     Page 48

Another key addition in DA 3.0, direct Item support.  In OPC DA 1.0 and 2.x, before a client could read/write any data, it had to first create a group.  This interface provides a simple way for applications to obtain OPC data, however programmers should be aware that in most servers the Group based OPC design will provide greatly improved performance. In terms of performance, the user of this interface should assume that it will behave as if he were to create a group, add the items, perform a single read or write and then delete the group.   A second purpose of this interface is to provide a method for writing timestamp and quality information into servers that support this functionality.   Another key addition with OPC DA 3.0

4.3.7.1 IOPCItemIO::Read     Page 48

Reads one or more values, qualities and timestamps for the items specified.  Much like a synchronous read using a single item in a group.  The interface does provide a MaxAge parameter that sets the ‘staleness’ tolerance so a server can provide some level of data access optimization.

4.3.7.2 IOPCItemIO::WriteVQT     Page 51

A major functionality addition that may applications looked for.  Before this DA 3.0 interface, OPC clients would need to rely on the OPC HDA interfaces to provide the ability to accurately write the timestamp and quality values.  Allows OPC clients to set the VT, VQ or VQT.  In practice, since this is optional behaviour, many servers still only support setting the value.   Complex guaranteed data delivery or store and forward solutions still use the OPC HDA interfaces.

Whew!   Even a high level commentary on this specification is proving to be more verbose than I expected.   Next up the Group Object.  Stay tuned.