“Give up your weekend,” they said.
I thought to myself, why on earth would I want to do that?
“Go to Germany to attend the OPC Foundation InterOp (IOP) Europe Workshop,” they said.
Why didn’t they lead with that? Weekends are overrated anyways!
I left home on Friday morning and arrived in Nuremberg, Germany 14 hours later. After thoroughly enjoying my weekend in Germany, my alarm clock went off on Monday morning and it was time to head to the workshop.
Party time is over; time to get to work
The 2015 OPC Interoperability Workshop was held at the Siemens AG Automation and Drive Technologies offices. The place was huge! The offices were extremely modern and rather intimidating if I were to be completely honest.
Upon arrival, I registered at the security office at Siemens’ front gate where I received an ID 
badge. The workshop was located in a large room full of computers, routers, switches, and network cables. It was pretty exciting for a geek like me.
This workshop is “the event” for testing OPC products for interoperability. Vendors can test and debug their products against one another for not only interoperability, but also compliance and reliability. IOP workshops also provide an ideal opportunity to learn about OPC technology and to interact with industry-leading experts.
I was testing the interoperability of a new product in development at RtTech Software. The object of the product testing was to try and connect to each server present. Once connected, tests were conducted which ultimately gave the product a pass or fail. If any of the tests failed, the client and server vendors would collaborate to troubleshoot and fix any issues.
Things aren’t working between us because I just don’t feel a strong connection
Upon connecting my product to the server, I discovered that the cloud tools didn’t work by default while behind a proxy server. I also found out that the API calls used by our data agent didn’t work with the server.
Because we couldn’t configure the proxy server to allow for communication with the cloud, I ended up having to hard code all of the items and configuration values to connect the client to the server.
If someone mentions DCOM 1 more time…
Whenever anyone talked about DCOM at the workshop, everyone sighed and rolled their eyes. DCOM has provided major headaches for OPC developers. Luckily the OPC Foundation provided a wrapper for DCOM which simplified it for us.
We did however, run into permissions issues with DCOM. Our client had no problem connecting to OPC DA 3x and 2x servers but could not create subscriptions to the items to collect data. The problem is that the server has to open a connection back to the client via DCOM which is used to send subscribed item values when they change.
The best solution was provided by Siemens, which was to give the Domain Users group permissions to the DCOM objects and to have the Windows service running as a Domain User. It may sound like an easy fix, but it would have been difficult to find this solution without the help from Siemens.
The Global Discovery Server and its secret handshake
A very common and useful method for handling certificates in OPC UA configurations is the Global Discovery Server (GDS). The GDS handles the “handshakes” for all client and server instances on the network.
The OPC Foundation provides a tool that enables clients and servers to join the GDS which was used during the workshop. Each client would load its certificate into the GDS tool which would then register the client and provide a signed certificate which is then trusted.
The advantage here is that the particular certificate contains the handshake for all other clients and servers that have completed this process.
No security configurations? Whoops…
The real hot topic at the workshop was security. Server security configurations ranged from absolutely no security configuration with the servers, to others which allowed for all types of security.
Many servers at the workshop were configured to have no security requirements because they wanted other features of their servers tested and did not want to have to deal with security issues. Our client had to be coded to bypass the security stage and allow the data collection to proceed without throwing any errors.
The main security issue I encountered with our client was that it was designed for a secure 
connection and would throw an error if the trusted certificate (handshake) was not successful. The security of our data collector was coded to be on a X.509 certificate basis where the client trusts the server certificate and the server trusts the client certificate.
Our client would not start the data collection process if the handshake was not successful, despite being successfully connected. The security for our data client had to basically be entirely re-coded to operate without a trusted certificate.
All good things must come to an end
The workshop was a huge success. Our data collection agent has gone from a prototype to a fully functioning and secure OPC UA client that can successfully connect to 18 different OPC servers, developed by some of the biggest names in the industry. The servers were coded in Java, C++, and .NET and were running on a range of different PC’s running VxWorks, Linux, and various versions of Windows.
During the workshop, I had the opportunity to work with some OPC professionals that had been OPC developers for many years. Their knowledge and understanding of the OPC fundamentals and standards proved to be extremely valuable. As a result, I have gained a great deal of knowledge and a far better understanding of how OPC is used.
Hopefully I get asked to give up another weekend sometime soon.
–Brad Logan, .NET Developer, RtTech Software