Power meter historian retention should preserve the evidence needed to explain energy totals, investigate faults and reproduce approved reports. Define separate retention rules for raw observations, quality flags, configuration changes and reporting aggregates. Keeping only monthly totals may be insufficient for a later interval dispute, while keeping every diagnostic packet indefinitely may add cost and access risk without serving an agreed purpose.
This guide helps engineering, maintenance and reporting teams define those rules together. It concerns the collection and storage system around a meter; it does not assume that a meter itself has a historian. Contractual, legal and regulatory retention requirements must be established by the responsible organization. The examples below are design questions and acceptance methods, not mandatory retention periods or compliance advice.
Start with the decisions the data must support
List the recurring questions that require historical evidence. Energy management may need interval profiles and production context. Maintenance may need the observations surrounding a communication fault. A disputed monthly total may require cumulative endpoints, quality flags and the configuration that interpreted the readings. These purposes need different detail and access patterns.
For each question, identify the earliest evidence that would make an answer possible. If a daily aggregate cannot identify a missing hour, retaining more daily aggregates will not solve that problem. Conversely, a raw packet trace is often unnecessary for an ordinary year-on-year monthly comparison. Choose granularity according to the decision rather than collecting the most detailed format everywhere.
The DOE federal metering guidance provides a program-level context for usable metering data. Translate that into a local evidence plan: who asks the question, which records answer it, how long they remain useful and how the organization verifies that they can still be retrieved.
Treat raw, corrected and aggregated data separately
Raw observations are the records received at collection, including their original values and timestamps where available. Corrected records add approved interpretation or replacement decisions. Aggregates summarize defined periods. These layers should remain distinguishable, even if they share one storage platform, because a report must explain which version and method produced its total.
Do not overwrite a raw missing value with an estimated interval and then call the resulting series measured data. Preserve the original state and the estimate’s method, author and approval. A later recovery of original readings may justify replacing a provisional estimate in the reporting layer, but the history of that correction still matters.
The article on quality flag mapping explains why quality information must survive system boundaries. Retention rules should cover flags and annotations alongside numerical values. A number without its invalid or stale state can become more misleading as the original operators and circumstances are forgotten.
| Record class | Typical purpose | Context that must remain linked | Retention decision question |
|---|---|---|---|
| Raw interval observations | Reconstruct profiles and identify gaps | Asset, unit, time basis, quality | How far back must detailed investigations reach? |
| Cumulative counter snapshots | Reconcile energy across a period | Counter scope, resets, scaling | Can an aggregate still be independently checked? |
| Corrected or estimated intervals | Produce approved reporting series | Original state, method, approval | Can a reviewer reproduce the correction? |
| Configuration history | Interpret historical readings | Effective time and exact revision | Can old data be decoded after equipment changes? |
| Reporting aggregates | Compare periods and communicate results | Method version and completeness | Is detail still needed behind the summary? |
| Diagnostic captures | Investigate bounded incidents | Route, collection method, limitations | Does an ongoing purpose justify continued storage? |
No duration in this table is a universal requirement. Assign periods through the organization’s actual reporting and governance obligations.
Define time and identity before calculating storage
Record whether timestamps identify measurement time, interval start, interval end or arrival time. Preserve a documented time zone and daylight-saving treatment. Two rows with the same displayed local time may represent different instants, while one late upload may contain observations from an earlier day. Retention cannot repair ambiguity that was never resolved at ingestion.
Keep hardware identity separate from installation role. A meter replacement may preserve the feeder name while changing the instrument and counter baseline. Store effective mappings so a historical query can find the correct hardware and configuration for the requested period. The guide to power meter configuration backups supports that configuration-history requirement.
Document units, scaling and measurement scope as versioned context. A column named energy is not enough to distinguish import active energy from export energy or another register. If a software update changes normalization, keep its effective time and transformation rule. Old raw values must remain interpretable without relying on today’s application defaults.
Estimate capacity using measured record sizes
Start with a sample export from the intended system. Measure the stored record size, including metadata, indexes and quality fields where relevant. Multiply by actual point count and collection frequency, then allow for the platform’s storage overhead and operational requirements. Do not infer production storage needs from the size of a compressed demonstration CSV alone.
A simple planning relationship is records per day equals point count multiplied by observations per point per day. Storage then depends on measured bytes per record and retained days. This is a sizing method, not a guaranteed compression ratio. Backups, replicas, indexes and diagnostic attachments may require separate capacity budgets.
Test a representative query and export before committing to a long retention window. A system can hold data but take too long to retrieve an incident period. Include the reporting team’s practical deadline in acceptance criteria. Record the tested volume, query range and export format so a later capacity change has a meaningful baseline.
Decide how detail ages into summaries
If older data will be aggregated, specify the exact method. Power samples, interval energy and cumulative counters require different treatment. Summing instantaneous power values does not automatically produce energy. Averaging cumulative counters does not produce consumption. The measurement type and time basis must determine the transformation.
Carry completeness information into the summary. A daily total assembled from only some intervals should not appear equivalent to a complete day unless the reporting method explicitly resolves the gaps. Preserve counts or coverage indicators appropriate to the dataset, together with any estimate flags. Explain the meaning to report users in ordinary language.
Before deleting detailed records, verify that the retained summary answers the agreed questions. Sample several cases: a complete normal day, a maintenance gap, a meter replacement and a corrected interval. If a reviewer cannot explain the total, revise the aggregation or retain supporting evidence. Keep observed and estimated values distinguishable in every retained summary, with the supporting correction record available for review.
Test retrieval and restoration as separate tasks
Retrieval checks whether the operating historian can return the intended historical records with their context. Restoration checks whether a protected copy can recover data after loss. A successful dashboard query does not prove a backup is usable, and a successful backup job does not prove its restored dataset includes configuration history and quality annotations.
The NIST OT security guide provides a basis for controlled access, backups and recovery planning in operational systems. Apply site-approved procedures and avoid disruptive restoration tests on production infrastructure. Use an isolated approved destination when testing recovered evidence.
Assign ownership and product requirements
Name the owner of raw collection, the owner of report corrections and the approver of deletion or retention changes. Record exceptions and their expiry or review date. Without ownership, storage cleanup can remove evidence that another team still relies on, or preserve sensitive operational records after their agreed purpose has ended.
For a system using the BY194 multifunctional power instrument family, confirm the exact variant’s readable quantities and communications documentation. Do not assume onboard interval storage, automatic buffering or a specific historical export function. The historian may reside entirely in a gateway or external application.
An inquiry should specify collection frequency, required measurement scope, interruption tolerance and historical questions. Request an acceptance demonstration that includes exporting old readings with identity, units, quality and configuration context. For broader measurement selection, consult three-phase electric power meters. That connects storage decisions to the actual measurement system rather than a generic database capacity target.
Review the retention plan after a reporting change or equipment replacement. A new calculation may require context that the previous archive policy discarded. Record that dependency before changing collection, aggregation or deletion rules, and test an older representative period against the revised reporting method.
Educational background
The following university lesson explains sampling. It provides background for deciding what information a sampled series contains and why a summary cannot recreate detail that was never retained. It does not specify historian retention periods or product functions.
Frequently asked questions
Is there one correct retention period for every power meter system?
No. Set periods from reporting needs, investigation windows and applicable organizational obligations. Document who approved each rule and which evidence must remain available.
Can monthly totals replace all raw interval data?
Only if they still answer every agreed question. They generally cannot reproduce an interval profile or explain individual missing samples without additional supporting records.
Is a successful backup job enough to prove recovery?
No. Test a controlled restoration and verify the recovered values, timestamps, quality flags and configuration context. Keep retrieval testing separate from recovery testing.
Does a BY194 meter necessarily contain a historian?
Do not assume that. Confirm the exact variant and system architecture; historical storage may be provided by an external gateway or application.