The RTDB OPC Client communicates with one or more OPC COM or OPC UA servers to fetch and send information between RTDB and the remote system. The OPC is a (COM) Interface, and the specification is defined by the OPC Foundation. For more information about OPC, see OPC foundation's website. OPC UA is a platform-independent interface specification that uses TCP/IP or Web Service communication.

OPC communication is based on client and server components. The client is the active part and creates the connection to the server and decides what to do and when (however, when using callbacks, the situation can be vice versa in a sense). There are different OPC specifications for the data access (DA), historical data access (HDA), alarms, and events (AE) transport, as well as Unified Architecture (UA). The RTDB OPC client can use each of these types of communication.

The OPC DA (Data Access) communication transports current values of measurements. The measurements to be collected are gathered to so-called OPC groups. The measurements that belong to a given OPC group all have a common transport time cycle and accuracy requirements. The transport time cycle is called the transfer rate, and the accuracy is called the dead band definition. The dead band means a percentage of the measurement range (the measurement range is the range known by the server-side, not the minimum and maximum values defined to the RTDB variable). For example, a transfer rate could be 10 seconds, and a dead band could be 0. This means that the values of the measurements are transferred to RTDB after any detected change (since the dead band is 0), but measurements are not transferred to RTDB more frequently than once in 10 seconds.

The RTDB OPC Client is able to transfer current value process data from any compatible OPC DA server. It is also able to fetch and store scan profiles from some sources (such as Honeywell Measurex DaVinci OPC server).

The RTDB OPC Client is also able to connect to the Alarms & Events OPC server, subscribe events from the server, and store the events to the RTDB EventLog and OpcEventLog tables. If the same OPC server can act both as DA server and AE server, only one connection to the OPC server is needed if both measurements and alarms need to be transferred.

The RTDB OPC Client supports the history data access (HDA) specification. It can connect to HDA servers, fetch history data, and store it as either current values or history values to the RTDB database.

The term "OPC Server" in this section of this article means any type of OPC server (DA, AE, or HDA). However, in some cases, it may mean only OPC DA Server (because this was the first OPC standard specification supported by RTDB OPC Server).

The RTDB OPC Client can also communicate by using the OPC Unified Architecture specification. Notice that the UA is a completely separate set of interfaces and also covers the transport ne

OPC (COM) capabilities

In short, the RTDB OPC client is able to produce RTDB current values or history values from OPC DA 1.0 servers by using polling (synchronous read), and from OPC DA 2.0 (and up) servers by using polling or event-based data transfer. It is able to get alarms and events from OPC AE 1.0 (and up) servers by using event-based communication and stores them to the RTDB EventLog table. It is able to get raw history values from HDA 1.20 (and up) servers and store the results as current or history values.

The data retrieval must conform to the spirit of the OPC standard. I.e., the measurements have a name, value, timestamp, and quality. These correspond one-by-one to the RTDB current values of RTDB variables. There are also some additional capabilities for data transfer (for example, by using vectors, or getting QCS data). The subsequent sections describe how these can be used.

The RTDB OPC client is also able to write data to the OPC server by using the RTDB sendoutputrequest and CTS-sender mechanism.

📘

Version info

The writing of Text valued variables has been supported since RTDB 4.5.

The following tables present the details of how the RTDB OPC client uses the OPC standard.

OPC server interfaces

OPC group interfaces

OPC event subscription interfaces

OPC HDA server interfaces

The RTDB OPC client is able to create a DCOM connection to a remote machine by using CoCreateInstanceEx, and passing a username and password for the connection. The credentials are also defined for each interface by using CoSetProxyBlanket. This way, the OPC client does not have to be run under the username that is needed to communicate with the remote OPC server. This also enables that the OPC client may connect to several OPC servers concurrently, and using a separate username/password for each connection.

OPC UA capabilities

RTDB OPC client is able to communicate with OPC UA servers by using the OPC UA specification 1.03. Production of RTDB current values or history values, and writing of values to the UA server by using output type variables and the CTS server mechanism is supported. Most UA-specific features are available, such as specifying the queue size and separate sampling interval for the monitored items. The transport of history values is not yet supported. The write functionality has been available starting from version RTDB 4.6 / 2015-01-03. The functionality to read and store events has been available from version RTDB 5.1 / 2017-10-10.

If the OPC Client has been configured to connect to a UA Server, and the used security mode (UaMessageSecurityMode) has been configured to some other value than “None”, the OPC Client itself generates a self-signed UA application instance certificate, if the certificate has not yet been created (and also if its valid time is over). The SimpleConfig settings can be defined to override some default parameters used in the certificate creation. The OPC client stores the certificate to the Local Machine certificate store location and store name RTDBOpcUaClient. To see the generated certificate, you can start mmc.exe, add snap in Certificates, select the “Computer account”, and then find the certificate from the RTDBOpcUaClient folder. (It is also possible to use a SimpleConfig setting to use the Current User account instead as the certificate store location, for example to test the program without the need to run the process with administrator privileges).

