Implementation Best Practice

Save PDF

Last UpdatedJan 15, 2025
5 minute read

Processing Steps

The diagram below illustrates the processing steps of the Registers Gateway.

The ISM model is processed and published to both the AIM staging area and the Reporting Database.
The data is being captured and interpreted, then consolidated and published to the AIM staging area and to the Reporting Database.

Optimum Execution Strategy

It is important to highlight that capture and interpret processes are executed for each register, while consolidation and publishing to the reporting database are performed at the category level (tags, docs, general, and physicals). Consequently, execution is significantly faster when running it in parallel rather than sequentially, for AIM on-prem implementations. This parallel approach is already implemented in AIM-A.

This can be executed as follows:

Run parallel processes for each register to capture and interpret data.
For each category, run parallel processes to consolidate and publish staging data.
Updating the reporting database can be time-consuming; therefore, it is recommended to schedule this task overnight.
The Registers Gateway generates a detailed log with general information about the processed data. Writing this information directly to the console screen can be time-consuming. It is highly recommended to redirect the Gateway console output to a file. For example, AVEVA.Registers.Gateway.exe .\update.cfg v:publish="ism|main" |Out-File -FilePath C:\regi\logs.txt

Asset Register Design

A register is used to manage a set of information. This may be thought of as an individual database of information with two states (captured raw data and interpreted data which is mapped to the class library). Multiple registers can be consolidated into a master asset register.

A register is:

A managed set of information with a clear purpose.
An isolated, clear and named data concern we wish to manage over a lifecycle.

A register is not:

A file (in this context), though it is typically updated through one or more files being passed into the register.

Register Design Best Practice

The Register ID should be named and readable.
Employ a two-node level structure in ISM where the first level describes a system (set) of registers with a common nomenclature and the second level is specific registers related to a data concept (Tag, Instrument, Functional Location, Equipment, etc.).
Use only alpha characters for a register ID with title case, no spaces, underscores, numbers, or other special characters.
Avoid using long names for a register ID. During data processing, the data is placed in a path constructed from the register node hierarchy, starting from the first node under InfoInterface:Data Sources. The total path length, including all folders and file names should not exceed 256 characters.
Be mindful of the number of columns, especially when many contain empty values. Combining data into a single large register with excessive columns is not recommended, as it can negatively impact processing performance. Remember, a register is a set of information with a specific purpose and a defined data concern to manage over a lifecycle, it is not intended as an interface for bulk data dumping.
Adding capture filters to reject incorrect or incomplete data is recommended, as it reduces the volume of invalid data and improves processing efficiency.
Avoid using overly complex data expressions, such as multiple nested if...then statements. Consider whether the data being processed would be better fixed by pre-processing or correcting it in an external system before supplying it to AIM. Fixing poor quality or confusing data is not intended to be a function of AIM.
Do not try to specify multiple registers with the same input file. In this scenario, a linked register should be used.

Troubleshooting Issues and Addressing Slow Performance

The Registers Gateway provides a detailed log describing each step of the data processing operations. When issues arise, the first step is to review these logs. Log messages are categorized as information, warnings, and errors. To locate specific entries, search for [ERR] or [FTL] to find errors, and [WRN] for warnings. The entry provides clear details about the error and the interface/category or processing step where it occurred.

The log messages are timestamped, allowing the time taken for each operation to be measured. This provides valuable insights when diagnosing slow performance, helping to identify which interface or operation is the most time-consuming. These issues can be addressed by tuning the configuration, correcting the data, or adding filters to exclude unnecessary, incorrect or incomplete data.

For more information on data loading performance, see Data Loading Performance.

Reducing the Number of Unknown Tags

The number of unknown tags can grow massively resulting in long processing and importing times. This can result from unoptimized configuration. The main source of unknowns is scraping, if the scraping patterns are not configured properly, the scraping process could end up generating massive amounts of data, leading to the creation of a significant number of document to unknown tag associations.

Optimizing Scraping Patterns

The following are a list of suggested scraping patterns. They can be customized according to customer data. AVEVA keep revising these patterns to find the best balance between maximum capture of correct tags and reducing the capture of incorrect ones. Scraping performance is influenced by the number and complexity of patterns used. Fewer and simpler patterns result in faster and more efficient scraping. The following list contains the latest optimized set of patterns.

<?xml version="1.0" encoding="utf-8"?>

</Search>

</Search>

</Search>

</Search>

</Search>

</Search>

</ConfigurationSettings>

Applying Capturing Filters

Capturing filters can help with rejecting unwanted invalid data. The rejected data will be reported in the logs. An example of utilizing the capturing filters is adding a rule that allows only tags containing characters, digits, and hyphens and requiring at least one of each (this is just an example, and must be adjusted based on the customer data and naming templates):

CaptureRejectRecordRule="{{ if @[TagID] not matches /^(?=.*[A-Za-z])(?=.*\d)(?=.*-)[A-Za-z\d-]+$/ then concat('Invalid Tag: ', @[ TagID]) }}"

Using Include Records

The IncludeRecords rule is another way to filter out unwanted data. While CaptureRejectRecordRule occurs during capture operation, the IncludeRecords rule will be applied during interpretation. This means that all data will be captured first, and the filters will be applied at the interpretation phase. As a result, the overall processing time can be longer when using IncludeRecords rule compared to the CaptureRejectRecordRule.

An example of using IncludeRecords:

IncludeRecords="{{ @[TagID] matches /^(?=.*[A-Za-z])(?=.*\d)(?=.*-)[A-Za-z\d-]+$/ }}"

Registers Gateway