Data Validation

A number of data validation rules can be defined to ensure data quality within the NEXUS database. These are applied on the individual data fields contained within “Asset Information” or “Event” forms.

Required

Any data field of any field type can be set to be “Required”. This means that, when adding a new record, this field must be filled before the record can be saved. Typically fields should be set to “Required” when they provide essential information or are used as an input to critical calculations. Required fields are clearly identified on the form.

Hovering your mouse over the provides the hint: “Design Life is a required field and must have a value specified”

This requirement is also enforced during any data import. The user is unable to proceed with the import until the column with the ‘required’ field is present in the import sheet. Import sheets created by NEXUS identify required fields with a red column in MSExcel.

Maximum & Minimum

Numeric and Whole Number data fields can have Maximum and Minimum values set. This means that, when adding a new record, values in this field must be within range before the record can be saved.

Typically maximum and minimum values should be set to ensure data quality for fields where ranges are consistent for all assets. For example; a percentage field must be between 0 and 100.

Fields with out of range data are clearly identified on the form.

Hovering your mouse over the provides the hint: “Design Life must be less than or equal to 90” or “Design Life must be greater than or equal to 0”

Lookup Lists

Look List fields by their very nature enforce selection of valid data and provide consistency.

Anomaly Triggers

Data input onto Event forms are additionally subject to Anomaly Triggers. These are validation checks that define anomalous readings and are used to trigger the automatic creation of Findings of a given type and severity.

When an anomaly trigger is violated, a yellow exclamation mark () will appear next to the field. You can set lower/upper bounds to be constant values (so a field might trigger if it was outside, say, 1 to 9) or to pull from a field, on this form or on another form. So for example if this field is Measured Wall Thickness, it might trigger if its value is less than Minimum Allowable Wall Thickness.

For Lookup List fields, the comparison is done of the lookup list item’s Value, not its Comment. So if you have a lookup list titled “Anode Depletion”, and its first entry has value “25” and comment “0 to 25% depleted”, NEXUS will use the “25” for purposes of determining whether an anomaly trigger should be fired.

For Yes/No fields you can set the trigger to fire on any combination of Yes, No or blank; but you can’t compare to another field.

The Include Boundary tickbox controls whether exact matches cause the trigger to fire: if you have set a trigger to “Fail when inside Upper/Lower bounds”, your lower bound is 1 and your upper bound is 9, this is the difference between “1 < x < 9” and “1 <= x <= 9”.

You can optionally give an anomaly trigger a date range. If you set just a Date From, the trigger will apply only to event data from that date forward. If you set just a Date To, the trigger will apply only to event data from that date or earlier. If you set both, the trigger will apply only to event data within the specified range. In this way, you can change triggers to reflect new conditions, without causing spurious warnings on historical data. For example, if you decrease the operating pressure of an asset, this might decrease the minimum allowable wall thickness. Rather than editing the existing anomaly trigger, you can set a “To” date on that old trigger, and add a new trigger with a “From” date.

Caution

In most cases, Findings are generated at the time events are added or imported. There are however some scenarios in which the Anomaly Triggers utility should be run manually. These are 1) whenever anomaly triggers are edited; 2) when anomaly triggers exist on a calculation field; 3) before any Finding review sessions; or 4) after a bulk import of event data (particularly when anomaly triggers rely on events other than itself).

Triggers for a field independent of asset are found in NEXUS IC in Asset Information and Event Types. Anomaly triggers for specific assets can be configured in NEXUS IC by right-clicking on an asset and choosing Anomaly Triggers…. If you have both an asset-specific and a generic anomaly trigger on the same field, for assets with the asset-specific trigger, only the asset-specific trigger will apply. For assets with only a generic trigger, only the generic trigger will apply. Note that asset-specific anomaly triggers are specific to their asset — they do not automatically apply to an asset’s children.

A trigger can have an anomaly Code and a Severity, and you can have several different triggers on a single field, with different codes and/or severities. The dialog may also show a preview chart, showing which triggers apply at which KPs or depths.

Fields with out-of-range data are clearly identified on the form.

Data quality alerts

Even with the most rigorous of data validation regimes it is sometimes possible for inaccurate data to be entered. Data quality checks can additionally be established for calculation results by means of Traffic Lights and Reports. For example, a “Remaining Life” traffic light could be configured to shown any negative values as red. Simply turning on the traffic light enables you to spot and investigate any potential data issues.