Let’s continue along with our detailed overview of the OPC DA 3.00 specification.  If you missed the preamble on this series of blog entries check out the earlier post.   The Reader’s Digest version is that there a many researchers, students, end-users or potential developers looking for an understanding of OPC is and what it offers.   They naturally assume the OPC specifications are the best place to go looking for this information, and find the policy requiring OPC Foundation membership to be unfair.  There are many benefits for joining the Foundation, and access to the specification for programming wishing to develop products is just one of them.

My hope is that by providing a technical commentary on the OPC specifications with the decision maker or researcher in mind, more people will see value in adopting OPC.  The fees associated with joining the OPC community should be an investment for gaining the benefits of standardized interoperability, and not a barrier to understanding.  So, let’s keep going (even if it’s a bit of a monster post)…

3 OPC DATA ACCESS QUICK REFERENCE     Page 10

3.1 CUSTOM INTERFACE     Page 10
This short section outlines the interfaces on the Server and Group objects, and highlights the new interfaces.  

OPCServer
IOPCServer
IOPCBrowse (new with DA 3.0)
IOPCItemIO (new with DA.0)
IConnectionPointContainer
IOPCCommon
OPCGroup
IOPCGroupStateMgt
IOPCGroupStateMgt2 (new with DA.0)
IOPCASyncIO2
IOPCAsyncIO3 (new with DA.0)
IOPCItemMgt
IOPCItemDeadbandMgt (new with DA.0)
IOPCItemSamplingMgt (new with DA.0, optional)
IConnectionPointContainer
IOPCSyncIO
IOPCSyncIO2 (new with DA.0)
EnumOPCItemAttributes
IEnumOPCItemAttributes

(Blogger Note:  Again no big secrets here, as this information can be found most user manual documentation or with a little legwork looking at an freely available OPC server.)

4 OPC CUSTOM INTERFACE     Page 11

4.1 OVERVIEW OF THE OPC CUSTOM INTERFACE     Page 11

As we said, the OPC Custom Interface Objects include the following custom objects:
OPCServer
OPCGroup

Since the OPC specifications focus on what developers of OPC servers are required to do in order to implement these objects, this section describes the interfaces and behaviors of these objects.

4.2 GENERAL INFORMATION     Page 12

4.2.1 Version Interoperability     Page 12
(Blogger Note:  This section is one that decision makers and end users will be very interested in.)

As the OPC specifications matured and evolved new versions of the Data Access specification were released.  Versions 1.0a (1997), 2.x (1998-2002) and 3.0 (2003) where released.  As the specifications, point out Data Access Servers MAY be compatible with the requirements of Versions 1.0a, 2.x or 3.0 of the specification or with any combinations of the Data Access Specification Versions. Data Access Clients may also be compatible with the requirements of Versions 1.0a, 2.x or 3.0 of the specification or with any combinations of the Data Access Specification Versions.  Notice the word MAY, that doesn’t mean they WILL.

There are sections of each previous interface that are not backward compatible with the next version.   The reason backwards compatibility was not demanded was each version make corrections or changes, due to interfaces that caused confusion, performance problems or other issues.  These things were corrected in the newer versions, so requiring backward compatibility would continually propagate the problems.  Existing products would be upgraded to the new interfaces, but new products being developed typically would use the most current version as the baseline.  A shiny new OPC DA 3.0 client would not interface properly with a legacy 1.0a server.

It is important for users to understand what OPC specification versions the products support, and ensure their OPC product vendor is keeping pace with the latest specifications.   

4.2.2 Ownership of memory     Page 13

The Microsoft COM specification dictates how clients must free all memory associated with parameters.  This is very important for client writers to understand, otherwise they will experience memory leaks that are difficult to find.   Key point is releasing the allocated resources is the client’s responsibility.  A poorly written client could make a server appear to be leaking memory.

4.2.3 Standard Interfaces     Page 14

Microsoft COM rules dictate how developers deal with standard and optional interface.

4.2.4 Null Strings and Null Pointers     Page 14

These are not the same thing and developers need to know the difference.

