logo-opclabs-new

Professional OPC Development Tools and Services

opc logo

OPC Glossary

Access Rights

Access rights allowed to a given item. Can be Read only, Write only, or Read/Write.

Asynchronous

Various OPC calls explicitly make use of asynchronous communication. When an OPC Client application issues an asynchronous call, the OPC Server acknowledges receipt of the call itself. The OPC Server then “calls” the OPC Client application back with the result using a callback. The OPC Client application does not know when it will receive the callback, and therefore the call is said to be asynchronous, or without time.

Developers and Integrators use asynchronous calls when they do not require a specific order of operations. Suppose that an operator must close two valves, but the order is not important. Furthermore, suppose that the first valve takes 5 seconds to close, and the second valve takes 1 second to close. Using an asynchronous call, the operator could issue both calls simultaneously, but the second call would actually complete first! However, if it is indeed necessary to complete the first action before the second begins, Developers and Integrators must ensure that they use Synchronous communication.

Asynchronous calls can provide a significant performance boost when an order of operations is not required. As well, developers use asynchronous calls to implement OPC Item subscription.

Using asynchronous communication, an OPC Server relies on callbacks to deliver data back to an OPC Client application. Integrators must configure the PC with the OPC Client application to accept the callbacks. Failure to do so will cause callbacks to fail and consequently any asynchronous communication will fail. This is a common cause for OPC Item Subscriptions to fail. Integrators often use synchronous communication to compensate for poor security configuration. However, this will have other undesirable affects.

See also: Callback, Subscription, Synchronous

Attribute

In the address space of the OPC Unified Architecture server, each node has a set of attributes, depending on the node class. Attributes can be read or written. The most important attribute is the Value, but there are other attributes as well, describing e.g. the rank of the value, the display name of the node, etc.

Authentication

Authentication is the process of determining whether someone or something is, in fact, who or what it is declared to be.

In the context of OPC Unified Architecture, the communicating applications (OPC Client and OPC Server) authenticate themselves mutually.

Browsing

An OPC interface that enables an OPC client application to view all of the available tag items of an OPC server.

Cache Read

OPC Server keeps the latest value of each item obtained from the device in its cache. The OPC client may call a Cache Read, and obtain the value from this cache. This operation is fairly efficient, but does not always provide the up-to-value that is currently in the device.

Callback

Microsoft Windows uses a callback mechanism to implement asynchronous communication.  When an OPC Client application issues an asynchronous call, the OPC Server acknowledges receipt of the call itself.  The OPC Server then “calls” the OPC Client application back with the result using a callback.  The OPC Client application does not know when it will receive the callback, and therefore the call is said to be asynchronous, or without time.

Using asynchronous communication, an OPC Server relies on callbacks to deliver data back to an OPC Client application.  Integrators must configure the PC with the OPC Client application to accept the callbacks.  Failure to do so will cause callbacks to fail and consequently any asynchronous communication will fail.  This is a common cause for OPC Item Subscriptions to fail.

See also: Asynchronous, Subscription

Certificate

In OPC Unified Architecture, certificates are used to prove the authenticity of communicating parties.

CLSID

CLSID is a 128 bit number that represents a unique id. The id is for a class of COM objects. In OPC "Classic", OPC Servers expose COM objects, and therefore are identified by CLSID as well. CLSID is difficult to work with for humans; for this reason, OPC clients usually allow the server be identified by its ProgID, or description.

COM (Component Object Model)

Component Object Model (COM) is a Microsoft concept used to communicate between components on the same computer. Components from different machines can be combined using DCOM.

DCOM (Distributed COM)

Distributed Component Object Model (DCOM) is a set of Microsoft concepts and program interfaces in which client program objects can request services from server program objects on other computers in a network. DCOM is based on the Component Object Model (COM), which provides a set of interfaces allowing clients and servers to communicate within the same computer.

DCS (Distributed Control System)

DCS (Distributed Control System) is a type of automated control system that is distributed throughout a machine to provide instructions to different parts of the machine. Instead of having a centrally located device controlling all machines, each section of a machine has its own computer that controls the operation. For instance, there may be one machine with a section that controls dry elements of cake frosting and another section controlling the liquid elements, but each section is individually managed by a DCS. A DCS is commonly used in manufacturing equipment and utilizes input and output protocols to control the machine.

Deadband

A deadband can be defined as the minimum percentage of a given range or amount by which a measured value must vary in order for the device or computer to register a change.

Device Read

A Device Read requires the OPC server to obtain the latest value from the device (as opposed to providing the value from the server cache). The Device Read is generally very inefficient, and it should be avoided.

Discovery

Discovery is a process by which OPC applications (OPC servers and clients) can be found on the network or in the enterprise. The term is mainly used with OPC Unified Architecture; in OPC "Classic", only servers can be discovered, and it is often referred to as browsing for servers, or enumerating servers.

DLL

A DLL is a library that contains code and data that can be used by more than one program at the same time.

Group

A collection of data items in an OPC Server. OPC Groups are created by the OPC client inside the OPC server, they are not pre-defined by the OPC server (except for so-called public groups).

HMI

An HMI, or Human-Machine Interface, is a device or software that lets users communicate with a machine or automation system. Besides translating complex data into useable information, an HMI relays the user's commands.
By providing information, alerts, commands and other tools, an HMI connects the user with the process being controlled. So the more adapted the tools are to the user, the more appropriately he or she can react.
An intuitive, user-friendly HMI can make the difference between an inefficient system and a cost-effective one.

