Scribd
Upload
11 views

Norme_1

Uploaded by

matteoborgogelli75
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
11 views

Norme_1

Uploaded by

matteoborgogelli75
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

DeltaV Whitepaper

January 2013 Page 4 OPC Alarms and Events Overview


Introduction
The OPC Foundation developed the OPC Data Access specification in 1996 to address the need for a common
communication interface for transferring real-time process control data. The OPC Data Access specification
defines a standard interface that allows applications to access real-time process control data from a variety of
devices. The applications must implement one OPC Data Access compliant driver to access data from any OPC
Data Access compliant server. The OPC Data Access specification has been widely adopted and is the standard
communication mechanism for transferring real-time process control data.

The OPC Alarms and Events specification follows the same ideas set forth in the original OPC Data Access
specification, only the Alarms and Events specification addresses real-time alarm and event data as opposed to
real-time process control data. Released in 1999, the OPC Alarms and Events specification was developed to
address a common communication interface for transferring real-time alarm and event data in the process control
environment.

History of OPC Technology


OPC is based on the OLE (Object Linking and Embedding)/COM (Component Object Model) standard from
Microsoft. OLE/COM was designed by Microsoft to be extensible by others. This allowed OPC to be developed on
top of an existing technology, rather than inventing a completely new technology. It also provided a large number
of clients for the OPC server data in the applications that are already OLE aware. Because the technology behind
OPC is based on Microsoft OLE/COM, OPC must operate in a Microsoft-based environment.

OPC provides for a high degree of interoperability between client and server applications supplied by different
suppliers. In the past, client application suppliers had to develop a different driver to interface with each control
device. The OPC standard provides the client application suppliers the benefit of now only having to develop one
driver to access data from a process control device. These situations are both shown in Figure 1.

If the control device supplier modified the interface to the device, the client supplier would also have to modify the
software from the details of the various systems below the OPC interface.
The device supplier is able to modify the functionality under the OPC server interface without affecting the client
software. Client suppliers can now expend resources on true value added activities for their products in place of
the effort required to maintain a library of device drivers.

Using the OPC specification, end users can chose the client application that best meets their needs. In the past, a
user had to use specific client software that provided an interface for a particular control device. With OPC, any
OPC compliant client application can interface to a control device with an OPC compliant server. In this way, the
user gets the best solution for a particular task.

Another benefit comes from lower integration costs and risks. With plug and play OPC compliant components,
available from a variety of suppliers, the system integrator can spend more time on the final integration goal and
less time developing custom drivers. Since the solution is based on standard OPC components rather than
custom drivers, the project risk is lower.

You might also like