Read data (data sources and tag names)
- Last UpdatedApr 24, 2025
- 3 minute read
Note: For information on overriding default configuration settings, refer to Modify configuration settings.
The Open Platform Communications (OPC) Server provides potential access to any data that is (or can be) published via the PubSub middleware. Included in this data is any field of any record within the RealTime database (RTDB), so an OPC client can access any RealTime data of its choice. Allowlists can be used to restrict this access.
When specifying OPC item names, the following conventions hold for all data contained within the RTDB:
<system name>.realtime.db.<table name>.<key name or number>.<field specifier>
Data Conventions
|
Name |
Meaning |
|---|---|
|
<system name> |
All AVEVA Enterprise SCADA systems have a system name, for example, primary. The first field in an item name must contain the system name from where the data is acquired. The system name is either supplied by the OPC Client user, or by instructing the AVEVA Enterprise SCADA OPC Server to supply it implicitly. To make the OPC Server supply the system name, you need to change the value of the nosystemname key from false to true in the %DNADataRoot%\RealTime\config\Settings\OPCDAServerConfig.json file for the OPC Server instance you want modified. In almost all instances, this is the name of the system on which the OPC server is running; exceptions to this rule should be kept to a minimum because of the performance degradation that could result. |
|
<table name>> |
This refers to the name of the table within the RTDB, such as: analog or status. |
|
<key name or number> |
This specifies which record or record number within the table, for example, Fred or 1. |
|
field specifier> |
This indicates the field within the record that contains the data of interest, such as flag.fresh. This field must be specific down to an elemental data value. Note: You cannot attach to an item that is a structure or an array. For example, attaching to primary.realtime.db.analog.fred.flag is incorrect, since the flag field of an analog is itself a structure. Note: Some OPC Clients can use a configuration file that contains paths, which are used to subscribe to points. By making use of the NOSYSTEMNAME option, the paths can be made relative or independent of the system that owns the OPC Server to which the client connects. For example, the line es.realtime.db.analog.blat.curval would be appropriate in the configuration file of a client running on the Test and Development System, but not appropriate in the configuration file for main. The NOSYSTEMNAME option turns the line into realtime.db.analog.blat.curval which will work regardless of the system from which the OPC Client is running. With this option specified in the OPCDAServerConfig.json file, the OPC client can use the same list of points to subscribe to data on multiple computers/systems. |
Examples of Legal RealTime Data Item Names
-
primary.realtime.db.analog.fred.curval
-
primary.realtime.db.status.pump1.cursta@raw
-
primary.realtime.db.analog.fred.flag.fresh@raw
-
primary.realtime.db.remote.sched[0].timerblk.day
PubSub Topic Space
In addition to items contained within the RTDB, you may also attach to any item that is available within the PubSub topic space, provided it has been published using the standard PSbuffer format.
For example, if you wish to monitor the arbitration state of the primary RealTime server, the you would add an item as follows: primary.realtime.arb.primary.states.state. Similarly, the hostname of the primary RealTime computer can be acquired via: primary.realtime.arb.primary.states.hostname.
If a PubSub message contains multiple data items within the PSbuffer message, only the first data item is available to the OPC Client
One other restriction is applicable to topics within the PubSub topic space. You may not specify any item that contains less than five segments. For example, primary.b.c.d.e is legal, while, primary.b.c.d is illegal. This restriction prevents the OPC Server from being overloaded by a client that attempts to make a subscription that is too broad. For example, any attempt to attach to an entire RTDB table, such as primary.realtime.db.analog, would be wrong as well as harmful to system performance.
Invalid OPC item names are logged in the %DNADataRoot%\RealTime\log\OPCServer.log files and the OPC Server returns invalid argument code. Invalid item names are those that do not parse correctly. For example, those that end with a dot or contain two consecutive dots, as well as invalid RTDB table, point, or field specifier values. However, it is possible to subscribe to any RTDB field with a correct naming convention, including one that does not exist. This is to allow access to a process that will be published to that field in the future.