Part 3 - The Cost of Poor Data Quality

This post is the third in a series related to this important topic, and builds on the information previously presented. If you have not read the previous posts, Part 1 and Part 2 may be found here and here, respectively. 

Reporting is a broad topic because it encompasses the needs of many different types of users and formats. Operators use real time data and trends for fault analysis, Performance Engineers relay on aggregates (e.g. Min, Max, Average, Summations, and calculated indexes) for comparisons, and Business Users look use energy and fuel summations over different settlement periods (e.g. 5m, 10m, 15m, hourly, daily, monthly, quarterly, annual, LTD) to support revenue estimates and  model-vs-actual performance comparisons.

Satisfying requirements of all these different users is a challenge for most organizations.

First, normalizing units.

Acuity’s device data mapping structure assigns engineering units to all data logged and archived, where the device’s engineering unit is converted into a system-default engineering unit automatically.

The most common example of this would be power. If an inverter’s power output is being reported as watts (W), Acuity stores the measured value as kW (where 1 Kilowatt = 1,000 Watts) which is Acuity’s default system engineering unit for all measurements recorded for power. The advantage to normalizing similar measurements to known units is that all reporting can be performed from a common scaling factor regardless of the manufacturer, make, or model of equipment within a single facility, or across a of fleet of multiple projects. While this may seem like an obvious step in the data collection for any organization, Acuity’s ability to enforce this at the lowest level in the data collection process removes complexity and confusion from all upstream businesses processes.

Second, pre-calculated values.

Whether your organization is used to using 15m internal data, hourly, or some other time-span for reporting; at some point either the range of the reporting period or the number of devices being examined will create some pretty monumental spreadsheet challenges for analysts.

A common use case … in any month, compare the total energy measured at the meter to the sum of all the string inverters on a site to verify there is not a large discrepancy buried in the dataset.

Even using hourly data and 10 string inverters for a 30 day month, this would require a spreadsheet that supported 11 horizontal columns (you need the meter too), and (10 inv * 24 hrs/day * 30 days =) 7,200 rows to calculate and compare. What if it were 208 string inverters for the same time period and 15 minute data? 209 rows and 601,920 rows.

It’s not hard to understand how this can become unmanageable quickly … and that’s for a single 5,000MW facility! How will you manage 20 facilities in a portfolio, or 200 facilities in a fleet of portfolios?

These are real issues with scale and data collection many organizations struggle with.

Acuity addresses the requirements of these audiences with both high resolution interval data, archived at 1 minute, and also pre-calculated values called KPIs (or Key Performance Indicators).

1 minute interval data provides operators and engineers the resolution they require for trend analysis of equipment start/stop events, fault reporting, and precise equipment availability studies.

Every minute, Acuity updates a set of KPIs based on algorithms that efficiently summarize the up-to-the-minute values for the current production day. A few examples of KPIs include: Total Daily Energy Exported (kWh), Total Daily Energy Imported (kWh), Maximum Power Exported (kW), Maximum Power Imported (kW). KPIs are not limited power and energy at the Facility level only. KPIs are utilized at both device and facility levels, and include all aspects of operational data including temperature, metering fundamentals, tracers, weathers station sensors, and more. 

While KPIs are calculated up to-the-minute for the current day, at the end of each production day, the final calculated value is archived to include a final roll-up that represents full day for historical reporting purposes.

Using our 10 inverter and 30 day example from above, instead of 11 columns and 7,200 rows of data using interval data, using KPIs this dataset is now 2 columns wide and 30 rows high; where the first column in total daily energy from the meter and the second column in total daily energy from all the inverters. A much more manageable dataset for analysis.

In the event that there is an erroneous KPI value for the inverter total, similar daily total energy values exist for each inverter to allow for drill-down style analysis … where each layer: facility-to-device-to-measure is available as it is required, rather than dealing with a huge dataset up front. This approach makes reporting lightning fast, and allows reporting staff to focus on where there are actually problems and delivering reports in a timely manner where no problems exist. 

A final note on KPIs. While a majority of KPI values represent a single value (e.g. Maximum Power Exported (kW) = 3,745), some KPIs store arrays of data to enable common graphing tasks and intra-day reporting requirements. Examples include power-vs-fuel graphing and hourly energy reporting for time-of-use (TOU) calculations.

Normalization and pre-calculated KPIs are part of the secret-sauce that differentiates Acuity from other SCADA or cloud-monitoring solutions, where the data collection and analysis pipeline is architected to support the needs of the end users who rely on information to support critical operational and reporting requirements.

The final post in this series will examine how the availability of real time data, interval data, and KPIs in a single interface enables Acuity’s revolutionary user interface and visual analysis tools.