I’ve posted before on the topic of the requirement to be a member of the OPC Foundation in order to have full access to the OPC specifications.  I’ve gotten comments back both on the blog and off line.   The main argument on the ‘open means free’ side of the argument, is that people considering using OPC, those researching the benefits of OPC or users wanting a better understanding of OPC should have access to the specs.    My reply back to that was always you don’t need the specifications for that information, and it’s available from other sources or training courses.

After thinking about it some more, and a few Guinness later, I realized that argument makes sense to me because I’ve SEEN the specifications.  I KNOW they are dry as Melba Toast and give specific details on what COM interfaces to implement, how to handle different return parameters, etc.  I also know that when you are finished reading them you know HOW to write an OPC server, but they don’t lay out WHY you would want to use OPC.    The WHY is really the question researchers and the users still sitting on the fence want answered.   I’ve played the roles of project director, system architect or product manager enough to know that the decision to go with a widely accepted industry standard or roll-your-own custom interface hinges on a much higher level then the implementation details.  Decision makers need to know things like functionality fit with their application, availability and interoperability of the interface in their market space and projected lifecycle and maintenance costs.   Whether a specific parameter is passed as a DWORD or Enum, or which return array contains the error result isn’t going to tip the scales on the decision to go with OPC.   Truly the only reason to read the specifications, is to determine HOW to write an OPC server.

Making the decision to go with OPC brings the benefits of standardization and interoperability, wide availability of products and services, and a vast, mature installation base.   Of course these benefits demand certain responsibilities from each implementer.   Adherence to the specifications, certified interoperability with other OPC products, acceptance of best practices and continued support and maintenance as the OCP interfaces mature and evolve.  It’s access to the OPC tools, processes and community events that membership really provides.   Access to the specifications is more of a necessary by product to meet these end goals, than the main reason for joining the OPC Foundation.

Like I said, it’s easy for me to say all this stuff because I’ve seen the specifications.   So to dispel the ‘Holy Grail’ aura of these documents, over the next few posts I’m going to give a section by section technical overview of the OPC specifications starting with OPC DA 3.00.    Before anyone gets too exicited let me say, I’m not going to be exposing any dark secrets here.  In fact the vast majority of this stuff is available on the Net if you know how to use ‘The Google’.   My aim here is to provide a one-stop-shop, ‘decision makers’ view of the information available in the OPC specifications.  So here goes:

Data Access Custom Interface Standard
Version 3.00 – Released  March 4, 2003

Synopsis:
This specification is the specification of the interface for developers of OPC Data Access clients and OPC Servers. The specification is a result of an analysis and design process to develop a standard interface to facilitate the development of servers and clients by multiple vendors that shall inter-operate seamlessly together.

1 INTRODUCTION     Page 1

This paragraph points to the publicly available OPC Overview document.

1.1 AUDIENCE     Page 1

This paragraph states the specification targets OPC client and server developers.  Stress the assumption readers understand Microsoft COM and C/C++ programming language.

Blogger Note:  Told you these things are written for the ‘gear heads’ among us

1.2 DELIVERABLES     Page 1

What you get.  The document, IDL and error code header files in the appendix as well as access to proxy stubs, additional header files and sample code on the OPC Foundation Web site.

2 OPC DATA ACCESS FUNDAMENTALS     Page 2

The specification will talk about OPC DA and other fun stuff like Microsoft Windows, UNICODE and threading modelsBlogger Note:  Sounds like riveting stuff

2.1 OPC OVERVIEW     Page 2

The specification uses different a few different diagrams, but they express the same concepts.  Any compliant OPC client can connect to any OPC server, and an OPC server can be written for pretty much anything.   

 

From a logical point of view, an OPC server is comprised of different objects: Server, Group and Item objects.  The OPC server object maintains information about the server and serves as a container for OPC group objects. The OPC group object maintains information about itself and provides the mechanism for containing and logically organizing OPC items.

 

The Group provides a convenient way for an application to organize the data it needs. Different Groups can be used by different parts of the application; can have different refresh rates; can be polled or exception based.  The Item provides a connection point to a value in the physical device. and provides information to the client; Value, Quality, TimeStamp, and Data Type.  The OPC item is a transient object which exists within the OPC server. It is used to create a connection between the server and the real data.  It should be thought of as simply specifying the address of the data, not as the actual physical source of the data that the address references.

Blogger Note:  This section actually is important for those looking for reasons to choose OPC over other interfacting options.  I’m not actually revealing secrets here.   Anything I’m posting here is freely available out on the web.   Special thanks to Al Chishom for all his great work on some of the early OPC presentations still available on GE’s website.

2.2 WHERE OPC FITS     Page 3

OPC can exist in multiple levels of a data acquisition architecture.  Again different diagrams, but the same concepts.

