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.

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 just 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.

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.

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, and hs:writable. Tags used in GroupLevelDefinitions are good candidates for indexing because they'll be 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 value is derived based on component and/or properties of the station are called smart tags. Other smart tags that are safe to index include 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, and hs:unit, hs:writeErr, hs:writeLevel, hs:writeStatus, and hs:writeVal.