When the security has been enabled and the OPC client connects to the OPC UA Server for the first time, it stores the OPC server application instance certificate to the Windows certificate store (to the same place as the client application certificate mentioned above). The OPC client saves the thumbprint of the certificate to a SimpleConfig entry that has the OPC server SID in the key name (for example UaCert.thesid). When the OPC client subsequently connects to the same server, the OPC client verifies that the server is still the same as during the first time. If the OPC UA server has been reinstalled and its application instance certificate has changed, the RTDB OPC UA will refuse to connect to the server, unless the user removes the SimpleConfig setting or the OPC server certificate from the RTDBOpcUaClient certificate store. If it is important that the certificate check is done even during the first connection, the server certificate thumbprint can be configured to the connection (by using the UaServerCertificateThumbPrint setting), or by using the UaServerCertificateToDownloadFolder option.

If the UA server certificate issuer is such that is not yet trusted by the OPC client computer, you need to import the issuer certificate to the "Trusted Root Certification Authorities" (if it is root) or "Intermediate Certification Authorities" (if the root of the intermediate cert is already in root certs ) of the local machine (or of the user under which RTDB_EcOpcClient runs). Also the possible CRL file (Certification Revocation List) can be installed to the same location. The installation can be done by right clicking the certificate or CRL file and selecting "install", and continuing to appropriately select the local machine and the correct store. In command line it can be done with command certutil -addstore Root ca.der or certutil -addstore CA ca.der for "Trusted Root Certification Authorities" and "Intermediate Certification Authorities" respectively (add -user if case you want to install it for the current user only, for special use cases). The CRL file can be installed with same commands. If you use certlm.msc tool to view the certificates, the CRL entries are in a separate "Certificate Revocation List" as a sibling folder ot the "Certificates" folder of the store. NOTE: you need to restart certlm.msc if the folder did not exist when you initially opened the tool because the tool does not show folders that were created when it was open, at least not in Windows 2019 server or older).

License

A license for the EcOpcClient service must be defined using the section name OPC DA Client and the following parameters (currently there is just one parameter):

The program reads the license file only during startup. All instances of RTDB_EcOpcClient needs to be restarted to get the a new license file into use.

📘

Version info

Before RTDB 4.2, there was no technical check for the presence of the license.

Redundancy support

In a redundant RTDB configuration only the OPC client instance(s) that have the Master Token produce(s) data to the database or allows writing of data to OPC server. The name of the master token is “ApplicationName-Sid”, so the name is OPC server connection specific (the Sid is the OPC server id as defined in OPCSRV entry in EcCrossRefs or from the ProgId part of DaPath of Tags).

The OPC client will first try to connect to the OPC server and create all groups and initiates the callbacks (if callbacks are needed). If this succeeded, it tries to acquire the Master Token. If it gets the Master Token, it will add the OPC items to the OPC group. In case of OPC AE, the subscription is created but it is not set to active before the Master Token is got. In case of OPC HDA, the OPC client does not get the HDA item handles before it has the Master Token. The state of the OPC server must be Running before the OPC client will create any groups or subscriptions.

When the OPC client has the Master Token, it cyclically checks if the master token is requested to be released, and if is, it will disconnect from the server and release the master token. This occurs in the same cycle as the checking of the OPC server state. The OPC client releases the master token also every time when it disconnects from the OPC server (either from command or after a connection break).

If the connection to OPC server is OK and the OPC client does not have the Master Token, it cyclically checks if it can get it. This occurs in the same cycle as the checking of the OPC server state.

Output Requests

The RTDB OPC client is able to do event-based output to the OPC DA or UA Server. The RTDB OPC Client reads output requests from the RTDB CommandQueue. ODBC application programs can send output requests using the ODBC stored procedure call SendOutputRequest. RTDB C++ programs can send output requests also by using the M_SendOutputRequest function of C_DataPoint.

The RTDB OPC Client discards too old output requests that it reads from the command queue. By default the command age is 60 seconds. It can be changed by creating a row to the SimpleConfig table with section name RTDB-EcOpcClient and KeyName MaxCmdAgeS and StrValue as the command age value in seconds. After this, the RTDB OPC Client must be restarted.

The CommandQueue mechanism is used also with the RTDB “output” type variables and for variables with SendOutputMode is defined. The CommandQueue mechanism supports additional logic so that if writing of values is slow, the OPC client may skip old writes for items for which a newer write value is already available. The writing of values can be configured to use either synchronous or asynchronous writes. Notice that when using Tags for configuration, the default is to use asynchronous write (while the default is synchronous write when using EcCrossRefs configuration).

Output to OPC DA server can also be done by sending CTS calls to the OPC client.

Time Synchronization

