The OPCHDA connector is available under Windows only. It requires a particular configuration of Windows to work properly. OIBus uses an HDA agent, a module integrated to OIBus but available in standalone to perform OPC history extractions in command line. This aspect will be discussed later.
COM is the standard protocol for communication between objects located on the same computer but which are part of different programs. The server is the object providing services, such as making data available. The client is an application that uses the services provided by the server.
DCOM represents an expansion of COM functionality to allow access to objects on remote computers. This foundation allows standardized data exchange between applications from industry, administrative offices and manufacturing. Previously, applications which accessed process data were tied to the access protocols of the communication network. The OPC standard software interface allows devices and applications from various manufacturers to be combined with one another in a uniform manner.
The OPC client is an application that accesses process data, messages and archives of an OPC server. Access is through the OPC software interface. An OPC server is a program that provides the applications from various manufacturers with a standard software interface. The OPC server is the intermediate layer between the applications for handling process data, the various network protocols and the interfaces for accessing these data. Only devices with operating systems based on Windows COM and DCOM technology can use the OPC software interface for data exchange.
OPCDA and OPCHDA
OPCDA and OPCHDA are communication protocols used in the industrial world and developed by the OPC Foundation (opcfondation.org). This technology has been replaced by OPCUA but is still widely used in the industry.
An HDA server allows the retrieval of historical data over a more or less long period of time, whereas a DA server allows the retrieval of only the most recent value of a tag.
OPCDA uses Microsoft’s proprietary DCOM technology to transfer information over the network. This technology is much more complex to set up than traditional TCP communications.
DCOM uses port 135 of the HDA server to exchange with the client. To do so, it is interesting to use the tnc command of the Windows Powershell installed as standard. Below, a test that fails (because of the firewall) then a test that succeeds:
If you have a problem, see the chapter on firewall configuration which is probably the source of the problem.
Preparing for authentication
An OPCDA client program will communicate with the DA/HDA server with the IP address or hostname of the server followed by the “progId” of the server. It will then have to be identified at the Windows level with a name and a password which are (by default) those of the user who launches the client program. This user must therefore be known on the HDA server as well. You must therefore either:
- Launch as “opcuser” with the password “H…..t! “which is known on the HDA server (shift click to get the “launch as user” menu)
- Create a user with the same password on the HDA server (assuming it is accessible).
- Be part of the same domain (so the user is accessible from all computers in the domain)
Important: The user must be a member of the “Distributed COM Users” group
Probably a communication problem: do the tests in step 1
Access rights that can be diagnosed using the server security log.
- Are the user and its password created on the HDA server?
- Is the user in the “Distributed COM Users” group on the HDA server?
Check the settings on the Client machine
The most likely cause is the configuration of a firewall between the two computers and/or at the hosting company in the case of machines on the cloud. On a Windows server, it is possible to configure the firewall by adding a rule on port 135:
In the case of a server hosted by Lightsail, there is an additional firewall in which a custom rule must be configured for port 135:
Check the settings on the Server machine
The OPC Foundation has provided a tool to allow OPC HDA clients to locate servers on remote nodes, without having information about those servers in the local registry. This tool is called OPCEnum and is freely distributed by the OPC Foundation. The PI OPC HDA interface installation installs OPCEnum as well. The primary function of OPCEnum is to inform or request information from other instances of OPCEnum about existing OPC HDA Servers on the local system. When OPCEnum is installed, it grants Launch and Access DCOM permission to Everyone and sets the Authentication level to NONE. This allows access to any user who can log on to the system. The permissions can be changed using
OPC HDA connector
The OIBus OPCHDA connector communicates transparently with the HDA agent. It is therefore configured in the same way than the other connectors. The following fields must be filled in:
- Address of the HDA agent file
- The TCP port to use
- The server address
- The server name
The HDA agent has its own logging level, which can be configured using the “Logging level” field in the HDA Agent category.
The server category also allows you to refine some parameters associated with the network:
- Retry interval: duration between two connection attempts in case of loss
- Max return values: maximum number of values returned by a request (the request is then split)
- Max read interval: the request interval is split into sub-intervals, particularly in the event of a recovery, to lighten the connection.
Finally, the scan group allows to indicate how the data should be aggregated on the specified scan mode. For example, if the scan mode every10Seconds is specified, the values will be aggregated according to the specified method in steps of 10 seconds.
The points can be listed by clicking on the “points” button. A pointId corresponds to the address of the data on the OPCHDA server.
History extraction with the HDA agent
It’ a common situation to have a large history of values available in a historian (PI/IP21) or an equipment (DeltaV) that can only be accessed with the protocol OPC-HDA.
OPC HDA is considered as the old version of OPC UA (the latest version OPC HDA 1.20 was released in 2003). The issue with this protocol is that it relies on DCOM technology from Microsoft quite difficult to configure (for example it uses “dynamic ports” not easy to setup with firewalls).
OIBus has a specific “agent” for HDA: “HDAagent”. HDAagent can be run in slave mode for the Continuous acquisition but has also a “command line” mode that is useful to debug and to import historical data.
- 1. Get HDAagent: The HDA Agent is delivered with OIBUS. You have to unzip the OIBus installation file and access to the folder HDAagent.
- 2. Test the installation: You can just run the command “HdaAgent help” that will display a small help about the usage:
- 3. Test connectivity to OPC Server: To do this, you can use the command “HdaAgent ping”. You need to know the OPC name of your server and its IP address. Note: it may be much easier to install OIBus directly on the server because it’s likely that the DCOM is already configured on the server.
- Get list of points (catalog)
To create the catalog with all points in the OPC Server (catalog.csv). It may take one hour to complete. You need to change the -h and the -s options accordingly.
hdaagent catalog -x debug -l info -h `<<`server ip`>>` -s `<<`server name`>>`This command will create in the current folder catalog.csv and also hdaagent.log (useful to check for any errors). The catalog.csv will be a list of tags that will be exported in the next step. It’s a text file that can be edited if needed.
- Import History
At this point, it is possible to start the export of the history of each point in catalog.csv. It can take days to complete. I would suggest starting on a small period (one week) for the initial test. After, you can go for longer period (maybe year).
The command will look like:
hdaagent bulk -x debug -l info -h `<<`server ip`>>` -s `<<`server name`>>` -b "2019-01-01 00:00:00" -e "2020-01-01 00:00:00”
This command will create one CSV file for each point in the catalog.csv. If for any reason the process fails, it is possible to restart it. The agent will only query points that are missing from previous run by checking if the corresponding file is already created.