Comment: The OPC Versioning Problem

This article, written in February 1999, highlighted a major problem with versioning of OPC software, which could cause working OPC installations to be broken by either installing or uninstalling software from other OPC vendors.

See also our follow-up to this article, posted March 4 1999.

A definition of the problem

At the center of the problem is the set of proxy/stub DLLs used for marshaling data between clients and either local or remote servers. Because Data Access is the oldest and best used of the OPC specifications, this is where problems are most frequently encountered at present, and this will be the focus of our article. However, the same principles apply equally for the other OPC standards.

Data Access 1

The seeds of the problem were sown with the original Data Access specification, OPC 1.0. At this time, and even after the subsequent update to Data Access 1.0A, each and every server vendor was expected to build and distribute his own proxy/stub DLL. Furthermore, there was no specification as to what the file should be called, or where it should be installed on the user's computer. At this stage there was already potential for trouble: a working OPC server installation ('A') could be broken by installing and then uninstalling a second OPC server ('B'), as follows:

  • Initially, OPC interface marshaling is handled by the proxy/stub DLL installed with 'A'.
  • Following installation of 'B', marshaling is dealt with by the new proxy/stub installed with 'B'. At this stage both 'A' and 'B' still function correctly.
  • 'B' is then uninstalled, along with its proxy/stub. There is no automated way to re-register the original proxy/stub from 'A', so marshaling of OPC interfaces is now impossible and 'A' is not accessible from OPC clients.

Data Access 2

When drafting the revised Data Access 2.0 standard, OPC Foundation was clearly aware of this problem. At this point it introduced its own build of the proxy/stub DLL, OPCPROXY.DLL, to be used by all OPC vendors. Furthermore, it also specified where and how this file should be installed: in the Windows System directory, and with reference counting, i.e. as a system shared DLL. This is certainly a step in the right direction, but at least two problems remain:

  1. The OPCPROXY.DLL supplied by OPC Foundation contains no version resource, and can therefore only be versioned by its date and time. If this approach is to work it relies on all OPC vendors keeping the file's original time stamp intact (a Version Control System might easily change the time stamp, for example).
  2. At the time of writing (February 1999), most OPC Data Access software is still at the version 1 level, rather than version 2. A version 1 server's installation program will usually not follow the newer rules, and can easily grab hold of the marshaling of OPC interfaces on behalf of its own proxy/stub DLL. Once again, all may appear to be well until the version 1 server is uninstalled.

Examples of the problem

We tested two currently available OPC servers, from two of the best-known suppliers of OPC software. Both of them were found to exhibit variants of the OPC versioning problem. This should not be taken as a particular criticism of these vendors, but rather as an indication of how widespread the problem is. We believe that the huge majority of available OPC servers would have shown some form of the problem.

Case 1

Prior to this test, we installed and registered the 'official' OPC Foundation Data Access 2.0 proxy/stub, OPCPROXY.DLL, and ensured that its time stamp was correct. We then installed the latest version of a popular commercial OPC (and DDE) server. This installed its own OPCPROXY.DLL into the Windows System directory, with a later date than the file from OPC Foundation. On closer inspection, this file was found to be a version 1 proxy/stub. This installation would therefore have broken the marshaling of newer OPC interfaces such as IOPCAsyncIO2.

It is also the case that a 'correct' installation program (i.e. one written to follow the current guidelines) would not have replaced this rogue proxy/stub, because the 'correct' (i.e. newer) proxy/stub DLL actually has an older time stamp.

Case 2

Once again, we started by installing and registering the Data Access 2.0 proxy/stub. We then installed an OPC simulation server from a well-known OPC vendor. This came with its own version 1 proxy/stub DLL, installed under a unique name in a non-shared directory. However, it still took over marshaling of Data Access version 1 interfaces from the later version 2 proxy/stub. Everything apparently continued to function correctly until the simulation server was uninstalled. No valid proxy/stub then remained registered for the version 1 interfaces, and OPC Data Access functionality between processes was no longer available.

Fixing the problem

Both OPC Foundation and vendors of OPC server software have to accept some responsibility for this situation, and both should play a part in its resolution. In the meantime, OPC users will need to remain vigilant when either installing or uninstalling OPC software.

OPC Foundation

It is appropriate that a unique proxy/stub DLL is now available from OPC Foundation. However, there is no reason why this file should not contain a version resource, and it is not sensible to base version management of this file solely on its time stamp.

We therefore suggest that all proxy/stub DLLs (and other shared binary files) supplied by OPC Foundation be reissued with version resources as soon as possible.

OPC Vendors

The OPC Data Access 2.0 specification has now been available for several months, yet there is still very little OPC server software which is 'DA2.0 aware'. By this, we mean that even if a vendor does not plan to support the newer interfaces in his server, there is no reason for him not to be making use of the new proxy/stub DLL, which is fully backward compatible with version 1 software. By ensuring that this DLL is installed in the right place, in the right way, and with the correct time stamp, the OPC versioning problem could be quickly eradicated.

We ask all suppliers of OPC servers to make sure their servers and installation programs are 'good citizens' in this regard, at the earliest possible opportunity. In the near future, we at OPC Programmers' Connection plan to clearly indicate on our pages those OPC packages that continue to exhibit the versioning problem.

Follow-up

See our follow-up to this article, posted March 4 1999.