The RTDB OPC client can read the current time from the OPC DA server and maintain the time of the RTDB computer accordingly. The current time is got as the timestamp of a defined OPC item (in a future version, the RTDB OPC Client may also be able to get the time by using the GetStatus of IOPCServer).

The time source item must be identified by including a special setting “TimeSource” to its RemoteId setting in the EcCrossRefs table. For example:

remid=FC.DateTime;TimeSource

The RTDB OPC client performs the timesynchronization when it receives a command "CALIBRATECLOCK". Thecommand can be scheduled to the RTDB TimedTasks table according to the following example:

INSERT INTO TimedTasks(TaskNum, ScheduleTime, IntervalSecs, SkipMissed, ResetAtStartup, TaskSpec) VALUES(401, { ts '2000-01-01 00:00:50' }, 60, 1, 1, 'CALIBRATECLOCK');
INSERT INTO TimedTaskState(ProcNumber, TaskNum, TaskOrder) VALUES(4, 401, 0);

The RTDB OPC client uses a time getting algorithm that is immune to the delays in the communication (the clock will not be changed at all if it can not be surely determined that the clock needs to be turned forwards or backwards). The time adjustment parameters can be configured with the TimeAdjust setting in the RTDB-EcOpcClient section of SimpleConfig as follows:

Min=1;Max=1800;ForwardDur=10;BackwardDur=10

Min defines the minimum time change in seconds.

Max defines the maximum time change in seconds. If the correction is more than this, the time will not be corrected at all.

ForwardDur and BackwardDur define the rate how fast the clock is turned forwards or backwards, respectively. Value 10 means that a correction of x seconds will be smoothly done during x * 10 seconds (in real time). Value zero means that the system time is changed immediately. Turning system time immediately backwards is not recommended because it may cause unexpected situations in some RTDB functions.

Generating Updated Timestamps

The RTDB current value production has the principle that the current value time (CT) should reflect to the newest time when the value was detected to have the specified value. When using OPC with data callbacks, the OPC server sends the new value and timestamp only when the value changes (however, the OPC UA has also an option to send the item state also when only the timestamp changes).

In order to have new timestamps to be generated for RTDB current values for constant OPC items, there are several different alternatives and they can be configured in very detailed way by using the EcCrossRefs style of configuration for OPC client. If you use EcCrossRefs for configuration, the newest mechanisms are not taken automatically into use without changing the stored configuration in the EcCrossRefs table. The more easy to use Tags based configuration uses the best conventions that are currently available (and the default conventions may change with new OPC client versions without any changes to the stored configuration).

Here is the description how the Tags based configuration handles the constant measurements for which the timestamp does not change.

The group uses cyclic refresh from cache. This means that the OPC client cyclically calls Refresh function to the OPC server which asks the OPC server to send the item states even if the value has not changed. The cycle time is 10 times the data rate, but not less than 1 minute.

When the OPC client handles the item state, it compares the current time to the time when the item state was handled previously. If this time interval is larger than the configuration parameter TRRMS, the default of which is the refresh rate divided by 2, the OPC client will generate a new item state with a new timestamp. The timestamp to be generated is the current time minus item specific delay minus value of TROMS parameter (the default of which is the daterate + 2000). The item specific delay is statistically collected from the previously received item states (as current time minus the item time).

For example, if you define a tag with data rate 5000 ms and the following measurement is received from OPC server from a callback at time 10:00:15:

At time 10:01:00, the OPC client will execute the Refresh call, and the OPC server sends the same item value and timestamp again.

The previous timestamp was received 45.015 seconds ago. This is older than 30 seconds (the refresh cycle / 2). The OPC client will generate an item time as follows:

currenttime  - 1000 ms - (TROMS = update rate + 2000) = currenttime - 1000 ms - 7000 ms =

General Configuration

The configuration tasks consist of editing the RTDB database tables that contain the OPC client configuration data. The database tables are usually maintained with the Excel files derived from RTDB_Populate_Database.xls.

Most configuration settings do not take effect before restarting the RTDB OPC Client. However, the some settings that affect the trace output take effect immediately without restarting. The RTDB OPC Client can be commanded to read the settings again by sending it a command GetConf via the CommandQueue as follows:

INSERT INTO CommandQueue(RcvId, CmdText) values(4, 'GetConf')

The GetConf command causes the RTDB OPC Client to read the settings again and to compare its contents with the previous one. The OPC client will apply the settings to the existing server connections and OPC groups on the fly. Another command alternative is “Restart”, for example:

INSERT INTO CommandQueue(RcvId, CmdText) values(4, 'Restart')

This means that the OPC client will do an internal reset of its state (it does not mean that the OPC client process restarts but the result effect is usually the same).

In addition to the traditional EcCrossRefs style configuration, the OPC client can also be configured with the Tags table. This is especially designed for automated tools that will populate the Tags table from according to the source system. The OPC can be configured to automatically detect the configuration changes to Tags table. In this case the GetConf CommandQueue command is not needed.

