OPCClient Object

The OPCClient object functions as the ArchestrA OPC Data Access Client for third-party OPC (OLE for Process Control) Data Access Servers. The OPCClient object provides functionality similar to OPCLink.

For more information, click on a Help topic.

; Overview

; Run-Time Behavior

; Configuration

; Run-Time Object Attributes

Overview

The OPCClient object is a key member of the core set of AutomationObjects within the ArchestrA system infrastructure. The OPCClient object is a DeviceIntegration (DI) object that allows access to a running OPC Data Access (DA) Server. A third-party OPC DA Server can provide data points to Galaxy application objects through the OPCClient object. Note The OPCClient object is compatible with all OPC Servers that are compliant with OPC Data Access v2.05 or later standards.

There is a one-to-one relationship between an instance of the OPCClient object and a running OPC DA Server. If you want to reference data points in more than one OPC DA Server, you must configure and deploy more than one OPCClient object. For example, you would need to configure one OPCClient object to communicate to an ABTCP OPC Server and another one to talk to the ABCIP OPC Server.

An OPCClient object supports the following operations on I/O points for the OPC DA Server:

; Subscriptions, which are implemented via scan groups. For more information, see

Scan Groups.

; Read transactions, which are implemented via block reads. For more information, see

Block Reads and Block Writes.

; Write transactions, which are implemented via block writes. For more information,

see Block Reads and Block Writes.

Important! If you are using this object to communicate with an OPC DA Server, you must properly configure the OPC DA Server before deploying this object.

Items in a scan group, block read, or block write are “dynamic” in that they are created or activated dynamically during run time.

For a block read, if the quality of a dynamic attribute changes, but a data value update is not received from the data provider, the current time of the hosting AppEngine is used as the new time stamp. If the data quality transitions to GOOD because a data update was received, the value and time stamp passed in with the data update is used for the attribute. For a block write, the time stamp of the attribute is updated to the time stamp provided by the set request. If no time stamp is provided, the current time of the hosting AppEngine is used. If the quality of an attribute changes because of a failed set request, the current time of the hosting AppEngine is used as the new time stamp.

For general information on objects, including relationships, deployment, and alarm distribution, see the Integrated Development Environment (IDE) documentation. For information on configuration options for object information, scripts, user-defined attributes (UDAs), or attribute extensions, click Extensions Help in the Help file header.

Related Topics

Run-Time Behavior

Configuration

Run-Time Object Attributes

OPC Data Access Server Security Settings In order for the OPCClient object to connect to a third-party OPC DA Server, certain security settings are required on the third-party OPC DA Server node.

Note These same settings must be applied to OPCEnum if the OPCClient is to use the server name instead of the progID.

If the OPC Server is a Wonderware DAServer, no additional configuration is required. The recommended settings are explained as follows. All of these setting can be set with Windows utility DCOMCnfg.Exe.

1. Run DCOMCnfg.Exe.

2. In the list of applications, select the OPC DA Server and then click Properties.

Note Under some conditions, the third-party OPC DA Server may not appear in the list of applications. In this case, you will need to create server specific AppID and run DCOMCnfg.Exe again. For information on creating AppID for COM objects, see the Microsoft documentation.

3. Click the General tab.

4. In the Authentication Level list, click None. (The default setting is "Default.")

The authentication level informs the component object model (COM) how much authentication protection is required, and it can range from authenticating the client at the first method call to encrypting parameter states fully.

5. Click the Security tab to configure who is allowed to launch permissions and access permissions to the server.

The launch permissions control the list of users who are granted or denied permission to launch a particular server.

You can control the list of users who are granted or denied access to the methods of a particular server by setting access permissions. You can add users or groups to the list, specifying whether access permission is being granted or denied. You can also remove users from the list.

When setting access permissions, you must ensure that both SYSTEM and Everyone are included in the list of users that are granted access.

6. Select Use custom access permissions and Use custom launch permissions.

7. For each of them, click Edit and then add "Everyone" and "System" to the list of users allowed to access and launch the server.

8. Click the Identity tab to configure the identity of the server.

An application's identity is the account that is used to run the application. The identity can be that of the user that is currently logged on (the interactive user), the user account of the client process that launched the server, a specified user, or a service. Thus, you can select from one of the following three options:

o The interactive user

The interactive user is the user that is currently logged on to the computer

where the application is running. If the identity is set to be the interactive

user, all clients use the same instance of the server if the server registers its

class factory as multi-use. If no user is logged on, the application will not run.

If the server has a graphical user interface (GUI) that the client needs to see,

you should use interactive user for the application's identity. However,

choosing this identity carries some security risks because the server runs

under the identity of the logged on user without the logged on user's

knowledge or consent.

o The launching user

This is the default setting for the application identity. When the launching

user is chosen for the application's identity, each client account gets a new

instance of the server, and each server gets its own WinStation. Because of

the separate server instances, launching user is the most secure identity

setting. However, there are limits on resource consumption. Also, any GUI

the server displays will not be seen by the client. Although this is the option

selected by default, we recommend to avoid selecting this option.

o This user

Specifying a particular user (and the user's password) is the preferred

identity for COM servers. The reason this identity is preferred is that no one

has to be logged on the machine where the server is running for the server to

run, and every client talks to the same instance of the server if the server

registers its class factory as multi-use. If the server has GUI, then you should

not choose this identity; if you do, the user will not be able to see the user

interface. Running as a fixed user account is more secure than the interactive

user identity because this identity can only be assigned to the application by

someone who has the specific user's password.

Related Topics

Overview

Scan Groups

A scan group, or device group, is a collection of user-defined attributes that have a common update interval. When you configure the OPCClient object, you will need to specify at least one scan group in order to deploy the object. Within each scan group, you can specify data items to use as the object attributes. At run time, items for a scan group will be updated with the latest values from the OPC DA Server according to the update interval. From other objects and from scripts, you can reference the attributes (items) you configured for the OPCClient object. For example, you might configure the input source for a FieldReference object to reference an item for one of the scan groups. Thus, the FieldReference object input source would be receiving data from an OPC DA Server via the OPCClient object.

Tip You can use any OPC client tool to browse a field device's address space for item names. The reference syntax for a OPCClient object data point is:

The <objectname> is the name that you choose to give to the OPCClient object.

The value of <itemname> depends on the type of OPC DA Server you are connecting to. For information on how to reference data points in the OPC DA Server, see the server documentation.

Run-time object attributes allow you to monitor errors related to the data quality for item values in a scan group.

Related Topics

Overview

Block Reads and Block Writes

A block read is a set of user-defined attributes for which you want to retrieve values in a single transaction. Instead of the I/O points being on advise, as with a scan group, the attributes are updated once per transaction. A block read must be initiated from a user or script via the BlockRead.TransactionTrigger attribute.

A block write is a set of user-defined attributes to which you want to write values in a single transaction. Only values that are new for the attribute since the last transaction are written to the OPC DA Server. A block write must be initiated from a user or script via the BlockWrite.TransactionTrigger attribute. You cannot trigger another transaction if the previous transaction has not completed.

Note Although block reads and writes are intended to be individual transactions, the actual communication with the field device is dependent on the number and type of attributes, and it may be necessary to send and receive multiple messages to and from the field device. As a result, the values exposed after a block read operation might have been obtained at different times. You must carefully design the logic in the field device to make sure that the values do not change until the full read operation is completed. In the case of a block write operation, the logic in the field device must not use the written values until the full write operation is completed.

For a block read, either all of the attributes will be updated or none of the attributes will be updated; no partial updates are supported. In the case of a block read failure or transaction timeout, the data quality for all attributes is set to BAD.

For a block write, partial writes are supported. However, the system does not offer roll-back functionality. In the case of a block write failure or transaction timeout, some values may have been successfully sent, but there is no way to undo the value changes. For items that have not yet been written to, the data quality is set to BAD.

Finally, run-time object attributes allow you to monitor errors related to the data quality for item values in a block read or block write operation.

Related Topics

Overview

Scan Groups

Run-Time Behavior

The following information describes the run-time behavior of OPCClient objects. Run-time

behavior is limited to the state of individual OPCClient objects. After it has been deployed and is operating, an OPCClient object can assume one of several

states, which are described in the following table:

State Behavior

Change

Startup In this state, the OPCClient object connects to the OPC DA Server.

Going None.

onscan

Running In this state, the OPCClient object:

onscan

; Services read and write requests.

; Receives values from the OPC DA Server scan groups (device

groups).

; Monitors the connection to the OPC DA Server.

; Detects alarm conditions, if alarming is enabled.

; Monitors the data quality for OPC DA Server data values and updates

run-time error statistics if the quality is not GOOD.

Going None. The ConnectionStatus attribute is set to "Disconnected."

offscan

Offscan The object is passive and does not service read and write requests.

Shutdown In this state, the OPCClient object disconnects from the OPC DA

Server.

Related Topics

Overview

Configuration

Run-Time Object Attributes

Configuration

The following section describes the object editor options for configuration and the associated

attributes:

; General Configuration

; Scan Group Configuration

; Block Read Configuration

; Block Write Configuration

For general information on objects, including relationships, deployment, and alarm

distribution, see the Integrated Development Environment (IDE) documentation.

For information on configuration options for object information, scripts, user-defined

attributes (UDAs), or attribute extensions, click Extensions Help in the Help file header. Related Topics

Overview

Run-Time Behavior

Run-Time Object Attributes

General Configuration

Use the General tab to specify the OPC DA Server from which to retrieve data and to

configure restart options.

Editor Associated Attribute Description Run-Time Option Access

(Supervisory,

User,

Read-Only,

None) Server ServerNode The name of the Supervisory, node node (computer) on User

which the OPC DA

Server is running. If

this attribute is

blank, the OPC DA

Server is assumed to

be running on the

local node.

Click the Browse

button to find the

network for the

node.

Server ServerName The name of the OPC Supervisory, name DA Server. The User

naming syntax for

the OPC DA Server

varies according to the type.

Run server ServerActivation If enabled, the OPC Read-Only

out-of-proc DA Server will be run

out-of-process. An in-process OPC DA Server runs as a .Dll

within the engine process. An

out-of-process OPC DA Server runs as a stand-alone

executable. The

method you choose depends on the methods supported by the OPC DA

Server and

performance

considerations.

To connect to the OPC DA Server

in-process, all of the following must be true:

; The OPC DA

Server must be

installed locally

relative to

where the

OPCClient is

installed.

; The OPC DA

Server must

support an

in-process

connection.

; The OPC DA

Server is not

currently

running

out-of-process.

; The value of

the ServerNode

attribute must

be blank.

; This Run

server

out-of-proc

check box must

be unchecked.

Use scan DAGroupAsAccessPath If enabled, the name Read-Only group of the scan group will name as be used for the OPC access path access path. Select

this option for OPC

DA Servers that

require a topic to be

specified for the

access path. You

must then make sure

that any scan group

you specify is named

the same as a topic

within the OPC DA

Server.

Restart RestartMax The maximum Supervisory, attempts number of times that User

the OPCClient object

should attempt to

restart a failed OPC

DA Server within the

restart period.

Restart RestartPeriod The time period, in Supervisory, period milliseconds, over User

which the maximum

number of restart

attempts applies. If

this time period

elapses before the

maximum number of

restarts is exceeded,

then the restart

count is set back to

zero.

Detect RestartAlarm.Alarmed If enabled, an alarm None restart will be triggered alarm when the number of

attempts to start the

OPC Server has

exceeded the

allowed maximum

within the restart

period.

Priority RestartAlarm.Priority See Alarm Supervisory,

Attributes. User Connection ConnectionHeartbeatPeriod The time interval, in Supervisory, heartbeat milliseconds, at User period which the OPCClient

object will check the

connection to the

OPC DA Server.

Detect ConnectionAlarm.Alarmed If enabled, an alarm None connection will be triggered alarm when the OPCClient

object can no longer

communicate with

the OPC Server.

Priority ConnectionAlarm.Priority See Alarm Supervisory,

Attributes. User Restart RestartReset Used to set security Supervisory, reset for restarting the User security OPC DA Server.

Related Topics

Configuration

Scan Group Configuration Use the Scan Group tab to add scan groups to the OPCClient object.

Editor Associated Attribute Description Run-Time Option Access

DOCSFORD

OPCClient Object