Inproc

In process. In context of OPC, in-proc OPC Servers are typically DLLs that are launched by and controlled by OPC Clients. Advantages include performance and ease of DCOM configuration

Interface

A COM interface defines a set of methods that an object can support, without dictating anything about the implementation. The interface marks a clear boundary between code that calls a method and the code that implements the method.

OPC "Classic" standards define a set of interfaces that objects in the OPC server must implement.

Item

A piece of data (from a device) in an OPC server.

Namespace

OCX

OLE Object: An OCX is a software object that can be embedded into any Microsoft Windows product that supports Object Linking and Embedding (OLE).

OLE

Object Linking & Embedding: The term Microsoft coined for their technology that allows you to embed documents, parts of programs, etc. created with one Windows program in to another. For example, using OLE, you can embed an Excel spreadsheet into a Word document.  If you want to edit the spreadsheet, you just double click on it, and your menus change over to the Excel menus, and you edit the document in place, without ever leaving Word.

OPC-UA (OPC Unified Architecture)

 The "classic" OPC interfaces, Data Access, Alarms&Events and Historical Data Access (DA, A&E, HDA) are based on the Microsoft COM/DCOM technology (Component Object Model) and therefore can only be run on Microsoft operating systems. The new OPC-UA specification defines a Service Oriented Architecture (SOA), which is platform independent and which functionally includes and unifies all legacy versions of OPC. The new communication stacks for ANSI C/C++, Java and .NET implement the low level protocol features. Additionally, message signing and encryption, as well as authentication and authorization via X509 certificates are already included. The most significant innovation of OPC-UA is the extensive support for information modelling. Information entities (Nodes) and relationships between them (References) follow an object oriented design paradigm. Not only the data itself, but also the related metadata, including their semantics can be generically described and transported over the network.

OPCAuto.dll

OPCAuto.dll is so-called OPC automation wrapper. It is an obsoleted technology, originally developed to allow VB6 (Visual Basic) programs to connect to OPC servers.

OPCEnum

OPCEnum is a component that provides a list of OPC server installed on the machine to OPC clients. OPCEnum usually runs as Windows service. OPCEnum is installed as part of OPC Core Components.

ProgID

The ProgID is a alias for a COM component registration. Instead of referring to a COM component through it's CLSID, there is also a mapping from a more friendlier name, the ProgID, to the CLSID. This PROGID - CLSID mapping is also stored in the registry of the computer.

OPC "Classic" servers on a computer are usually identified in the OPC client application by their ProgId-s.

Property

In OPC Data Access, every OPC Item may have so-called properties that contain further information about the item. Example properties would be the access rights or a description of the item.

In OPC Unified Architecture, properties exist as well, but are implemented as nodes in the address space, with a dedicated reference type.

SCADA

SCADA (supervisory control and data acquisition) is a category of software application program for process control, the gathering of data in real time from remote locations in order to control equipment and conditions. SCADA is used in power plants as well as in oil and gas refining, telecommunications, transportation, and water and waste control.

SCADA systems include hardware and software components. The hardware gathers and feeds data into a computer that has SCADA software installed. The computer then processes this data and presents it in a timely manner. SCADA also records and logs all events into a file stored on a hard disk or sends them to a printer. SCADA warns when conditions become hazardous by sounding alarms.

Subscription

The subscription mechanism enables OPC Client applications to receive multiple updates from OPC Servers.  When an OPC Client application (HMI, Historian, etc) subscribes to OPC Items, it receives all updates as soon as the OPC Server detects the change.

To implement subscription, DCOM-based OPC servers use callbacks, and the call is thus asynchronous.

OPC UA Client applications implement subscription using a poll-report-by-exception mechanism.  Thus, the OPC UA Client application polls the OPC Server once, and receives a result for all the item changes.  This mechanism also enables OPC UA Client applications to implement a heartbeat, which enables them to know when they lose their client/server connection.

See also: Asynchronous, Callback

Synchronous

Various OPC calls explicitly require the use of synchronous communication. When an OPC Client application issues a synchronous call, it will wait for the OPC Server to provide the required result. This functionality makes it easier for developers to implement interlocks that necessitate a specific sequence of events. For example, when a specific operating procedure necessitates opening a valve before turning on a pump, developers can first use a synchronous call to open the valve, and then use a synchronous call to turn on the pump. The synchronous operation ensures that the first action (opening the valve) executes completely before the second action (turning on the pump). By contrast, an asynchronous call does not ensure that one action is complete before another action is taken. Integrators can also use synchronous communication when they must implement interlocks.

Synchronous calls can also cause OPC products to slow down. This is because synchronous calls will be implemented in sequence. Therefore, if applications use synchronous communications when End-Users do not require a specific order of operations, the associated products will perform unnecessarily slow.

Integrators often use synchronous communication to get around poor configuration of DCOM security. This will cause an unnecessarily high load on OPC Servers, as well as poor performance of OPC Client applications.

See also: Asynchronous, Callback

TCP/IP

The protocol (language- see definition of protocol), used on the Internet and many office networks.

Update Rate

The rate, in milliseconds, at which group data is updated.

 

 

 

 

 

 

Add comment


Security code
Refresh