The value of some configuration settings is “infix expression”. This is a C-language like numeric expression with an addition of integer divide arithmetic operator “\”. The expression may contain references to the current value of RTDB variables (however, the RTDB variable name must be a valid C-language identifier) and to the values of internal OPC client variables declared with the “IID”-definitions in EcCrossRefs OPC item definitions.

General SimpleConfig Settings

The general configuration settings for the RTDB OPC Client reside in the database table SimpleConfig, where SectionName is the service application name, which is “RTDB-EcOpcClient” by default. The KeyNames in the SimpleConfig are:

KeyNames in table SimpleConfig

OPC UA Security related settings

Trace settings

The amount of trace information printed by the RTDB OPC client to the diagnostic log file and to the RTDB MessageLog is configurable. The configuration resides in the SimpleConfig table, where SectionName is “RTDB-EcOpcClient” and KeyName is “AppTrace”. The value is a 32-bit integer bit mask (i.e. multiple settings can be used by adding the values together, for example 32+64= 96). Value -1 means that all bits are on and the program produces the greatest amount of log information. The bits in the bit mask have the following meaning:­

AppTrace bit mask in table SimpleConfig

Note that the default AppTrace setting is -1, which means that all bits are set. Notice that it may be easier to write the setting as hexadecimal value. For example the setting 0x20000068 means that the bits 3,5,6 and 29 are set.

Another setting is the “TaskTrace” setting in the SimpleConfig. It is also a 32 bit integer bit mask and it controls the amount of log displayed about received or scheduled commands. The bits in the bit mask have the following meaning:

Table: TaskTrace Bit Mask in Table SimpleConfig

Note that the messages about executed commands may get heavily filtered when placed in MessageLog. If you want to force keeping of last N messages in the MessageLog, you can define the SimpleConfig setting CmdOutFilterLimit in the RTDB-EcOpcClient section to have value N. It's default value is zero, which means the default MessageLog filtering of C_RTDBServiceApplication::M_PutLog is used. The algorithm may filter identical messages that are identical except for the numeric values that they may contain.

The OPC client detects changes in tracing settings without needing a restart.

When item value tracing is turned on (by not having bit 30 in AppTrace), tracing of received item values can be enabled temporarily on an item-by-item basis using the following command:

INSERT INTO CommandQueue(RcvId, CmdText) values(4, 'ItemLog=1;Item=name;Sid=name;Gid=name')

The Sid and Gid parts are optional. The log can be turned off with ItemLog=0. The setting has effect until the service is restarted (or until a restart command is sent).

CommandQueue or TimedTasks commands

The OPC client can be controlled by sending messages via CommandQueue mechanism. The same commands can also be defined to be executed cyclically by using TimedTasks definitions. All commands have the format "Verb=value;Keyword=Value;...".

Table: OPC Client CommandQueue Commands

Configuration by Using the Tags Table

Starting from RTDB version 4.1, RTDB_EcOpcClient can be configured by using the Tags table that was introduced to that RTDB version. In older versions, the collected variables could only be configured with the EcCrossRefs table, which is also still available.

The SimpleConfig parameter "DataSources" must be configured (see General SimpleConfig Settings), so that the Tags table is used.

Because of its simplicity, the Tags configuration is much easier and allows configuration of new items and even OPC server connections directly from a dialog of the Vtrin user interface (In Vtrin you need to create a list display and define Tag as the source). Vtrin applications can be easily written to automate the population of Tags. (Note: Tags table can NOT be populated by other tools than VtrinLib because the RTDBDriver of VtrinLib contains special handling).

The Tags configuration is currently suitable only for straightforward configuration of current value production, and if you need more complex definitions, you may try the mixed Tags/EcCrossRefs-style configuration instead (see chapter Using Mixed Tags/EcCrossRefs configuration).

Defining Collected Variables

The following table lists the columns of the Tags table that are relevant for the OPC client communication.

Table: Item Configuration Table Tags

If HDA communication is defined, the result values are written to CurrentHistory. If both DA and HDA communications are specified, the communication runs in so called backfilling mode so that normally the data is read with DA and if there are communication breaks, the breaks are filled by reading the values with HDA protocol. In this case, the RTDB variable must not have any preprocessing defined (the DA items must be in the final engineering units).

Support for Hierarchical DatabaseNodes Configuration

A hierarchical node configuration can be defined with the DatabaseNodes table. In this configuration there are separate "data collector node" RTDB computers that collect data from the source OPC server near to the original source of data. And then there is a separate Main RTDB system that collects data from the data collector nodes. The contents of the Tags and DatabaseNodes table is identical in each computer and RTDB-EcOpcClient is able to use it to collect data in a hierarchical manner. If the data collector node is included to the DataSources and the DaTypeInternal is "OPC DA" and the communication is not disallowed with CollectFromChildren, the OPC client will collect the variables from its child nodes. In this communication, the OPC item id names are generated dynamically according to the convention of RTDB OPC DA and HDA servers. (Note: in current version the OPC client always takes of Output Tags despite of the DaTypeInternal setting).