4.2.5 Returned Arrays     Page 14

Notes on how the specifications deal with returned arrays to simplify marshaling, creation, and access of the data by the server and client.

4.2.6 CACHE data, DEVICE data and TimeStamps     Page 14

(Blogger Note:  This is another concept that decision makers and end users often care about.  Performance of any client or server depends on how they make use of the CACHE and DEVICE access options.  A good training course goes over this in detail, but here are the main ideas.) 

The specification uses the terms CACHE and DEVICE as abstract concepts with well defined described behaviors of the various interfaces in a well. The specifications does not dictate the implementation details of these capabilities.  Due to the nature of the caching requirements, most servers will read data into some sort of CACHE. 

OPC clients typically provide read data from this cache via one of several OPC DA mechanisms.  In most systems direct DEVICE access is not optimized or perfomant.  Most architectures will only use this access method for diagnostics or for particularly critical operations.  

Most architectures will only use this access method for diagnostics or for particularly critical operations.The specification outlines how the CACHE should reflect the latest value, quality and timestamp of the data based on configured update rate and deadband. It is expected that the timestamp will either indicate the time the value and quality was obtained by the device or that the server updated or validated these in its CACHE.  So for example, if a device or server is checking a value faster than a client has subscribed to that value, then the server would be updating the timestamp in the cache at the checking rate even if the value is not actually changing. Therefore the time stamp reflects the time at which the server knew the corresponding value was accurate.

4.2.7 Time Series Values     Page 15

(Blogger Note:  Another concept that decision makers and end users should consider when determining where OPC DA best fits in their architecture.)

4.2.8 Asynchronous vs. Synchronous Interfaces     Page 15

The OPC DA specifications are based on the premise that most client applications are willing to sacrifice data freshness, within the specified update rate, in order to optimize data access.  OPC Clients may provide options to use Asynchronous and/or Synchronous access to an OPC server with CACHE or DEVICE qualifiers.  Using asynchronous subscriptions to cache data will minimize the demand on CPU and network resources. OPC Data Access is designed to reflect the most current real time process or automation data. The Timestamp returned with those values is primarily intended as an indication of the quality of that most recent data.  Although the specification deals with a single value data cache and offers the Item Sampling functionality, the OPC DA interfaces are not intended to deal with buffered time series data.   Historical data access or guaranteed data delivery in unstable systems are better handled using the OPC HDA (Historical Data Access) specification.

4.2.9 The ACTIVE flags, Deadband and Update Rate     Page 15

The OPC DA specification offers options to reduce resource usage by OPC clients and servers.  The affect how often the cached data and quality information is reported back to a subscribed OPC client.  These are important considerations for extremely large systems or those using networks that are unreliable or bandwidth limited.

4.2.10 Errors and return codes     Page 15

The main mechanism an OPC server has for communicating abnormal information to an OPC client is via return codes.  The specification outlines the OPC specific codes as well as the most common COM based codes.   Of course robust OPC servers and clients will be able to handle a wide range of error situations, not just the most common.  In certain situations the OPC specification allows for vendor specific codes which rely on the string description to communicate the specific information to the user.  Well designed OPC client applications will take this into consideration as part of their GUI development.

4.2.11 Startup Issues     Page 15

(Blogger Note:  This section deals with a common pitfall many inexperienced developers fell into.   Although many clients/servers already worked around this issue, the OPC DA 3.0 specification deals with it specifically.)

After Items are added to a group, it may take some time for the server to actually obtain values for the items depending on the underlying data source  The specification states that when using subscriptions that an initial callback is expected which contains all values in a Group. In order to statisfy this need, servers typically add items to a group with their initial state set to OPC_QUALITY_BAD. 

Some OPC clients where designed perform a reconnect when a BAD value was encountered, resulting in a never ending failure/retry scenario.  To overcome such situations many clients perform a follow up read from cache and/or execute a Refresh on subscriptions before declaring the value BAD.   In an effort to better standardize the initial startup behavior, the OPC DA 3.0 specification introduces the OPC_QUALITY_WAITING_FOR_INITIAL_DATA (20) status mask.  Properly designed OPC clients will be able to handle the situation for OPC DA 2.05 and 3.0 servers.

