When someone says “I’m using OPC”, invariably they mean they are using OPC DA 2.05.  It’s far and away the front runner of existing OPC installations.  There are quite a few architectures using OPC HDA and A&E, far fewer using Batch, XML DA or DX.  Somewhat of a mixed bag, would be those using OPC DA 3.00, which was released in early 2003.  Most major OPC vendors have since upgraded their products to support OPC DA 3.00, but how many out there are using the new features?  A better question is what ARE the ‘new’ features.  In fact that topic recently surfaced again recently on the OPC Forum.  If you read the introduction of the OPC DA 3.00 specification, you see the main changes were:

• Added new interfaces  (IOPCBrowse, IOPCItemDeadbandMgt, IOPCItemSamplingMgt, IOPCItemIO, IOPCSyncIO2, IOPCAsyncIO3, IOPCGroupStateMgt2)
• Clarified startup issues and add WAITING_FOR_INITIAL_DATA quality status mask.
• Added Item Property #7, #8 for EUTYPE
• Clarify SetActiveState to indicate that an item transition from inactive to active will ultimately result in a quality change, triggering a callback.
• Add new server status enumeration (OPC_STATUS_COMM_FAULT)
• Removed Legacy Interfaces from this version of the specification (IOPCServerPublicGroups, IOPCBrowseServerAddressSpace, IOPCPublicGroupStateMgt, IOPCAsyncIO, IOPCItemProperties)
• Added Item Properties section
• Clarify RemoveGroup
• Added CATIDs to idl
• Provided the ability to read and write the quality and timestamp
• KeepAlive mechanism was added to confirm the callback connection health

Fine and dandy.  What exactly does that mean to the end user in terms of functionality?  Let’s paraphrase things, shall we?

New Browsing:  v3.00 replaced the way server browsing was performed, and was very similar to the way XML DA provided browsing.  First key item is browsing is no longer optional.  A server must return something when a client browses.  From the perspective of the user,  browsing behaves much as it did before.  The new interface greatly simplified the recursive work OPC clients sometime had to do when using the now deprecated IOPCBrowseServerAddressSpace.  It also streamlined how Item properties were accessed, as well as provided better handling for very large address spaces.   This same thinking has been carried over into the OPC UA specifications.

Better Deadband Handling:  Deadband was handled as a percentage of span of an OPC Group.  The deadband can be still be set on the at the group level, but DA 3.0, also allows the deadband to be on a per item basis. This means that each item can potentially override the deadband set for the group it resides within.

Single Item Data Access:  In OPC DA 2.05 the only way to read/write data was for an item to first be added to a group.  An interface was added so that it would be function as if a group was created, items added, a single read or write was performed and the group deleted.  

Writing VQT:  Interfaces were added/enhanced to allow for a DA write to set the value, quality and timestamp.  The DA 2.05 interface only allowed for the value to be set on a write.  Before the release of DA 3.0 people would use OPC HDA to do this.  In DA 3.0 the WriteVQT functionality applies to single item access, synchronous and asynchronous interfaces.

Maximum Age of Data:  Interfaces were added/enhanced to allow passing of an array of “staleness” for each item. The server calculates, for each requested item, the number of milliseconds between “now” and the timestamp on each item. For each item that has not been updated within the last MaxAge milliseconds, then data must be obtained from the underlying device.  This functionality applies to single item access, synchronous and asynchronous reads and refreshes.

Item Sampling:   An optional interface was added that allowed the client to manipulate the rate at which individual items within a group are obtained from the underlying device. It did not affect the group update rate of the data change callbacks.  This is sort of a poor man’s buffering solution.  In a nutshell, an server could scan data at a rate faster than the group update rate, so on an update multiple values could be returned for a single item.  This is useful for protocols like DNP 3.0 where a device could send multiple values in a single scan, which a DA 2.05 client would miss, even on an extremely fast update, but a DA 3.0 client would catch.

KeepAlive Message:  Added a specific KeepAlive message so clients could tell a server was still around even if no data was updating. 

Removed Public Groups:  Not practical. Not necessary. Not used. Not around anymore.

…and a bunch of clarifications to clear up some of the grey areas of the specification.

So, all and all some good stuff.  Conscientious vendors upgraded their servers to support DA 3.0, and clients were updated as the functionality was needed for particular applications.  The good news is it all got rolled into OPC UA as well.   It won’t be too long before you start seeing those too.