To retrieve data from the data collector node, a RTDB OPC DA and HDA Servers must have installed to the local (main) computer with the program id ABB.RtdbOpcDaServer_NAME and ABB.RtdbOpcHdaServer_NAME, where NAME is the name that is used in the name column in DatabaseNodes table. The RTDB OPC DA Server must be configured to accept the LongGuid Variable Item Id format. The RTDB OPC HDA Server must be configured to accept the ShortGuid Variable Item Id format.

The data retrieval from child nodes use DA for normal data transport and HDA for backfill purposes. After a backfill is done, the OPC client produces an entry to HistoryUpdateLog that has a comment value "Backfill:CollectorNode=DC1" where DC1 is the name of the data collector node (as defined in DatabaseNodes.Name). The variable id in the HistoryUpdateLog is empty, denoting that multiple variables where updated.

OPC Write

When the DataFlowDirection column in Tags table is set to 1/out, the OPC client prepares the variable for writing the current values to the OPC server. The writing of values is event based, and it occurs always when a current value is produced to the variable.

The output triggering is implemented so that when the OPC client reads the configuration in the Tags table, it maintains two attributes of Variables table: ValueChangeReceiver and SendOutputMode. For Output tags, it sets SendOutputMode to 1/Always and ValueChangeReceiver to the process number of the OPC client (usually it is 4 which is the default). When any application produces a current value, the RTDB current value production uses these two attributes in the Variables table and activates the SendOutputRequest for the current value (it is not activated if the current value is invalid after possible current value preprocessing steps). The (possibly) preprocessed current value is sent. However, it is assumed that analog preprocessing is NOT used for the output variables (because of the original requirements of output requests, analog values are back scaled before the value is sent to output).

For Tags with DataFlowDirection "1/in", the OPC client checks that ValueChangeReceiver is not the OPC client itself. If it is, it resets ValueChangeReceiver and SendOutputMode to zero. This means that the same OPC client process can not act as the producer of the current value and the writer of the output controls. Moreover, this means that Tags table can not be used to define reading of the same variable (by some data acquisition link) and outputting it (be same or some other data acquisition link). (This limitation may be removed in a future version).

The application that produces current values to output variables can not assume that the value is always successfully written to the OPC server (and from there to the low level control system for instance). For example, if the OPC client process is not running or the connection to the OPC server is broken, the write may not be possible. If it is essential to know that the writing was successful, the application must verify it by checking the write from some feedback measurement that is provided by the low level control system. If such is not available, another RTDB variable can be defined that reads the written value back from the same OPC item. However, this method is not available if the control system does not allow reading the values from the same item. For example, some control systems reset the written value each time when it has processed it.

The OPC client collects all buffered output values and uses asynchronous write call to perform the writing of the item values to the OPC server. If new values have been requested to be output for the same variable, the OPC client discards the old buffered request. The OPC client waits until the last asynchronous write is ready before sending another asynchronous write for the OPC group (however, the OPC client can be configured also to allow a given number of pending writes, but notice that the OPC specification does not require that OPC servers would allow more than one). The OPC client maintains Component Status information about how many values it has successfully written, and the count of items for which the last write operation to the item failed. (Version info RTDB 4.5).

The CommandQueue based output mechanism supports only the numeric (int and double) and text variables (not arrays).

Instead of the event based CommandQueue mechanism, it is also possible to configure cyclic writes. This can be done by appending ";CommType=CO" to the DaPath. After this, the OPC client will cyclically read the current value of the variable and if it is valid, it will write the value to the OPC server. The DaFrequency defines the cycle. (version info: cyclic output needs version 5.3/2020-05-23).

The output (write) calls are done in the OPC server connection specific thread. The same thread performs also cyclical check of server status and cyclic retry of adding missing items to the communication. If there are delays in these operations, it will cause missed write cycles. Missed write cycles can also be caused if the actual writing in the OPC server takes too long time.

Using Mixed Tags/EcCrossRefs configuration

If you need the capabilities of server and group configuration not available via Tags configuration, you can define them with EcCrossRefs definitions and use the Tags table only for adding items to them. When the DaPath strings of Tags are processed, the item is added to the server with matching node, progid and clsid. If this server is defined in EcCrossRefs, it is used instead.

