View source for A (Partial) Story of OPC URLs

This article describes how the URLs used in OPC Classic came to existence, and their syntax in different software packages.

Have you ever seen something like this, when connecting to an OPC server?

 opcda://TEST-OPC/Kepware.KEPServerEX.V5/{B3AF0BF6-4C0C-4804-A122-6F3B160F4397}

It looks like an URL. But, is it an URL? In this case, you might guess that it refers to an OPC Data Access server, and that the TEST-OPC is the name of the computer, "KEPServerEX.V5" is the OPC server's ProgID, and {B3AF0BF6-4C0C-4804-A122-6F3B160F4397} is its CLSID.

For OPC "Classic" servers, the OPC specification actually do not have a mention of such syntax at all. Yet it seems to be used by various products. The first time I remember seeing this syntax was when playing with the Softing OPC Toolbox Demo Client:

[[File:Softing-demo-client-url.png|thumb|alt=Screenshot of Softing Demo Client with URL|Softing Demo Client with URL]]

Over the time, I spotted its usage at some other places as well. What's more, people who were not expert in OPC area started to consider such URL-like syntax like a part of the OPC specification, and posted forums questions mentioning the syntax etc. And, customers even used that form when they tried to work with our own products, which did not have a support for it at the time (when specifically dealing with COM servers, we prefer to identify the server directly by the computer name, and the server's ProgID or CLSID).

As it turned out, the probable cause of the proliferation was the OPC NET API, basically a sample code from the OPC Foundation (available to its members) which demonstrates how to create basic OPC servers and clients in .NET. The OPC NET API has a code that displays this syntax at various places to the user, and is able to recognize it as an input to some of its methods. Also, Kepware ClientAce product uses a variant of this syntax.

Things start becoming even more interesting when we put the Internet-based OPC specifications into the mix, because they use the true URLs for connection to the servers. First of them was the OPC XML-DA spec, but now we have OPC-UA with its various transport mechanisms; also, the OPC Xi specifications are based on Web services and thus need URLs.

Below is a short summary of what we could find about the "OPC URL" syntax used in various OPC products.

== Softing ==
Following is the syntax used by Softing for OPC Data Access and OPC Alarms&Events servers, respectively:

 opcda://''computerName''/''progId''/{''clsid''}
 opcae://''computerName''/''progId''/{''clsid''}

When both ProgID and a version-independent ProgID are available from the server browsing, Softing places just the normal ProgID (version-dependent) to the URL. Note that this is a difference from OPC NET API (described further below). The computerName can be an empty string (for a local computer). Also, the progId may be empty altogether, and the client will simply use the CLSID.

== Kepware ==
Kepware documents following syntax for the URL parameter of their Connect method:

 ''opcSpecification''://''hostName''/''serverIdentifier''

For OPC Data Access servers, the ''serverIdentifier'' has the form below, where the {''clsid''} is optional:

 ''progID''/{''clsid''}

Originally, Kepware has allowed only "opcda" for the opcSpecification, but as you can see further below, they have later generalized it to support OPC XML-DA and OPC Unified Architecture as well.

=== Notes from Kepware documentation ===
For OPC DA servers, the API will attempt to connect using the ClassID first. If the ClassID is not given (or is found to be invalid), the API will attempt to connect using the ProgID.

=== OPC DA Example ===
 opcda://opcua.demo-this.com/Kepware.KEPServerEX.V5
 opcda://127.0.0.1/Kepware.KEPServerEX.V5/{B3AF0BF6-4C0C-4804-A122-6F3B160F4397}
=== OPC XML-DA Example ===
 http://127.0.0.1/Kepware/xmldaservice.asp
=== OPC UA Example ===
 opc.tcp://127.0.0.1:49320

== OPC NET API ==
For OPC COM servers, OPC NET API (version 2.01.105.1) uses one of the following syntaxes, depending on whether the ProgID is available or not:

 ''scheme''://''computerName''/''progId''/{''clsid''}
 ''scheme''://''computerName''/{''clsid''}

When both ProgID and a version-independent ProgID are available from the server browsing, OPC NET API places just the version-independent ProgID to the URL. Note that this is a difference from Softing (described above). The computerName can be an empty string (for a local computer). Also note the slight difference from Softing and Kepware in case that the ProgID is not available: In OPC NET API, one forward slash is missing.

OPC NET API defines following schemes for OPC COM servers (they are just constants taken from the code - the library actually does not have support for all of them):

* opcae
* opcbatch
* opcda
* opcdx
* opchda

There is also an indication that the library was supposed to also support (or it originally supported) "dcom" as the alternative scheme for "opcda", but currently the "dcom" scheme does not work in OPC NET API.

For OPC XML-DA, the library contains a constant for a scheme "opc.xmlda", but it does not really support it; instead, it recognizes just "http".

For OPC Unified Architecture, the library contains scheme contants "opc.http" and "opc.tcp", but it does not actually support OPC-UA at all (for this, there is a separate .NET stack library by the OPC Foundation).

== Conclusion ==
Now, is it a good thing or bad thing that such un-official standard has emerged?

=== Advantages ===
* The OPC connection data can be specified in just one string, making it easy to pass around, or convey to a user. 
* There is a common understanding in the OPC community of the OPC URLs.
* Both the ProgID and CLSID can be contained in the string, and the connection code can pick whatever allows to make the connection and/or is more efficient.
* The OPC URL can be used to distinguish the specification (technology) of the OPC server you want to connect to.
* URL syntax allows synthesis with Web-based technologies.

=== Disadvantages ===
* There is no real standard to conform to, and there are differences (some minor, some quite significant) in how different parties think how the "OPC URLs" should look like.
* Some parts of the syntax used do not fully conform to URL syntax. For example, the curly brackets used around the CLSID should not really appear (as such) in a URL; they should be escaped (using the percent sign). Similar problems arise when an OPC server developer decides to use non-standard characters in a ProgID (which is against the Microsoft specifications, but it actually works). For example, Matrikon OPC Tunneller uses colons (:) in the ProgIDs it generates.
* Because of lack of a standard, it is not fully clear how to compare the OPC URLs for equivalence, and how to normalize or canonicalize them.
* Passing the OPC URLs to various system or library classes designed to handle URLs is not without problems (due to the issues mentioned above). Precise round-trip from the URL string to the URL-handling classes back to the URL string is generally not achievable.
* It is not always possible to determine the OPC specification (technology) from the OPC URL. For example, "http" may refer to an OPC XML-DA server, to an OPC Unified Architecture, or possible even to OPC Xi (Express Interface/OPC .NET 3.0) server.

We at OPC Labs have decided to support OPC URLs, but at the same time, we provide means to specify the OPC connections in a traditional way. You can pick whatever suits you better.