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.

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…

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…