When the server is found, and the protocol name "opcda" or "opc.tcp" is used in DaPath, the item is added to the group of the server with matching group parameters frequency (rate) and deadband (band). If other protocol name is used, the name (GID) of the OPC group is used for matching. The group name for Tags has the format "G" + suffix + datarate. In OPC DA, if a nonzero deadband is defined, the "_" + deadband is added to the name (in OPC UA, the deadband is not used in the name, instead the deadband is item specific). The suffix is used if the protocol name is other than opcda or opc.tcp, in which case the name is the protocol name suffix after the "opcda" or "opc.tcp" -prefix plus an underscore. For example if a protocol name "opcdacr1" is used with datarate of 10000 ms and zero deadband, the group name will be "Gcr1_10000".

Note that the automatic generation of server and group objects from Tags define some non-default settings for them. You may need to compare item reports that the group and server parameters do not unexpectedly change if you use manually defined OPCSRV and OPCGRP entries. Note also that if you need OPCSRV definitions need to always define also the OPCSRV definition (because the OPC client parses EcCrossRefs definitions before Tags).

The following are the nondefault OPC server settings used by the Tags configuration:

• BinMask=-1
• DATATYPE=EMPTY
• CVOPTS=1

The following are the nondefault OPC group settings used by the Tags configuration:

• UseAsyncWrite=1
• SkipOldWrites=1
• TOK_IDT= SYS_OPC_OK_sid (for HDA)

The following are the nondefault OPC item settings used by the Tags configuration:

• SetInvalid=1 (for input tags only, unless changed with SimpleConfig TagSetInvalid setting)

Server or group specific settings can also be augmented by using SimpleConfig settings (version info: RTDB 4.5). Server settings can be defined in setting with section name "AppName" and key name "SID_sid ", and group settings with section name "AppName", key name "GID_sid_gid". Example:

insert into SimpleConfig(SectionName, KeyName, StrValue) values('RTDB-EcOpcClient', 'SID_fi8-main_4841', 'StatusCheckSecs=15')
insert into SimpleConfig(SectionName, KeyName, StrValue) values('RTDB-EcOpcClient', 'GID_fi8-main_4841_G10000', 'UaNameSpace=http://fi.abb.com/Vtrin')

If the sid name is longer than 36 characters, the "SID_sid" does not fit to the keyName column of SimpleConfig because its max length is only 40 characters. This can easily occur if the SID name was generated from the Tags configuration. In some cases it is possible to make it shorter if the DaPath uses a fake Program Id part, in which case the program id can just be selected to a shorter value. Also if ProgId is not fake, you can start using fake ProgId by adding also the ClsId part to the DaPath. For example change:

opcda:///A.Very.Long.Program.Id//MyOpcItemName

to

opcda:///ShortId/{THECLSID-OFMY-OPC1-SERV-ER4534534534}/MyOpcItemName

If the sid string still is too long, for example because the network node name is so long, such as in DaPath

opc.tcp://a.too.long.network.name.com:4841///Variable.RTDB_SECOND_OF_HOUR;UaNamespace=http://fi.abb.com/Vtrin

you can use a short SID instead by using only (often a fake) ProgId part in the DaPath, such as:

opc.tcp:///R1//Variable.RTDB_SECOND_OF_HOUR;UaNamespace=http://fi.abb.com/Vtrin

Notice that now there are three slashes at the beginning, meaning that the node network name is not there. Now define the node name in a separate simpleconfig entry as follows:

INSERT INTO SimpleConfig(SectionName, KeyName, StrValue) VALUES('RTDB-EcOpcclient', 'SID_R1', 'UaUrl=opc.tcp://a.too.long.network.name.com:4841');

Or in the case of classic OPC DA:

opcda:///My.OpcServer.With.Too.Long.Name.1//MyItem1
opcda://a.too.long.network.name.com//{52e30da6-f8c3-4257-9714-5ff4b563d935}/MyItem1

and using short da paths:

opcda:///R1//MyItem1
opcda:///R2//MyItem1

and:

INSERT INTO SimpleConfig(SectionName, KeyName, StrValue) VALUES('RTDB-EcOpcclient', 'SID_R1', 'ProgId=My.OpcServer.With.Too.Long.Name.1');
INSERT INTO SimpleConfig(SectionName, KeyName, StrValue) VALUES('RTDB-EcOpcclient', 'SID_R2', 'Node=a.too.long.network.name.com;ClsId={52e30da6-f8c3-4257-9714-5ff4b563d935}');