2.3 GENERAL OPC ARCHITECTURE AND COMPONENTS     Page 4

Outlines how OPC, much like any COM interface can be provided as a custom C++ implementation or a wrapped Automation interface for simplified Visual Basic or Delphi applications.  Stresses the specifications detail what the interfaces are, not how they are presented.   Vendors may choose to provide the interfaces as In-proc, Local or Remote flavors.   Blogger Note:  Experience shows use that the vast majority of OPC servers should be Remote type implementations, but Local or In-Proc versions might exist to provide specific, tightly bound, behaviours like seamless redundancyOutlines how OPC, much like any COM interface can be provided as a custom C++ implementation or a wrapped Automation interface for simplified Visual Basic or Delphi applications.   Stresses the specifications detail what the interfaces are, not how they are presented.   Vendors may choose to provide the interfaces as In-proc, Local or Remote flavors. 

2.4 OPC DATA ACCESS ARCHITECTURE COMPANION SPECIFICATIONS  Page 5

OPC Data Access provides the baseline functionality for reading and writing data from various networked devices via a standard set of interfaces. The interfaces facilitate the interoperability between clients and servers discovering each other and communicating the set of capabilities as well as a defined set of interfaces to facilitate mechanisms to access data items according to the needs of the client application.  Other OPC specialized real time data access specifications exist such as OPC Common, OPC Complex Data, OPC Data eXchange.

2.5 OVERVIEW OF THE OBJECTS AND INTERFACES  Page 6

The OPC Server object provides a way to access a set of data sources. The types of sources available are a function of the server implementation, and an OPC client connects to an OPC server and communicates to the OPC server through these interfaces. The OPC server object provides functionality to an OPC client to create and manipulate OPC group objects. These groups allow clients to organize the data is accessed. A group can be activated and deactivated as a unit. A group also provides a way for the client to ‘subscribe’ to the list of items so that it can be notified when they change.

OPC Server Object has the interfaces:

IOPCCommon
IOPCServer
IOPCBrowse
IOPCItem
IOIConnectionPointContainer

OPC Group Object has the interfaces:

IOPCItemMgt
IOPCGroupStateMgt2
IOPCSyncIO
IOPCSyncIO2
IOPCAsyncIO2
IOPCAsyncIO3
IOPCItemDeadBandMgt
IOPCItemSamplingMgt  (optional)

Blogger Note:  A lot of functionality packed into a few objects.  If OPC servers weren’t reasonable to implement, OPC wouldn’t be as wide spread as it is today.  Note I didn’t say easy.  I said reasonable.  There is a difference.

2.6 THE ADDRESS SPACE AND CONFIGURATION OF THE SERVER.  Page 7

This release of the OPC specification assumes that a server configuration address space may be managed and persistently stored using the IPersistFile interface. Only the server specific information is persistently stored. All client configuration information (Group and Item Definitions) must be persistently stored by the respective client application. All Handles that are defined in the system are not guaranteed to have the same value between sessions of the client and server conversation.Blogger Note:  Ah, the many headed beast that is browsing, address space and server discovery/persistence responsibility.  DA 1.0 and 2.05 said this was optional.  DA 3.00 states an address space is mandatory, yet still is constrained by the underlying system as to how detailed this information might be.  In general, whenever practically possible, a well written OPC server will give some information as to how the underlying system is structured or expecting to be addressed by the client application.

2.7 APPLICATION LEVEL SERVER AND NETWORK NODE SELECTION  Page 8

An OPC client needs the OPC server name, name or IP address of the host machine and details on the Item ID nomenclature expected by the OPC server.  The specification does not provide strict guidlelines such as allowed characters, use of spaces or specific delimiters or character length limitations.   Any such limitations a vendor may choose to impose is their choice, and at their (and their customers’ peril)

2.8 SYNCHRONIZATION AND SERIALIZATION ISSUES  Page 8

The OPC specifications do NOT outline any requirements to ensure that all Items in a particular group or read function are synchronized by the underlying device. Blogger Note:  The aim of the OPC interfaces is to provide standardized, timely data access.   It was not intended as  a guaranteed, synchronized data access method.  Specialized OPC client or server applications may provide this, but it is not inherent in the OPC specifications.

2.9 PERSISTENT STORAGE STORY  Page 9

Servers might provide this, but at the end of the day OPC clients are responsible for the configuration and persistent storage of the groups and items that are required by their application. Servers might provide this, but at the end of the day OPC clients are responsible for the configuration and persistent storage of the groups and items that are required by their application.Servers might provide this, but at the end of the day OPC clients are responsible for the configuration and persistent storage of the groups and items that are required by their application.This post is already WAY too long, and we are only on Page 9 of 190!   Actually we will see that the majority of the document is dedicated to the gory details of implementation, with a some key general concepts buried in there.  Stay tuned…