Implied tags index

Implied tags index improves performance of NEQL searches and hierarchy traversal. Implied tags originate from evaluating the tag rules in smart tag dictionaries and evaluating direct tag groups on an entity. Indexing implied tags limits the amount of tag rule re-evaluation that occurs on subsequent NEQL queries.

For example, a NEQL search on an unindexed tag (ex.: c:city) requires that every tag rule that contains this tag be evaluated; every component throughout the station be evaluated for this tag; and this evaluation must be done every time a search for this tag is initiated. All of which adds up to a significant drain on performance.

JACE is constrained not only by processor power but also by memory availability. To control the impact on memory, the Implied Tags Index is disabled by default.

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.

You can enable specific tags for indexing by entering those individual tagIDs in the Indexed Tags field in the Tag Dictionary Service property sheet. Entering tagIDs in this field enables those tags to be indexed for each component in the station. Use a semi-colon separated list to enter multiple tagIDs to be indexed. Tags that are not enabled for indexing will use normal tag rule and direct tag group evaluation.

To stop indexing from occurring on some or all tagIDs and reduce the memory used by this index, remove tagIDs from the Indexed Tags field in the Tag Dictionary Service property sheet.

Although there is no mechanism for clearing the index, you can reset the index whether a tag definition is implied or not via the following actions on the Tag Dictionary Service. These actions do not discontinue indexing for the tagIDs listed in the Indexed Tags field but reset the index in regards to some or all of the tagIDs being indexed. The index will be rebuilt the next time a search for one of the indexed tagIDs is executed.

  • Invalidate All Implied Tags Indexes

  • Invalidate Single Implied Tags Index

CAUTION: Memory use is strongly influenced by the number of components in the station and then also influenced by the number of tags being indexed. The implied tags index has the potential to grow large enough to exceed available memory. To avoid this, limit the number of tags enabled for indexing.

Either direct or implied tags can be added to the Indexed Tags field. If an object contains an indexed tag as a direct tag, the index will not be used at all. If the entity does not contain the indexed tag as a direct tag, a search through the rules will be executed to determine if the tag is implied and the index will store whether or not the tag is implied.

Note: The implied tag index is most helpful for tags that are implied (rather than direct tags), because the re-evaluation of any tag rules can be skipped.
Implied tags that are safe for indexing are those tags that will be implied and whose values will not change regardless of changes to the station. For example, tags that are related to the type of a component, which can never change, are very safe to index. Tags related to type of a component include:

  • n:type

  • n:point

  • n:input

  • n:output

  • n:device

  • n:network

  • n:schedule

  • hs:connection

  • hs:cur

  • hs:device

  • hs:equip

  • hs:kind

  • hs:network

  • hs:point

  • hs:writable

Tags used in GroupLevelDefinitions are good candidates for indexing because they are used frequently. However, that does not necessarily make them safe tags to index.

Other implied tags may be riskier because rule conditions and contents can be changed and the changes might not be reflected in the index. Tags that are implied using the HasAncestorRule or HasRelationRule conditions depend on the station configuration and, if the station configuration changes, might affect whether or not tags are implied.

Also, it is not the value of the tag that is indexed but the tag definition. So, if the value of the tag depends on something that changes, those changes will be reflected in the value of the tag when the tag is retrieved from the index. For example, if the history ID of a history extension changes, the new value will be reflected in the value of the n:history tag when it is retrieved.

Tags whose values are derived based on component and/or properties of the station are called smart tags. Other smart tags that are safe to index include the following:

  • n:name

  • n:displayName

  • n:ordInSession

  • n:station

  • hs:curErr

  • hs:curStatus

  • hs:curVal

  • hs:enum

  • hs:his

  • hs:hisErr

  • hs:hisInterpolate

  • hs:hisStatus

  • hs:id

  • hs:maxVal

  • hs:minVal

  • hs:tz

  • hs:unit

  • hs:writeErr

  • hs:writeLevel

  • hs:writeStatus

  • hs:writeVal

Note: If you find that the JACE is at the limit of memory usage, it is best to clear any tags from the Indexed Tags field in the Tag Dictionary Service so that the indexing no longer occurs. If the station crashes before the Indexed Tags field can be cleared, the station can be started with the system property niagara.tagdictionary.disableTagIndexing set to true. This will prevent any indexing and allow the Indexed Tags field to be cleared. Then, this system property can be cleared and the station restarted to allow indexing again.