(version info: this did not work for the Classic OPC servers before 5.3/2024-09-19, see WI#63815 in release notes)

Of course, another solution to a too long network node name is to use a shorter name, and define it in the hosts file of the client computer. However, this will not work with UA where the name must match the name in the server certificate.

The simpleconfig "SID_" setting replaces the setting in Tags or EcCrossrefs if both contain the same keyword (for example, the UaUrl can be thus defined in SimpleConfig, and this is actually the only way to define UaUrl that contain a slash character. The simpleconfig "GID_" setting is not allowed to contain same settings as come from Tags or EcCrossrefs, except for the NEWTS keyword.

To know the correct sid name to be used, the easiest is to look it from the generated item report because the rules how the OPC client generates the sid name from tag are quite complex, but here they are in brief: The ProgId is used as the SID name. If server name is used, it is prefixed with special characters replaced with underscore.

For non-default RTDB_EcOpcClient.exe instances, the application instance name and underscore is prefixed to the sid name, with prefix "RTDB-EcOpc" removed. For example, in case of RTDB_EcOpcClient.exe -proc 104 -app RTDB_EcOpcUA, the sid prefix is "UA_" (do not get confused that in this case the instance name is both present in the SectionName and in the KeyName of the SimpleConfig entry). So the SimpleConfig entry looks something like this in that case:

INSERT INTO SimpleConfig(SectionName, KeyName, StrValue) VALUES('RTDB-EcOpcUA', 'SID_UA_R1', 'UaUrl=opc.tcp://FI-DB-MAIN-R1.ANKKALINNA.FI.ABB.COM:4841');

The Tags configuration gives an internal time class for the groups, and it starts the numbering the time class from 1001. When you define your OPCGRP entries to EcCrossRefs, you should use smaller time class numbers.

If you need special item definitions available only via EcCrossRefs table, you may append them to the DaPath definition after a semicolon. For example ";Index=1".

(version info: before version 4.2-1/2010-03-02, this was available only for the "RemoteId" keywords).

Example 1

We want to define a custom CTACS setting (connection thread alive check in seconds) for the server connection that uses the following DaPath in Tags:

opcda://10.16.16.113/MetsoAutomation.XDOPCServer3.1/{73FA5150-2E82-11D1-BA51-0020AFFA38BB}/:e:pr:661-GC5304.P5:av

The following OPCSRV definition can now added to EcCrossrefs:

INSERT INTO eccrossrefs (ProcNumber, TimeClass, OrderBy, CommType, LocalId, RemoteId) VALUES(
415, 0, 0, 'OPCSRV', 
'SID=KA5_10.16.16.113_MetsoAutomation.XDOPCServer3.1;CTACS=960;BinMask=-1;DataType=EMPTY;CVOPTS=1', 
'node=10.16.16.113;ClsId={73FA5150-2E82-11D1-BA51-0020AFFA38BB};ProgId=MetsoAutomation.XDOPCServer3.1');

Note that both ClsId and ProgId need to be defined because they both were present in the Tags definition, even though the ProgId is not used at all when ClsId is present. Because ProgId is not used, you can even use a fake ProgId (both in Tags and EcCrossRefs) to make the generated SID name shorter. The SID name that is used in the EcCrossRefs can actually be any name (needs to be unique within the RTDB database because the item report file names use the SID name). In the above example, the same SID name was used that RTDB_EcOpcClient generates from the DaPath definition of Tags.

In the above example, a separate RTDB_EcOpcClient service instance has been installed (see chapter Running the Service Programs how to install separate service instances) that uses the RTDB process number 415. Remember that when separate instances are used, SimpleConfig/DataSources definition needs to be added for each instance, for example:

INSERT INTO SimpleConfig(SectionName, KeyName, StrValue) VALUES('RTDB-EcOpcKA5', 'DataSources', 'opcda://10.16.16.113/MetsoAutomation.XDOPCServer3.1/{73FA5150-2E82-11D1-BA51-0020AFFA38BB}')

Assuming that the application name RTDB-EcOpcKA5 was used in the service installation.

Example 2

We have a very large amount of items and the OPC server has some limitation how many items one group and have. A simple solution could be to use slightly different data rates or deadbands in the Tag definition, but it is also possible to define another group with identical parameters. The protocol name in the DaPath is then used to decide to which group the item belongs. Now we need to define an OPCGRP entry to EcCrossRefs. However, when OPCGRP entries are used an OPCSRC entry must also be defined for it first (otherwise the OPCGRP does not recognize to which OPCSRV it belongs, even if it has been defined in Tags, because RTDB_EcOpcClient parses the EcCrossRefs configuration before parting the Tags configuration).

-- Insert the OPCSRV entry (see example above)
INSERT INTO eccrossrefs (..., CommType, ...) VALUES(..., 'OPCSRV', ...)

-- Insert the OPCGRP entry
INSERT INTO EcCrossRefs(ProcNumber, TimeClass, CommType, LocalId, RemoteId) VALUES(415, 1, 'OPCGRP', 'GID=Gcb1_10000', 'rate=10000;SID=KA5_10.16.16.113_MetsoAutomation.XDOPCServer3.1')

Items to this group can now be added by using the following DaPath:

opcdacb1://10.16.16.113/MetsoAutomation.XDOPCServer3.1/{73FA5150-2E82-11D1-BA51-0020AFFA38BB}/:e:pr:661-GC5304.P5:av

(and datarate 10000 and deadband zero)

STATUS_IDT example

This is an example where a tag uses a STATUS_IDT and STATUS_OK definition. By this way, the validity of the measurement is read from another measurement. Both items should be in the same OPC group (i.e. the same DaFrequency), and it also relies something about the atomicity how the OPC server provides the values. In this example, the measurement is an array type (type 20 = array of float).

This SQL script is for the VtrinLib ODBC Driver. To execute it in an installed RTDB 5.0 or later environment, use the command praox %app_vtrinlib_dsn% -script a.sql, where SQL commands have been copied to the file a.sql.

insert into Tag(ProposedName, DaType, Activity, DaFrequency, Type, MaxArrayLength, VariableLengthArray, TargetHistory, DaPath) values('TST_Array',       0, 1, 10000, 20, 100, 1, 195, 'opcda:///opc.t.1/TST_Array;status_idt=TST_ArrayStatus;STATUS_OK=x==0');
insert into Tag(ProposedName, DaType, Activity, DaFrequency, Type,                                                     DaPath) values('TST_ArrayStatus', 0, 1, 10000, 1,               'opcda:///opc.t.1/TST_ArrayStatus');

It is also possible to use the measurement itself as the status item. However, if the measurement is an array type, only one selected element in the array can be used. The following example will set the current value as invalid if the first element has value zero:

insert into Tag(ProposedName, DaType, Activity, DaFrequency, Type, MaxArrayLength, VariableLengthArray, TargetHistory, DaPath) values('TST_Array',       0, 1, 10000, 20, 100, 1, 195, 'opcda:///opc.t.1/TST_Array;status_idt=TST_ArrayStatus;STATUS_OK=x!=0');
insert into Tag(ProposedName, DaType, Activity, DaFrequency, Type,                                                     DaPath) values('TST_ArrayStatus', 0, 1, 10000, 1,               'opcda:///opc.t.1/TST_Array;Index=1');

Notice that the STATUS_OK expression is now "x!=0" and the "Index=1" definition selects the array element, and the OPC item for the TST_ArrayStatus tag is same as for TST_Array.

Configuration by Using the DataAccessSources Table

Starting from RTDB version 5.1, RTDB_EcOpcClient can also be configured by using the DataAccessSources and DataAccessRealTime tables that were introduced in that RTDB version. The DataAccessSources configuration can currently (as of 2016/05) be used only for collecting data to equipment model historized properties.

The DataAccessSources-based configuration uses the same kind of DaPath strings as the Tags configuration. Also, the DataSources SimpleConfig setting must be set similarly so that the OPC client instance knows which DaPath connections it will take care of (see section General SimpleConfig Settings).

DataAccessSources Table

DataAccessSources table

The following table lists the columns of the DataAccessRealTimetable that are relevant for the OPC client communication.

DataAccessRealTime Table

For example, consider that we have an equipment model that contains a base class for all Drive types, such as:

INSERT INTO Equipments (Id,Name,Abstract,BaseId) VALUES('42cf61dd-5f04-4402-b921-5a5d24769b4c','Drive',1,'00000000-0000-0000-0000-000000000000');
INSERT INTO EquipmentPropertyInfos (EquipmentId,Id,Name,Historized,Type,Unit) VALUES('42cf61dd-5f04-4402-b921-5a5d24769b4c','d6712f22-bd84-490c-8149-7d6b9b635839','MotorSpeed', 1, 14, 'Rpm');

And then we have a derived class

INSERT INTO Equipments (Id,Name,Abstract,BaseId) VALUES('4eda46cd-947a-4ba2-9d69-3fe2f96462b0','ACS600',0,'42cf61dd-5f04-4402-b921-5a5d24769b4c');
INSERT INTO EquipmentPropertyInfos (EquipmentId,Id,Name,Historized,Type,Unit) VALUES('4eda46cd-947a-4ba2-9d69-3fe2f96462b0','3d94447d-a98a-49f9-97fa-e3c536f81532','MotorRunTime', 1, 14, 'h');

And then we have an instance of the equipment:

insert into Path_ACS600(name) values('Drive1');

And now we can define the OPC client configuration:

INSERT INTO SimpleConfig(SectionName, KeyName, StrValue) VALUES('RTDB-EcOpcClient', 'DataSources', '*');

-- By default, the properties have the default update rate of 10 seconds:
insert into DataAccessRealTime(id, name, UpdateRate, PublishInterval, OwnerComponent) values('/Path_Drive', 'Drive default update rate', 100000000, 100000000, 0);

-- The Default update rate of some properties is one second:
insert into DataAccessRealTime(id, name, SamplingInterval, PublishingInterval, OwnerComponent, Options) values('/Path_Drive[MotorSpeed]', 'Drive MotorSpeed default update rate', 10000000, 10000000, 0, NULL);
insert into DataAccessSources(id,OwnerComponent,AccessType,AccessPath) values('/Path_ACS600[MotorSpeed]/|Drive1', 0, 0, 'opcda:///SMP.1/{0}{1}1.02');