Reconciliation provides estimates of process variables based on combining measurement information with process knowledge (such as mass and energy balances) in the form of equations and inequality constraints. If the constraints are correct, and measurements fit assumptions about their noise, the resulting estimates will be better than those obtained just from raw measurements. Data reconciliation is generally accomplished by formulating a least-squares optimization problem to minimize a weighted sum of the measurement adjustments and solving it. At the basic stage the quality of the individual signal tags is checked and the quality information is stored together with the signal value in the data base.

The data reconciliation software supports the user in the following areas:

- Gross Error Detection

Gross errors are significant deviations from assumptions such as assumed error probability distributions in the case of measurements, or incorrect constraints. Gross errors in measurements typically reflect instrument failures, bias errors, or unusual noise spikes if only a short time averaging period is used. An example of a gross error due to an incorrect constraint is the unexpected presence of a significant leak. Gross errors invalidate the assumptions made in data reconciliation, so it is important to detect them and remove their effects. Otherwise, the reconciled estimates could actually be worse than just using the raw data. So, gross error detection is generally done prior to final estimates, although some techniques modify the problem to try to minimize the damage done by the gross errors. - Redundancy Analysis

Redundancy analysis determines which measurements could be estimated from other variables using the constraint equations. Without redundancy, data reconciliation cannot use the constraints to improve the estimates, so recognizing a lack of redundancy is key to knowing if the data reconciliation will be useful. - Data Reconciliation using least-squares optimization

For a defined balance area, where "n" flows are crossing the area's border and where "n" mass flow rates are available and known, the total of all flows (entering flows added, leaving flows subtracted) must be near to zero as long as all "n" mass flow values are correct. The acceptable deviation from zero is depending on the accuracies of all individual flows used in the balance. Thus, the accuracies of all related measurements must be defined in the Tags' property data base, and in all calculation steps, these accuracies are to be tracked for signal values respectively calculated for result values and balance totals. This is automatically performed once the calculation equations are configured.

Concerning the final results of a two stage Data Reconciliation for "n" flows the following cases are possible:

- If the individual quality of more than one flow is bad, Data Reconciliation is not possible for all "n" flows.
- If the individual quality of exact one flow is bad, Data Reconciliation is not possible for all "n" flows, but the resulting mass flow rate of the "bad quality" Tag can be calculated.
- If the individual quality of all "n" flows is good, the Data Reconciliation balance can be calculated and its result can be judged:
- If the deviation from zero is outside of the limit, the qualities of all "n" Tags are marked as "good, reconciliation failed",
- If the deviation from zero is inside the limit, the qualities of all "n" Tags are marked as "reconciled", which is the best possible quality.

The benefit of this type of Data Reconciliation is to get an alarm if a measurement device is not obviously failed but is having a "hidden" drift. In this case the wrong measurement cannot be identified by the application, but the alarm will indicate, that one of the "n" flows is having a "hidden" defect.

If more than "n" measurements are available for a balance area of "n" flows, then even the identification of the defect flow measurement could be possible under certain conditions.

The balances and the resulting qualities are stored as calculated Tags in the **proIMS** **RTDB**. The values and qualities of these "mirrored" Tags can be displayed in all kinds of **proIMS Reports** or WEB Displays.