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.