Overview of the HAB Collector

The HAB collector collects data from Habitat, which is a SCADA application that contains real-time data. The collector interacts with the Habitat Sampler application to fetch data from the Habitat database records and stores the data in a Historian server.

Features:
  • Tags as well as alarms data collection: The collector can collect data for tags as well as alarms. Although a single collector instance can be used for both, we recommend that you use separate collector instances for tags and alarms.
  • High availability: You can achieve high availability by configuring redundant collector instances connected to redundant Habitat servers. For more information, refer to High Availability.
  • Automatic tag sync: The HAB collector creates tags automatically in Historian. When additional tags are added in Habitat, or when tags are renamed or deleted, the changes are reflected automatically in Historian. You can, however, choose to do it manually if you want to review the changes first. When you do so, only after you approve the changes, they are reflected in Historian. For more information, refer to Approve Tag Changes.
  • Tag deletion versus disablement: When a tag is deleted in Habitat, you can choose to delete it in Historian or disable data collection for the tag. For more information, refer to Configure the HAB Collector for Tags and Configure the HAB Collector for Alarms.
  • Multiple instances: You can create multiple instances of the HAB collector either on the same machine or on different ones. For example, one instance can collect data for tags with a faster streaming rate, while the other instance can collect data for tags with a slower streaming rate. For each instance, you must create a configuration file. For more information, refer to Configure the HAB Collector for Tags and Configure the HAB Collector for Alarms.
  • No dependency on an external database: Since data is stored in archive files, you do not require an external database (especially for alarms data, which is huge).
  • Supported timestamp resolution: The supported timestamp resolution is 1 second.
  • Unsolicited as well as polled data collection: For tags, both the polled as well as unsolicited data collection are supported. For alarms, only the unsolicited data collection is supported.
  • Supported data types: Floating point, integer, string, and binary data are supported.
  • The collector accepts device timestamps.
How it works when automatic tag sync is enabled:
  1. You specify the site details of Habitat and collection definitions in the configuration file, and start the collector.
  2. The collector connects to the Habitat Sampler application.
  3. Depending on the key value that you have provided in the configuration file, tags are created in Historian with the following naming convention: <host name of the Habitat server>.<composite key>.<field name in Habitat>
  4. Data collection begins.
  5. When tags are added, renamed, or deleted later in Habitat, the changes are reflected automatically in Historian. No manual steps are required.
How it works when automatic tag sync is disabled:
  1. You specify the site details of Habitat and collection definitions in the configuration file, and start the collector.
  2. The collector connects to the Habitat Sampler application.
  3. Depending on the key value that you have provided in the configuration file, tags in Habitat are listed in the <collector name>_Tag_Unconfirmed.xml file under the ProposedTags section. These tags use the following naming convention: <host name of the Habitat server>.<composite key>.<field name in Habitat>
  4. You approve the tags that must be created in Historian.
  5. The tags that you approve are created in Historian.
  6. Data collection begins.
  7. When tags are added, renamed, or deleted later in Habitat, you must again approve these changes. Only then they are reflected in Historian.
The tags created in Historian contain the MRID and composite key values of the corresponding Habitat record. Although MRID is constant for a tag, the composite key value can change if there is a change in the transmission/distribution lines. Therefore, the collector uses the MRID value to identify whether a tag is a newly added one or an old one that has been renamed. And the composite key is used in naming the tags created in Historian.
Supported data types:
  • Float
  • Integer
  • String
  • Boolean