Tag Rule Index

In Niagara 4.3 and later the Tag Rule Index, which is enabled by default (as shown here), 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 6. 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, as shown. Typically, you would never 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 7. 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 number of implied tags (technically, it is 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 8. Tag rule index info section in Spy Remote view

Imply tags in a different tag dictionary

The presence of the 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 (you cannot add rules that will persist through a station restart) in the tag rules of your custom smart tag dictionaries.

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 9. 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. On the Implied Tags tab in the dialog 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 10. Implied Tags tab in Edit Tags dialog

More significantly (in Niagara 4.3 and later) when you search for "n:geoCountry" for example, you'll actually get booleanWritable points in the results.