Data Groups
With few exceptions, data groups must be defined in a device template file (DTF) in order for them to be available for use on a remote device. Which data groups are defined by a device template file depends on protocol, device type, and unique configuration.
CygNet distributes sample device template files for its EIEs, each of which typically serves one or more hardware models along with applicable firmware. Therefore, the data groups described below are only those data groups defined by CygNet in sample device template file(s). Your template(s) might not include some of the data groups described below. Device template files exist to enable users to customize device configurations; however, CygNet is not responsible for changes made by users.
For information about data group definitions and device template files, see Device Template Files.
For more information about data group dependencies, see Data Group Dependencies.
For more information, see the following subsections:
- Data Group Types Defined by the "dgStruct" Attribute
- FMS Data Group Types
- FMS Legacy Data Group Types
BSAP Data Group Types Defined by the "dgStruct" Attribute
The BSAP EIE manages most data groups according to type as defined by the data group’s dgStruct attribute.
|
<DataGroupType niceName="Data Group Name" dgStruct="type" ... > |
Available types and attribute values are listed in the table below.
Notes:
- The attributes values are case sensitive.
-
When point processing is performed on history data groups, only closed records will be published and processed to points. If a device has leading timestamped records and returns the current, open record, point processing will not be performed for that record, even though there is data in the DDS transaction. The point record will be updated only when that record is closed. This is to avoid a situation where a point has multiple entries with the same timestamp, since an open record may be still updating values with each new poll, but each update will have the same timestamp. For example, say you start polling for a daily history record at 8:00am, you’ll get the first value at 8:00am, then if you poll every five minutes, you’ll get new values throughout the day at the exact same timestamp. A history record is basically an array of data with a timestamp and values where the values have different process variables for each incremental poll. The timestamp won’t get written until the record is closed, which happens at the end of the time period, in this case, a day.
| Data Group Type | Attribute Value | Usage Notes | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
AArray/DAArray |
Analog Array and Dated Analog Array data groups handle sets of analog data group elements (floating points) and are identified by dgStruct="AArray" or dgStruct="DAArray". A Dated Analog Array("DAArray") data group displays the date in the first column. Array numbers are configured in the same manner as list data groups. Both the single specification and the ordinal format are supported. |
||||||||||||||||||
|
Archive |
Archive data groups are used for historical data, but otherwise have the same format as signal data groups. Only the value (Val column) for a signal is stored in dated rows. Archive data groups are identified by dgStruct="Archive". |
||||||||||||||||||
|
ArrayHistory |
The Array History data group retrieves data that is historical in nature from the Analog array on a BSAP device. This data group is identified by dgStruct="ArrayHistory". The data group element supports the following attributes:
The following request types are supported:
ExampleSee the following example data group for retrieving daily history data:
|
||||||||||||||||||
|
Audit |
Audit data groups are used for historical event and alarm records, and otherwise have the same format as signal data groups. Audit data groups are identified by dgStruct="Audit". Set oldNew="true" if text from device represents Old/New values for digitals. Set oldNew="false" if it represents the value of True/False conditions. Data groups of this type can be configured to optimize audit log retrieval by setting the Optimization setting on the Data Group Properties dialog box. Options include None: read entire log (default) and Get latest: read and purge. See Optimization for more information. Note: If you change the setting to read and purge the audit log you will be prompted to change the transaction retention settings to retain more data or accept transaction retention settings, which may cause CygNet to lose data that can’t be retrieved again. |
||||||||||||||||||
|
DatedAnalog Array |
DAArray |
See AArray above. |
|||||||||||||||||
|
List |
A list data group is used to process a predefined list of signals. Lists can be configured with the ACCOL load file on the device. Because they are defined at the device level, messaging using lists can be more efficient than using signal data groups. List data groups are identified by dgStruct="List", and require either a dgStructNum or one or more dgStructNum_ord<Ord> attributes to be present. The dgStructNum attribute corresponds to an RTU list number defined in the load file. The dgStructNum_ord<Ord> attribute, where <Ord> is replaced with the ordinal number, indicates that the list is dependent on the ordinal number of the data group. See Configuring Signal-Related Data Groups. ExampleIn the following example, the data group uses list 10 for ordinal 1 and list 11 for ordinal 2:
|
||||||||||||||||||
|
Logical Array |
LArray |
Logical Array data groups handle sets of logical data group elements (bits) and are identified by dgStruct="LArray". Array numbers are configured in the same manner as list data groups. Both the single specification and the ordinal format are supported. See Configuring Array-Related Data Groups. |
|||||||||||||||||
|
RTUConfig |
Signal |
A valid "RTU Config" data group must be retrieved before other data groups can be retrieved or sent. The "RTU Config" data group is identified by dgStruct="Signal". |
|||||||||||||||||
|
Search |
Search |
A search data group enables signal retrieval based on filter criteria. This type is available only for EGM 3530 and Teleflow models. Search data groups are identified by dgStruct="Search". See Configuring Search Data Groups. |
|||||||||||||||||
|
Signal |
Signal |
A signal represents a data group element along with its fields (listed in columns). A signal data group is a list of signals from the device. These signals do not need to be in any specific order or from any specific location. Signal data groups are identified by dgStruct="Signal". See Configuring Signal-Related Data Groups. |
BSAP FMS Data Group Types
The FMS data groups do not retrieve data directly from a remote device; instead, they depend on another data group to supply data to them. These data groups are not defined by the dgStruct attribute.
Notes:
- In the supportDg list in the device template file for FMS data groups, if you want to include a data group that is not included on the FMS ordinal, that data group must be on ordinal 0.
-
Best practice recommends that you do not perform UDC and point processing on FMS data groups. The DEIDs specified in FMS data groups are generic and use the eFMS enumeration to identify the CygNet-defined FMS items referenced in the device template file. No polling is done on these data groups — all data is coming from the native data groups. Points should be mapped to the native data groups since that is the data group that is actually processing the device data. While point processing may work on the FMS data groups, it is not supported, not tested, not consistent across EIEs, and is not recommended practice.
| Data Group Type | Usage Notes |
|---|---|
|
FmsAlarm |
"FMS Alarm Data" depends on a support data group identified by attribute type dgStruct="Audit" to supply data to it. Support data groups are assigned to an "FMS Alarm Data" data group in the supportDg element of the "FMS Alarm Data" data group in a device template file. Dependencies:
"Audit Trail" (Audit) must be instantiated before this data group can be polled. See FMS Alarm Data Group. |
|
FmsConfig |
"FMS Configuration Data" depends on a support data group to supply data to it. Support data groups are assigned to an "FMS Configuration" data group in the supportDg element of the "FMS Configuration" data group in a device template file. "FMS Configuration" must be retrieved before polling other FMS data groups of the same ordinal. |
|
FmsEvent |
"FMS Event Data" depends on a support data group identified by attribute type dgStruct="Audit" to supply data to it. Support data groups are assigned to an "FMS Event Data" data group in the supportDg element of the "FMS Event Data" data group in a device template file. Dependencies:
"Audit Trail" (Audit) must be instantiated before this data group can be polled. See FMS Event Data Group. |
|
"FMS History" depends on a support data group identified by attribute type dgStruct="Archive" or dgStruct="Array History" for its data. Support data groups are assigned to an "FMS History" data group in the supportDg element of the "FMS History" data group in a device template file. Dependencies:
-OR- Notes:
|
Best practice recommends that you do not perform UDC and point processing on FMS data groups. The DEIDs specified in FMS data groups are generic and use the eFMS enumeration to identify the CygNet-defined FMS items referenced in the device template file. No polling is done on these data groups — all data is coming from the native data groups. Points should be mapped to the native data groups since that is the data group that is actually processing the device data. While point processing may work on the FMS data groups, it is not supported, not tested, not consistent across EIEs, and is not recommended practice.
BSAP FMS Legacy Data Group Types
The FMS Legacy data groups do not retrieve data directly from a remote device; instead, they depend on another data group to supply data to them. These data groups are not defined by the dgStruct attribute.
Notes:
- Device template validation for BSAP FMS Legacy data groups has changed. If you are not migrating to the new BSAP FMS data groups, be sure to perform the CygNet upgrade procedure for device templates.
-
Best practice recommends that you do not perform UDC and point processing on FMS data groups. The DEIDs specified in FMS data groups are generic and use the eFMS enumeration to identify the CygNet-defined FMS items referenced in the device template file. No polling is done on these data groups — all data is coming from the native data groups. Points should be mapped to the native data groups since that is the data group that is actually processing the device data. While point processing may work on the FMS data groups, it is not supported, not tested, not consistent across EIEs, and is not recommended practice.
| Data Group Type | Usage Notes |
|---|---|
|
GmrCfgSend |
"FMS Legacy Config Send Data" is used to send modified measurement data to the field device. This data group is required only if you plan to use FMS and want to perform this specific task. |
|
"FMS Legacy Configuration Data" depends on a support data group to supply data to it. Support data groups are assigned to an "FMS Legacy Configuration" data group in the gmrDataGroupList element of the "FMS Legacy Configuration" data group in a device template file. |
|
|
"FMS Legacy Events Data" depends on the "Audit" data group to supply data to it. Support data groups are assigned to an "FMS Legacy Events" data group in the gmrDataGroupList element of the "FMS Legacy Events" data group in a device template file. See FMS Legacy Events Data Group. Dependencies:
|
|
|
"FMS Legacy History Data" depends on a support data group to supply data to it. Support data groups are assigned to an "FMS Legacy History" data group in the gmrDataGroupList element of the "FMS Legacy History" data group in a device template file. See FMS Legacy History Data Group. |