4.2.12 VARIANT Data Types and Interoperability     Page 16

Another common stumbling block for OPC product developers was dealing with data type conversions.   The specifications allow for an OPC client to request any data in a specific format, regardless of the underlying canonical data type.  This introduces many grey areas in expected behavior.  For example when expecting conversion of the string “BOB” as an integer one might understand an error code, but what if the string was “5”?  Converting the REAL value of 25.0 into an integer is straight forward, but what happens when an eight byte REAL value overflows a two byte INTEGER?  These situations where not well defined in the OPC DA 2.x specifications.   This section of the OPC DA 3.0 specification outlines all the rules needed to handle expected data conversion situations.

4.2.13 Localization and LocaleID     Page 19

Since OPC is a globally accepted data access standard that means that OPC clients and servers will have to deal with Localized aspects such as language, data format, etc.   While the specifications do not mandate specific Local support, it does outline the expected behavior for OPC clients and servers for negotiating and dealing with locals.Since OPC is a globally accepted data access standard that means that OPC clients and servers will have to deal with Localized aspects such as language, data format, etc.   While the specifications do not mandate specific Local support, it does outline the expected behavior for OPC clients and servers for negotiating and dealing with locals.

4.2.14 Item Properties     Page 19

(Blogger Note:  Item properties are another OPC DA concept that was very useful, yet not fully detailed in previous versions of the specification.  OPC DA 3.0 provides more detailed expectations for servers when dealing with OPC item properties..)

Since OPC is a globally accepted data access standard that means that OPC clients and servers will have to deal with Localized aspects such as language, data format, etc.   While the specifications do not mandate specific Local support, it does outline the expected behavior for OPC clients and servers for negotiating and dealing with locals.The initial assumption by the OPC specifications was that some associated information for a particular item, such as description or engineering units would only be needed sporadically and therefore did not need optimization or detailed clarification.  As OPC became more accepted and used in applications like system management or data optimization access to auxiliary information became more prevalent.   This led to variations in how OPC Servers exposed data.  For example some servers would expose the item FIC101 with the item properties Description and EU Type, while another server would expose three OPC items FIC101, FIC101.Description and FIC101.EU.  To deal with this OPC DA 3.0 provides mechanisms that allow for flexible and convenient ways to browse, locate and read related information without imposing any particular design structure on the underlying system.

4.2.15 IOPCSyncIO     Page 25

4.2.16 IOPCASyncIO2     Page 26

4.2.17 SUBSCRIPTION via IOPCDataCallback     Page 27

These three sections deal with how a server should behave depending on what interface an OPC client calls, and what the associated flags for CACHE/DEVICE, callback support and group/item active states have been set to.   There are many possible combinations of data source, method and activation set any particular client might choose.   While the detailed situations are important for a developer implementing an OPC server, it should be sufficient for a decision maker to know that each relevant situation has been considered and explained.

These three sections deal with how a server should behave depending on what interface an OPC client calls, and what the associated flags for CACHE/DEVICE, callback support and group/item active states have been set to.   There are many possible combinations of data source, method and activation set any particular client might choose.   While the detailed situations are important for a developer implementing an OPC server, it should be sufficient for a decision maker to know that each relevant situation has been considered and explained.This post is getting a bit long in the tooth so to speak, so I’ll stop here.   What I’ve been posting is a bit of rough paraphrasing the specs and a bit of my commentary and elaboration on concepts I think decision makers would care about.  We’re on page 28, but a lot of the next few sections is dedicated information only developers would care about.  I’ll still hit each section and attempt to extract the higher level meaning the masses would care about.  

Is this exercise useful?  Let me know either in comments or an e-mail off line.  If enough people express interest, I’ll do something similar for HDA, A&E and even UA if people want.  If you think this is a waste of blog space and I’m not offering anything you don’t already know, tell me that too.  I’m here to write what you want to hear, so let me know what that is.  Next post the Server Object…