This is the final posting on the DA Specification overview.  When I started this series, I warned you that most of the specification is geared towards what is needed to actually sit down and develop an OPC Server, and less on the how and why of using OPC.   Hopefully I was able to shed some light on those things over the last few postings.

4.5 CLIENT SIDE INTERFACES     Page 130

Blogger Note:  In terms of Compliance, there was no test for OPC clients.   The original thinking was OPC clients could implement as much or little of the specifications as they needed.   The onus was on the OPC Server to handle poorly behaving clients, and the specification only outlines the interfaces OPC Clients need to implement in order to properly handle callbacks and shutdowns  This lead to many interoperability problems.
The revamped OPC Certification process now places more requirements on OPC client development.  These include attending OPC Interoperability sessions and testing against a standardized test client the OPC Analyzer, before a client can be Certifified.

4.5.1 IOPCDataCallback     Page 130

This interface allows an OPC client to access the asynchronous functionality of an OPC server.  Only very simple or limited functionality clients would not support callbacks.  In order to be considered properly behaved, an OPC client must implement all methods on the interface.

OPC clients must also follow standard COM programming rules when dealing with memory management.   A poorly written OPC client can make it appear that an OPC server is ‘leaking’ memory.

4.5.1.1 IOPCDataCallback::OnDataChange     Page 131

Needed to access exception based data changes and Refreshs.  A client should expect to receive callbacks when the value or quality changes on an active item in an active group, but no faster than the set update rate.  Of course callbacks will also occur shortly after a Refresh request.

4.5.1.2 IOPCDataCallback::OnReadComplete 134

Called upon the completion of a Async Read.

4.5.1.3 IOPCDataCallback::OnWriteComplete     Page 136

Called upon the completion of a Async Write.�
�
Blogger Note:  A successful write does not necessarily mean the value was actually accepted by the underlying system, just that is was successful as far as the OPC server can determine.   Robust clients will perform a follow up read to ensure the write was not rejected at a lower level.

4.5.1.4 IOPCDataCallback::OnCancelComplete     Page 138

Called upon the completion of a Cancel request.

4.5.2 IOPCShutdown     Page 139

Good OPC clients will implement this interface, as it is the only way for an OPC server to cleanly notify the OPC client that it is shutting down.  Of course if the client supports connections to multiple servers, it would support interfaces for each server instance.

4.5.2.1 IOPCShutdown::ShutdownRequest     Page 139

Servers use this method to tell clients of impending shutdown, and allow them to perform clean up actions such as unadvising callbacks, etc.

5 INSTALLATION ISSUES     Page 140

The specification does not mandate any form of installation program, interface or installation type functionality.   However there are key registry settings and files required by Certified OPC products during installation.

5.1 COMPONENT CATEGORIES     Page 140

Outlines the Microsoft Component Category ids required by DA 3.0 servers.   These where introduced with OPC DA 2.0 to improve server discovery.   DA 1.0 installations required clients to perform time consuming remote registry scans, or worse require users to manually update the server machine registry.

5.2 REGISTRY ENTRIES FOR CUSTOM INTERFACE     Page 140

Required registry keys for any OPC server.

5.3 REGISTRY ENTRIES FOR THE PROXY/STUB DLL     Page 141

The proxy/stub DLL is used for marshalling interfaces to LOCAL or REMOTE servers. It is generated directly from the OPC Foundation supplied code and should be the same for every OPC Server.   Prebuilt and tested proxy/stubs are provided at the OPC Foundation Web site making it unnecessary for vendors to rebuild this DLL.

6 DESCRIPTION OF DATA TYPES, PARAMETERS AND STRUCTURES     Page 142

6.1 ITEM DEFINITION     Page 142

The ItemID is the fully qualified definition of a data item in the server, commonly referred to as the WHAT. No other information is required to identify the data item for the client to be able to read/write values.

Blogger Note:  ItemIDs are unspecified by the OPC Foundation.   Servers can use pretty much any format or naming convention they want.  This is both a majority flexibility feature, and an interoperability headache.   The open format allows servers to offer very powerful data access features by simply having a well documented naming convention.   On the other hand OPC clients need to be able to handle many formats, and make no assumptions on naming conventions like name length, acceptable characters or delimiters, or even that the ItemID is in any way related to the browse structure a server may expose.

6.2 ACCESSPATH     Page 143

The AccessPath is intended as a way for the client to provide to the server a suggested data path (e.g. a particular modem or network interface). It indicates HOW to get the data.

The ITEM ID provides all of the information needed to locate and process a data item. The Access Path is an optional piece of information that can be provided by the client. Its use is highly server specific but it is intended to allow the client to provide a ‘recommendation’ to the server regarding how to get to the data.

Blogger Note:  This was a good idea that resulted in many interoperability problems.  Since it was an optional feature neither clients or servers could rely on the AccessPath to provide information.   Most well written clients/servers use it as a convenient way to pass information, but will rely on the ItemID or other configuration to ensure essential data is transferred.

