A Technical Overview of the OPC Dataaccess

A Technical Overview of the OPC DataAccess
Interfaces

Al Chisholm

Chief Technical Officer

Intellution Inc

1 Edgewater Drive

Norwood, MA 02062

781 769 8878

KEY WORDS

OPC, COM, DCOM, Windows, NT, I/O, Standards, Data, Realtime

ABSTRACT

This paper presents a fairly detailed technical overview of the Data Access interfaces. It begins by describing the problem these interfaces are designed to solve, the functionality they provide and the object model they employ. Following this is a review of the specific interfaces provided, including a brief discussion of the specific methods exposed by those interfaces.

A REVIEW OF THE PROBLEM

This paper contains a fairly detailed technical overview of the OPC (OLE for Process Control) Data Access Interface. It assumes that the reader has some technical background in COM (Component Object Model) and object oriented programming. This paper will also talk about where OPC Data Access fits in the architecture of a control system and about the objects and methods that the OPC Interface presents to the programmer.

In addition to talking about WHAT the objects look like, this paper will also talk a bit about WHY they look the way they do. Which is to say it will try to answer the question, “What were those guys thinking when they designed this stuff…”. This paper talks primarily about the Custom (C++) interface as that is what server vendors and most serious client vendors need to understand and implement.

The left figure above illustrates ‘The I/O Driver Problem’. Clearly each software driver for a new device requires a unique, device-specific chunk of code to talk to the device or network. The need for this device specific code is not a problem OPC is trying to address. Rather, this is something Fieldbus is trying to address, and Devicenet, and Profibus, and Lonworks, and a host of others.

The problem that OPC deals with is that each of these software drivers also presents a different software interface to the calling application. As a result, each application also requires a unique chunk of code for each driver, device or network it wants to connect to. This obviously makes it difficult to reuse applications with different sets of process interface equipment.

OPC Solves this problem be creating a ‘software bus’ as shown in the right hand figure. Applications only need to know how to get data from OPC data sources. As a result, they are simpler, smaller and easier to use. Device Drivers (servers) only need to know how to provide data in a single format (OPC Server). As a result they are easier to write (and there is more of a market for such servers).

Although the MAIN problem OPC solves is the ‘I/O Driver’, you can see in the figure above that OPC is flexible enough to be used not only between Devices and SCADA, SoftPLC or DCS systems, but also between the SCADA SoftPLC or DCS engines and the high level applications such as HMI, Trends, Reports, etc. which use their data. In this architecture, the SCADA system, the DCS system or the SOFTLOGIC system really just represents a ‘smarter’ device.

THE TECHNOLOGY

Now for some technology basics… Why, for example, does OPC use COM? COM is Microsoft's Component Object Model which is the ‘90’s’ way to do APIs (subroutines). In addition to being widely used, another advantage of COM is that Microsoft provides a lot of the useful common ‘plumbing’ required to connect the clients and servers. This includes DCOM (Distributed COM) which allows creation of network-based applications with a minimum of development effort.

As noted earlier OPC is flexible enough to be used at different layers within the system architecture and is specifically designed to work well over a network. Efficiency is insured by the fact that (a) OPC can be exception based and (b) unlike DDE, OPC can pack 100s or 1000s of data items into each transaction. Performance is also guaranteed both by the support for multiple data items per transaction and by the fact that COM and thus OPC servers can be created in several models; inprocess, local and remote. For the highest possible performance, Inprocess servers incur 0 overhead. Millions of transactions per second are possible using this approach. Local servers allow 1000s of transactions per second. Even remote servers can manage 100s of transactions per second. And again, unlike DDE, each transaction can include many data items.

THE LOGICAL OBJECT MODEL

The OPC interfaces look the way they do largely because of the assumptions the OPC working group made about the applications. The main assumptions are listed below.

·  Apps are interested in a subset of the Tags available within the underlying Control system.

·  Apps are interested in many different subsets of Tags at different times and at different resolutions.

·  Apps want to be independent of the process objects

It is important to stress that first point. A fundamental assumption is that there is some sort of control or monitoring engine running independently of anything OPC is doing and that OPC is just a window into this engine’s data. That last assumption is the only controversial one. This issue will be discussed again below. In any case, these assumptions lead logically to the model in the following figure.

At the top of this figure is an OPC Server object . This is the COM object to which the application first connects. Below this is a collection of OPC Group Objects. These are created dynamically by the applications to hold lists of Tags and attributes (which OPC refers to as Items). An HMI might create a Group for each open picture. A report package might create a group to access data for each report. The contents of the Group and item collections may vary over time based on the needs of the applications. (Again this has no effect on the underlying control system). This is actually somewhat analogous to RowSets as used on OLEDB. There is a lot of data in the database, you want to look at a subset of it in your application., and that subset may vary based on your needs at the time.

Which brings us back to the assumption about process object independence. There were two fundamental approaches which could have been taken to this; the first is the ‘rowset’ approach seen here. The second is a more purely object oriented approach in which the server would ‘proxy’ the process objects and expose their properties and methods to the applications. The OPC working group felt the pure object approach was basically much to complex. Two issues in particular were those of efficiency and getting the vendors to agree on the nature and properties of the specific objects. Do note that the OPC approach does allow a vendor to expose data from an OODB through a very flexible names space.

TYPICAL SERVER DESIGN

The figure above shows a typical server design. The SERVER provides management of the OPC Groups and also controls, mediates and optimizes access to the physical devices by multiple clients. The Server is essentially an I/O Driver which ‘understands’ how to talk to some vendor specific data provider (hardware or software) and which Exposes the data from this data provider via the standard OPC Interfaces. The OPC sample server available at the OPC web site provides a very good implementation of the upper two layers of the diagram. Various commercial toolkits provide frameworks or implementations of one or more additional layers.

