OPC DA – OPC Data Access

The original OPC standard was introduced to avoid this process data Babylon. The OPC Foundation, founded in 1996 as a non-commercial organization, was in charge of this. Members of the OPC Foundation are representatives of leading companies in the automation industry.

The aim was to create a globally accepted standard for communication in automation technology.

OPC DA – Classic OPC

OPC DA is not actually a network protocol. However, OPC DA is still an important industry standard and, depending on the end device, can also have points of contact with network communication.

OPC stands for OLE for Process Control, where OLE is the abbreviation for Object Linking and Embedding. The basic idea of ​​OLE is the controlled embedding of documents from other applications in your own application, for example inserting an Excel document in a Word file.

Both OLE and OPC were specially designed for PCs with Windows operating systems and only work on Microsoft operating systems.

OPC-supported applications do not communicate directly with the end devices addressed. Instead, an OPC server is installed for the corresponding end device. The OPC server is a software process that handles manufacturer-specific communication with the end device in the background – similar to a driver for hardware on your own PC. The process data made accessible in this way is processed according to the OPC standard and transferred to the application in a standardized form.

The part of the application that communicates with the OPC server is called the OPC client.

The following example shows access to a Wiesemann & Theis Web-IO 12xDigital using an OPC server:

Access via OPC

With the original OPC interface, a distinction is made between four main tasks:

• Data Access: DA for short, describes the exchange of real-time data via OPC.
• Alarm & Events: AE for short, is used for alarm and event handling.
• Historical Data Access: HDA for short, allows stored, historical values ​​and value progressions to be made accessible.
• Data Exchange: DX for short, allows OPC servers to exchange data with each other.

OPC treats the process data as individual data endpoints. A data endpoint can be a measured value, a process status, a switching status and much more. The individual data endpoints are referred to as items. Depending on the type, the items can be read or written.

All items have an item ID, an address that is unique within the OPC server, i.e. unambiguous. Each item has an indefinite number of properties or item properties, such as B. value, quality, timestamp, etc.

The items are usually combined into groups by the OPC server. This results in a kind of hierarchy (OPC server > OPC group > OPC item).

In order to give the OPC client easy access to all available items, many OPC servers allow the OPC client to do OPC browsing. The OPC client can use this to query all items in a kind of directory tree structure. Here as an example the structure of the items of a W&T Web-IO 2xDigital and a Web-Thermo-Hygrobarometer.

Communication between OPC client and OPC server

The OPC client can select a subset (or all) from all the items offered by the OPC server and combine them into one or more groups. These groups do not have to be identical to the groups formed by the OPC server. The selected items are then subscribed to in groups by the OPC client. This means that the OPC client does not have to constantly query the status of the items, but is automatically informed by the OPC server if one of the properties of an item changes. In this way, the OPC server relieves the OPC client and thus the application.

When does it make sense to work with OPC DA?

Whenever a flexible application is to be created that needs to exchange data with hardware from a wide range of manufacturers without great effort, OPC is the ideal solution.

In applications of process control technology and process and measurement data visualization, OPC is a fine thing, especially for the user.

Despite all the advantages of OPC technology, it should not be concealed that programming a universal OPC client application is a complex task that requires a high level of programming competence.

So when it comes to creating a special application for a special end device from a manufacturer, you should consider whether it might not be easier to use the direct communication path provided by the manufacturer.