Data Groups
With few exceptions, data groups must be defined in a device template file 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 in the table 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.
Notes:
- Point IDs must be unique within a data group (case insensitive).
- Data group elements for DNP3 data groups do not support a conversion function (cvtF).
-
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.
DNP3 EIE Data Groups
| Data Group Type | Usage Notes | |||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
AllPoints |
The "All Points (Class 0)" data group gets all Class 0 static data values. When this data group is polled, CygNet point updates are made to any mapped deids in instantiated data groups with a matching ptId. Note: The "All Points (Class 0)" data group can be huge — it will get a data value for every single DNP3 item (AI, AO, DI, DO, counter, string, etc…). |
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
The "Configurable Data Group" data group provides a flexible way to create custom data groups on a per-device basis. See Configurable Data Group for more information. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
DateTime |
The "Date and Time" data group retrieves the field device's current time and can be used to sync it to the host's current time. |
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
The "Events" data group gets events by class (1, 2, 3) or by point type. The point type option provides a drop-down menu listing variations available for the chosen point type. When this data group is polled, CygNet point updates are made to any mapped deids in instantiated data groups with a matching ptId. See Polling Notes for more information. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The "Internal Indications" data group displays the IIN values obtained when reading/writing other data groups. The data group is composed of 16 Internal Indication bits that indicate a combination of whether events are available, whether the device needs time, the device status, whether there is an event overflow condition, and the success or failure of a specific request. The IIN bits are part of the header of every packet received from the device and are described in the following table: IIN Bit Mapping
The "Internal Indications" data group can also be used to clear the "Restart" bit (IIN.7). See Device Template File Items for more information. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The "Single Point" data group reads from or writes to a point on demand. See Single Point Data Group for more information. Note: It is recommended that you use this data group to write analog output and binary output values. |
DNP3 User-Defined Data Group Types
The DNP3 protocol allows users to define data groups using point types in combination with another data group element. See Point Types for more information.
Point Type-based Data Group
A Point Type-based data group that has the attribute dgPtType="XX" in the device template file will get all values of that point type. It may optionally specify the group variation number. The default variation is 0, indicating that the device determines which variation to return. The dgElements element for this data group type includes a point index (ptIndex) attribute. The configuration for these data groups is dictated by a specific device and load and are read-only.
The following example data group displays data group PointAI and the values specified for each point index.
|
<PointAI niceName="Points - Analog Input" dgPtType="AI"> <dgElements secLev="4"type="vrnt"> <Pt000 desc="Point 0" ptIndex="0"/> <Pt001 desc="Point 1" ptIndex="1"/> <Pt002 desc="Point 2" ptIndex="2"/> <Pt003 desc="Point 3" ptIndex="3"/ </dgElements> </PointAI> |
Generic Data Group
In a generic data group type, each data group element includes a Point ID consisting of point type and index. The point type and index are represented in a DNP3 device template file as ptId. These data groups can be read and/or written. The generic data group type is available to any remote device that is capable of handling requests for individual point IDs. In edit mode, a Send only edited items check box displays on the View Data dialog box, and when selected, only the edited values are written to the DDS transaction.
Note: For generic data groups using the String point type, string length ("Len") is required on a Send.
The following example data group displays the ptId for various point types.
|
<SampGen niceName="Sample Generic" canSend="true" uccSend="true"> <dgElements secLev="4" type="vrnt"> <Pt1 desc="Point 1" ptId="AI.1"/> <Pt2 desc="Point 2" ptId="AI.2"/> <Pt3 desc="Point 3" ptId="AO.2"/> <Pt4 desc="Point 4" ptId="BO.0"/> </dgElements> </SampGen> |
Data Groups for File Processing
A data group that contains the attribute dgCat="File" reads data from a file. When the name of the file is known, it should be represented in the device template file using the fileName data group attribute. A file name can contain these substitution strings: %ordinal%, %facilityid%, and %deviceid%. When the name of the file varies beyond the scope of the substitution strings, it must be provided using the FileName UIS command parameter.
A file data group is always read-only. It can be ordinalized, and can represent an array of records. When an array of records is represented in the file, the length attribute is used to specify the number of bytes in a single record.
Each dgElement element for this data group type includes the attribute off as an offset into the file. The data bytes that represent the contents of the file are interpreted based on the offset values. For example, an offset attribute of off="4" indicates the value is at byte 4.
The following are examples of data groups used for file processing. The FileSeq example is the simplest. It has a fixed file name, and contains three data elements. The FileHstCfg example is ordinalized and includes the wildcard %ordinal% in the fileName attribute. It also contains an array of records; each record is 91 bytes long. The FileSeqTm example has a variable file name, so the fileName is omitted from the device template file, and a UIS command with the parameter FileName is required.
|
<FileSeq niceName="File Seq # Range" dgCat="File" fileName="Hist_readSeqNumRange_1"> <!--test using emerson device--> <dgElements secLev="4" readOnly="true"> <Instance desc="File instance" type="ui1" off="0"/> <SeqOld desc="Seq # old" type="ui4" off="1"/> <SeqNew desc="Seq # new" type="ui4" off="5"/> </dgElements> </FileSeq> <FileHstCfg niceName="File Hist Config" dgCat="File" fileName="Hist_readMeterHistHeader_%ordinal%" baseOrd="1" maxCnt="5" ordLabel="Group" hasArray="true" length="91"> <!--data represents an array of records - length=size of record in bytes, hasArray=true--> <dgOrdinals> <e1 value="User 1"/> <e2 value="User 2"/> <e3 value="Generic"/> <e4 value="Station 1"/> <e5 value="Station 2"/> </dgOrdinals> <dgElements secLev="4" readOnly="true" isArray="true"> <Count desc="Count" type="ui1" off="0"/> <DataType desc="Data type #" type="ui1" off="1"/> <Unit desc="Unit #" type="ui1" off="2"/> <EfmItem desc="EFM item #" type="ui1" off="3"/> <TypeInst desc="Type/inst #" type="ui1" off="4"/> <Archive desc="Arch #" type="ui2" off="5"/> <Meas desc="Meas type #" type="ui2" off="7"/> <Desc desc="Description" type="string" len="21" off="9"/> <GrpObj desc="Group object" type="string" len="21" off="30"/> <Parm desc="Parameter" type="string" len="41" off="51"/> </dgElements> <uccRecvParms> <FileName desc="File name" required="true" type="string"/> </uccRecvParms> </FileHstCfg> <FileSeqTm niceName="File Seq # by Time via UIS Cmd" dgCat="File"> <!--test using emerson device and UIS command to provide filename--> <dgElements secLev="4" readOnly="true"> <Instance desc="File instance" type="ui1" off="0"/> <Time1 desc="Time1" type="ui4" off="1"/> <Time2 desc="Time2" type="ui4" off="5"/> <Seq desc="Seq" type="ui4" off="9"/> <Count desc="Count" type="ui4" off="13"/> </dgElements> <uccRecvParms> <FileName desc="File name" required="true" type="string"/> </uccRecvParms> </FileSeqTm> |


