Tag Rule Index

The tag rule index, which is enabled by default, is an index on the Tag Dictionary Service. The index improves performance in evaluating tag rules for implied tags during NEQL searches. The index, which is built as NEQL queries are executed, maps tags to the tag rules that imply those tags. This index should not require a significant amount of system memory.

Note: The type of memory being used by the tag rule and implied tag indexes is heap memory. So these indexes are not stored persistently but are built dynamically after every station reboot when NEQL queries are submitted.
Figure 1. Tag Rule Index Enabled property


To ensure that the index is kept up-to-date, it is cleared automatically whenever changes are made in the Tag Dictionary Service. For example, if you delete a tag from the tag list under a tag rule, the index is automatically cleared. This prevents incorrect or incomplete results from occurring in your hierarchies, searches, and anything else that uses NEQL queries. As you execute subsequent searches the index is rebuilt.

Although cleared automatically, there is an added Clear Tag Rule Index action on the Tag Dictionary Service which allows you to manually clear the index. Typically, you would not need to invoke this action. It is provided so that you can reset everything when you are not seeing the expected results. It is not likely that the tag rule index would be the cause of the problem but the action is available just in case.
Figure 2. Clear Tag Rule Index action


Additionally, within the Spy Remote view, there is an added “Tag rule index info” section, which lists details of the index. Specifically, it shows the following:
  • the number of implied tags, technically, tagIDs in the index referred to as “# of indexed tags”

  • the number of tag rules in the index implying those tags; a single rule may appear many times in the index and indicates via these values whether the index has been cleared. For example, when the index is cleared or disabled both the "# of indexed tags" and "# of tag rules" values on the Spy page will be zero.

Figure 3. Tag rule index info section in Spy Remote view


Imply tags in a different tag dictionary

Tag rule index allows you to imply tags in a different tag dictionary than the one containing the tag rule doing the implying. Stated another way, this permits you to use tags from other tag dictionaries with a different namespace, such as the Niagara tag dictionary which is frozen in the tag rules of your custom smart tag dictionaries. Frozen means that you cannot add rules that persist through a station restart.

For example, the following image shows the property sheet for a custom smart tag dictionary in which a tag rule contains several tags, one of which is a marker tag for “isBooleanWritable”. Notice that this tag is not fully qualified, meaning that the tag name does not include the namespace of the source tag dictionary. In this situation the tag automatically assumes the namespace of the dictionary in which it is being used, in this case the “Custom” tag dictionary: c:isBooleanWritable. The other tags in the tag rule are fully qualified and reference a completely different tag dictionary, the Niagara tag dictionary as indicated by the namespace, n:.

Figure 4. Tag dictionary property sheet followed by implied tags in Edit Tags dialog


Right-clicking a boolenWritable point in the station allows you to select the Edit Tags dialog box. On the Implied Tags tab, you can see that the tags in the example tag rule are implied on this object. Also, you can confirm that the tag rule has implied tags from the parent smart tag dictionary (Custom, c:isBooleanWritable) as well as tags from a different tag dictionary (Niagara, n:geo*).
Figure 5. Implied Tags tab in Edit Tags dialog

More significantly, when you search for "n:geoCountry", for example, you will get booleanWritable points in the results.