6.3 BLOB     Page 144

Essentially a binary ‘scratch pad’ that allows clients and servers to exchange unstructured binary information.
Blogger Note:  Another good idea that suffered from interoperability problems.

6.4 TIME STAMPS     Page 144

Time stamps are in the form of a FILETIME as this is more compact than other available standard time structures. Time stamps are always in UTC since this form is always increasing and is unambiguous. Time stamps should reflect the best estimate of the most recent time at which the corresponding value was known to be accurate. If this is not provided by the device itself then it should be provided by the server.

Blogger Note:  The most common complaint with OPC timestamps is that there is no standardized way of clients to determine if a timestamp is supplied by the underlying device, the OPC server or even an aggregating OPC server.   OPC UA addresses this problem by supplying two timestamps a SERVER and SOURCE timestamp.

6.5 VARIANT DATA TYPES FOR OPC DATA ITEMS     Page 145

Outlines how VARIANT data types are handled with Win95, NT 4.0 and Automation interfaces.  It also points out that under IEEE rules, NAN values are allowed and must be handled by clients and servers.

6.6 CONSTANTS     Page 146

6.6.1 OPCHANDLE     Page 146

OPCHANDLEs are used in conjunction with both groups and items within groups. The purpose of handles in OPC is to allow faster access to various objects by both the client and the server.

6.6.1.1 Group Handles     Page 146

6.6.1.2 Item Handles     Page 146

Describe specifics on how servers handle the handles.

6.7 STRUCTURES AND MASKS     Page 147

6.7.1 OPCITEMSTATE     Page 147

6.7.2 OPCITEMDEF     Page 148

6.7.3 OPCITEMRESULT     Page 150

6.7.4 OPCITEMATTRIBUTES     Page 151

6.7.5 OPCSERVERSTATUS     Page 153

Gory details on specific structures and masks used within the OPC specification. 

6.7.6 Access Rights     Page 154

This represents the server’s ability to access a single OPC data item in terms of readable and writeable.  Client applications should use this information only as something to be viewed by the user. Attempts by the user to read or write a value should always be passed by the client program to the server regardless of the access rights that were returned when the item was added.

6.7.7 OPCITEMPROPERTY     Page 156

6.7.8 OPCITEMPROPERTIES     Page 157

Describe specifics on OPC Item Properties.

Blogger Note:  Yet another powerful feature that suffered interoperability woes.  Item properties could supply important information, but suffered from less than performant access calls.  DA 3.0 aliviated this somewhat by adding property information to the browse interface.   Again this issue has been dealt with in OPC UA.

6.7.9 OPCBROWSEELEMENT     Page 158

6.7.10 OPCITEMVQT     Page 159

New structures to handle new DA 3.0 functionality.

6.8 OPC QUALITY FLAGS     Page 160

These flags represent the quality state for a item’s data value. This is a simplified version of the Fieldbus Data Quality Specification. The intent of the design was to make easy for both servers and client applications to determine how much functionality they needed to implement.

Blogger Note:  Although there are some rarely used Quality codes, for the most part the GOOD, BAD and UNCERTAIN codes and associated sub states are fairly well used and predicable. In general, most of these states have migrated to OPC UA.

7 SUMMARY OF OPC ERROR CODES     Page 164

The OPC specification attempts to minimize the number of unique errors by identifying 32 common generic problems and defining error codes that can be reused in many contexts. An OPC server should only return those OPC errors that are listed for the various methods in this specification or are standard Microsoft errors.

8 APPENDIX A - OPCERROR.H     Page 167

9 APPENDIX B - DATA ACCESS IDL SPECIFICATION     Page 173

Nothing says ‘gearhead’ like a document that includes header or IDL files in the documentation.  If you don’t know what a header or IDL file is, then your not missing anything unless your job is to produce a working OPC server.

Whew!  Got to admit, when I decided to recap a 190 page specification from a high level, decision maker’s point of view, I didn’t think it would take six lengthy postings.   It just goes to show that standardized interoperability is not child’s play.   There are many key aspects to consider and many more factors to consider when choosing an OPC vendor you can trust to know what they are doing.  No wonder pundits say system interoperability is 10% of the budget and 90% of the heartache.

I hope that a few of you out there got some good information from this exercise, then it was worth the effort.  I know that taking forcing myself to take a renewed, close look at the specification was a helpful reminder of what OPC is and does.  If you are sitting there wondering; Should I use OPC?   Is joining the OPC Foundation important?  Or Do I trust my OPC vendor? I hope I’ve helped you answer your question.

I would still like to do something on a ‘layman’s comments on OPC UA’ but the shear size of the specifications would preclude such a detailed commenting as I did for OPC DA 3.00.  The next few posts will be more topical, since even as we approach the slower holiday season, there are things happening in the security, vulnerability disclosure and other arenas that are worth commenting on.  Tune in.