OPC DA

OPC DA, short for OPC Data Access, is an OPC standard that enables industrial process data to be shared between software applications in a standardized way.

The main purpose of OPC DA is to provide a common data access method between automation devices from different manufacturers and SCADA, HMI, data logging, reporting, and analysis applications that use the data collected from these devices.

OPC DA is not a direct PLC communication protocol. Typically, an OPC Server communicates with a PLC or another field device. The server then makes the data received from the device available to other applications according to the OPC standard.

For example, a temperature value from a PLC can be read by an OPC Server and then accessed through OPC DA by a SCADA application, data logging application, or another OPC Client.

OPC DA is primarily based on a Client / Server architecture. The OPC Server is positioned between the data source and the application that uses the data.

In a basic OPC DA system, data flows through the following stages:

In OPC DA, variables in field devices are generally referred to as Items or Data Items.

An OPC Item can represent a temperature, pressure, flow rate, motor status, valve position, power value, or any other process variable.

An OPC Server can present these data points within an address space using a hierarchical structure. An OPC Client application can Browse this space to find the available data points.

For example, an OPC Server may provide a structure such as:

Plant
 ├── Boiler
 │    ├── Temperature
 │    ├── Pressure
 │    └── SteamFlow
 │
 ├── Turbine
 │    ├── Speed
 │    ├── Power
 │    └── Temperature
 │
 └── Generator
      ├── Voltage
      ├── Current
      └── Frequency

This structure may vary depending on the manufacturer and the OPC Server software being used. The OPC DA standard defines how data access is performed; the actual Item names and address structure depend on the system being used.

In OPC DA, a process variable should not be considered only as a numerical or textual value. To use the data reliably, Quality and Timestamp information are also important.

The OPC Data Access standard has evolved through different versions over time. The OPC Foundation's OPC DA specification covers the development of versions 1.x, 2.x, and 3.0.

One of the important aspects of understanding OPC DA is understanding COM/DCOM technology. OPC Classic standards are based on Microsoft Windows technologies and use COM/DCOM for communication between software components.

COM (Component Object Model) is a Microsoft technology that enables software components running on Windows to communicate with each other through standardized interfaces.

DCOM (Distributed COM) is an extended architecture that allows COM objects to be accessed from another computer over a network.

Therefore, in OPC DA systems, the Client and Server can run on the same computer or, with appropriate Windows and DCOM configuration, on different computers.

DCOM configuration is particularly important for remote OPC DA connections from a system administration perspective. User permissions, computer security policies, and firewall settings can directly affect whether the connection works correctly.

OPC DA has been widely used for many years, particularly in Windows-based industrial automation systems, to allow different software applications to access the same process data.

• Provides a standardized data access model between systems from different vendors.
• Makes it easier for SCADA, HMI, Data Logger, and analysis applications to access the same process data.
• Supports fundamental data access operations such as Browse, Read, Write, and Subscription.
• Important information such as Quality and Timestamp can be transferred along with the data value.
• As it is a technology that has been used for many years, OPC DA support is available in a large number of existing industrial systems.
• Can be used to connect existing Windows-based automation systems to modern applications.

Although OPC DA has been successfully used in industrial automation for many years, it has some limitations in today's platform-independent and Internet-connected systems.

• Depends on Microsoft Windows and COM/DCOM technologies.
• DCOM configuration can be complex for remote connections between different computers.
• Windows Firewall and security policies can affect remote OPC DA connections.
• OPC UA provides a more suitable architecture for modern, platform-independent, and Internet-based applications.
• OPC UA is preferred in most new system designs instead of OPC DA.

Although OPC DA and OPC UA serve the same fundamental purpose, namely sharing industrial data between applications, their underlying architectures are significantly different.

The OPC Foundation describes OPC UA as the advanced, platform-independent generation of OPC Classic technologies. In addition to OPC DA, OPC UA brings OPC Classic functions such as alarms, events, and historical data access together within a more modern architecture.

Especially when the Client and Server are running on different computers, properly installing the OPC software alone may not be sufficient for OPC DA connections. Windows and DCOM configuration must also be checked.

• Check whether the OPC Server is running.
• Check whether the OPC Server is actually publishing the relevant Items.
• Check whether the OPC Client has selected the correct OPC Server.
• For a local connection, test whether the Client can access the Server.
• For a remote connection, check Windows user accounts and DCOM permissions.
• Check whether Windows Firewall and network communication allow the connection.
• Check whether the 32-bit or 64-bit architecture of the OPC Server is compatible with the Client application.
• If data can be read but the Quality information is not valid, first check the communication between the OPC Server and the field device.

OPC DA has been an important integration technology in SCADA systems, particularly for obtaining data from automation systems supplied by different vendors.

For example, a facility may contain PLCs from different vendors, DCS systems, or specialized control software. While each of these systems may use its own communication method, the OPC Server can provide data from these different sources to the SCADA system through a common OPC DA interface.

This allows the SCADA application to use a standardized data access method through the OPC Server as an OPC Client, instead of directly supporting the proprietary communication protocol of every device vendor.

This section will provide tools that can be used to work with OPC DA, test OPC Servers, Browse data points, read and write data, or develop OPC DA Client applications.

This section is currently under development. Free OPC DA tools, sample applications, test software, and utility tools will be shared here in the future.

OPC DA is an OPC Classic standard that has been used for many years to enable real-time data sharing between different software applications in industrial automation systems.

The basic architecture consists of an OPC Server that obtains data from field devices and one or more OPC Clients that use this data. Client applications can Browse and read data, write data when appropriate permissions are available, and monitor data changes through the Subscription mechanism.

OPC DA still plays an important role, particularly in the integration of existing Windows-based industrial systems. However, OPC UA may be a more suitable option for new systems due to requirements such as platform independence, security, and modern network communication.

You can get in touch regarding OPC DA, industrial communication, EOS software, or technical content.

• benanbasoglu@gmail.com
• ANKARA