THE GROUP AND THE ITEM

The GROUP provides a convenient way for an application to organize the data it needs. Different Groups can be used by different parts of the application; can have different refresh rates; can be polled or exception based. Operator Displays, Recipes, Reports might each use one or more groups.

The ITEM provides a connection point to a value in the physical device. Typically this is a single variable such as a process value or setpoint. The ITEM provides information to the client; Value, Quality, TimeStamp, and Data Type. As mentioned before, the OPC item is a transient object which exists within the OPC server. It is used to create a connection between the server and the real data.

The OPC interfaces always return the process data in a VARIANT. It is assumed that the server has a ‘native’ or ‘prefered’ datatype which is also known as the canonical datatype. OPC allows clients to read this canonical type (e.g. 4 byte float). It also allows them to specify that they want the data returned in some other format (e.g. ASCII).

THE SERVER INTERFACES IN DETAIL

·  IOPCServer

·  IOPCBrowseServerAddressSpace (optional)

We will now review the interfaces on these objects in more detail discussing first what functionality they provide and then listing the methods of each interface to show how that functionality is provided.

The Server interfaces are listed above. They allow the application...

·  To create and delete groups

·  To browse the available tags

·  To translate error codes into meaningful text

·  To obtain status information about the server

IOPCServer

·  AddGroup

·  RemoveGroup

·  GetGroupByName

·  CreateGroupEnumerator

·  GetErrorString

·  GetStatus

The IOPCServer Interface allows the client to manage Groups. This is done using the Add, Remove, Get and Enumerator functions. GetErrorString allows the client to translate errors (HRESULTS) into strings. GetStatus allows the client to monitor the overall status of the server.

IOPCBrowseServerAddressSpace

·  QueryOrganization

·  ChangeBrowsePosition

·  BrowseOPCItemIDs

·  GetItemID

The browser interface (which is optional but which any worthwhile server should provide) allows the application to browse the tag names and attributes available within the server. It is carefully designed to work with essentially any organization; from a flat list of PLC registers to a hierarchical area/group/loop organization to a fully object oriented database. It does this by mapping all of the above into a hierarchical name space. This is intended to allow the application to present the results in an Explorer like browse tree. QureryOrganization tells the client if the space is flat or hierarchical. If the space is hierarchical, ChangeBrowsePosition moves up and down the hierarchy. BrowseOPCIDs returns an enumeration of the leafs or branches at a particular node. GetItemID returns the fully qualified name of an item. (This allows complete independence from the syntax and delimiters used by the vendor).

THE GROUP MANAGMENT INTERFACES IN DETAIL

The Group Interfaces allow the application

·  To add and remove items from groups

·  To Manage the accuracy (update rate) of the data in the group

·  To read or write values for one or more items in a group

·  To Subscribe to data in the group on an exception basis.

Note that the ITEM is not defined as a COM object and does not expose any interfaces in the Custom model. There are a variety of reasons for this, most related to the efficiency and complexity of the server.

IOPCGroupStateMgt

·  GetState

·  SetState

·  SetName

·  CloneGroup

After a client creates a group, IOPCGroupStateMgt allows control of the behavior of that group. It can change the name or update rate and a few other parameters of the group. It can also activate or deactivate the group. For example, an HMI might want to deactivate a group (but not delete it) if the display page using that group was minimized or hidden. CloneGroup can also create a copy of the group.

IOPCitemMgt

·  AddItems

·  ValidateItems

·  RemoveItems

·  SetActiveState

·  SetClientHandles

·  SetDatatypes

·  CreateEnumerator

IOPCitemMgt allows the client to add items to the group. For example, an HMI might create a group for each display page and then add to those groups all of the items referenced by that page. The most important functions here are AddItems and RemoveItems. The other functions are basically bells and whistles.

THE GROUP READ/WRITE INTERFACES IN DETAIL

There are 3 ways for a client to read data from an OPC Server Group; sync read (polled), async read and exception (subscription). The sync and async read work with specific lists (subsets) of items from the group which are provided by the caller. The subscription sends back any item in the group that changes. The interfaces which allow these operations are described below.

IOPCAsyncIO

·  Read

·  Write

·  Refresh

·  Cancel

The Asynch functions work in combination with the callbacks (IAdviseSink). The Read and Write functions ‘launch’ an asynchronous request for one or more items. The server works in background to get the data and then returns the data for those items to the caller via a callback. (a completion event).

The Refresh method works in combination with the subscription mode. It tells the server to pretend that all of the data items have changed. As a result, fresh copies of all of the items get sent back.

IOPCSyncIO

·  Read

·  Write

This interface supports very straight forward polled reads and writes. The client provides a list of items to read and gets back a list of values and/or errors or provide a list of items and values to write and gets back a list of errors. These functions always run to completion.

IDataObject

·  DAdvise

·  Dunadvise

The IDataObject is a standard Microsoft interface. OPC requires that vendors provide the DAdvise and DUnadvise methods. These are used to hook up callbacks which are used by the async and subscription modes of data access. Clients which do synchronous reads do not need to use this interface. Specifically, this interface works in combination with IAdviseSink on the client side. Note that the groups operate independently. The client can poll, subscribe or do asynch I/O to different groups.

THE CLIENT SIDE INTERFACES

On the client side, there is one ‘callback’ interface required in order to do synchronous or exception based I/O. This is a standard Microsoft interface called IAdviseSink. The only important method the client needs to implement is OnDataChange. The client will get a callback into this method if any of the following occurs: