Access to OPC DA Data
References
Introduction to OPC - https://www.youtube.com/watch?v=E6ELXwzJFgE
OPC Server and Client Data Communications - https://www.youtube.com/watch?v=u6E9uAtyhow
OPC DA and UA DCOM and security issues - https://www.youtube.com/watch?v=0kLXepCuyOw
OPC DA Overview - https://www.win911.com/Enterprise/1/14/1/OPC-DA_Overview.htm
OPC DA Security and Data Access
The OPC DA server standard was in use during the years 1995-2009. The OPC DA defines real time data, OPC HDA defines historical data and OPC AE defines alarm and events access. These are also known as "Classic OPC". These have all been replaced by the next generation known as OPC UA (Unified Architecture).
OPC DA operates on a client/server model. It was originally developed as a way to allow a single OPC DA server to communicate with one or more proprietary PLCs or other SCADA devices. Usually these PLCs or devices were connected via serial lines, before the widespread use of Ethernet on plant networks. The OPC DA would use inbuilt drivers to talk the (usually) proprietary language to get data, or control, to/from the PLCs/devices. The OPC DA standard was built around the Windows operations system, and sharing out data via DCOM (Distributed Common Object Model).
OPC DA Client/Server communications across an Ethernet network are authenticated using DCOM, which is a low level network interface ONLY available on Windows machines. DCOM is not required if talking to an OPC DA server on the local Windows machine (ie; not across a network). It is required if talking to a server across a local or remote network. DCOM dates back to Windows NT (in the early 1990s) and introduces very serious security vulnerabilities, even on a local plant's Ethernet network. This DCOM interface IS NOT SECURE and should not be used in a modern network. See Reference 1 (above) from the US Cert, which recommended it not be used back in 2006. Opening up DCOM access on a plant network will almost certainly expose the OPC DA server to viruses (including ransomware) attacks very easily. Configuring DCOM for maximum security is far from trivial and requires an experienced Windows security network engineer. Not only does DCOM need to be configured, but only Windows clients in the same Windows Domain or Workgroup would be allowed to access the OPC DA server. Overall, opening up access to an OPC DA server represents very significant security risks that are not recommended by Ardexa.
Recommendations
The options to obtain data from legacy OPC DA servers are as follows. Note that some of these options are not recommended. These are presented in order.
Install an OPC DA gateway. This does not change the OPC DA server, and it means that data can be accessed via a much more secure OPC UA connection. There are many software gateways available such as the "Kepware OPC Connectivity Suite", the "Cogent DataHub OPC Gateway" or the "Unified Automation OPC Expert". There are many more. Most of these are under $1000, some are significantly cheaper. Ardexa uses OpenOPC (https://github.com/sightmachine/OpenOPC), which is free and allows secure access to the OPC DA data without exposing it on a network via OPC DA.
(Not recommended). Get the data directly from the source, eg Port 102 for Siemens PLC, or via Modbus. This may not be possible if the OPC DA server connected to the PLCs/devices via serial line(s). And allowing Ethernet connections to old, legacy equipment may introduce many more, very serious, security issues.
(Not recommended). Get an OPC DA client to talk to the OPC DA server. This will require DCOM security on the Windows OPC DA server to be configured so that a client can access the Windows. Unless someone with very detailed knowledge on DCOM security configures the DCOM security access, serious security vulnerabilities will be introduced. In any case, DCOM has security vulnerabilities which cannot be patched.
Last updated