{"id":3778,"date":"2026-11-03T09:00:00","date_gmt":"2026-11-03T01:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3778"},"modified":"2026-11-02T19:15:13","modified_gmt":"2026-11-02T11:15:13","slug":"meter-historian-retention","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/vi\/blog\/meter-historian-retention\/","title":{"rendered":"L\u01b0u tr\u1eef L\u1ecbch s\u1eed \u0110\u1ed3ng h\u1ed3 \u0110o C\u00f4ng Su\u1ea5t: Gi\u1eef B\u1eb1ng Ch\u1ee9ng N\u0103ng L\u01b0\u1ee3ng H\u1eefu \u00cdch"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

Start with the decisions the data must support<\/h2>\n

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.<\/p>\n

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.<\/p>\n

The DOE federal metering guidance<\/a> 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.<\/p>\n

Treat raw, corrected and aggregated data separately<\/h2>\n

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.<\/p>\n

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.<\/p>\n

The article on quality flag mapping<\/a> 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.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Record class<\/th>\nTypical purpose<\/th>\nContext that must remain linked<\/th>\nRetention decision question<\/th>\n<\/tr>\n<\/thead>\n
Raw interval observations<\/td>\nReconstruct profiles and identify gaps<\/td>\nAsset, unit, time basis, quality<\/td>\nHow far back must detailed investigations reach?<\/td>\n<\/tr>\n
Cumulative counter snapshots<\/td>\nReconcile energy across a period<\/td>\nCounter scope, resets, scaling<\/td>\nCan an aggregate still be independently checked?<\/td>\n<\/tr>\n
Corrected or estimated intervals<\/td>\nProduce approved reporting series<\/td>\nOriginal state, method, approval<\/td>\nCan a reviewer reproduce the correction?<\/td>\n<\/tr>\n
Configuration history<\/td>\nInterpret historical readings<\/td>\nEffective time and exact revision<\/td>\nCan old data be decoded after equipment changes?<\/td>\n<\/tr>\n
Reporting aggregates<\/td>\nCompare periods and communicate results<\/td>\nMethod version and completeness<\/td>\nIs detail still needed behind the summary?<\/td>\n<\/tr>\n
Diagnostic captures<\/td>\nInvestigate bounded incidents<\/td>\nRoute, collection method, limitations<\/td>\nDoes an ongoing purpose justify continued storage?<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

No duration in this table is a universal requirement. Assign periods through the organization’s actual reporting and governance obligations.<\/p>\n

Define time and identity before calculating storage<\/h2>\n

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.<\/p>\n

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<\/a> supports that configuration-history requirement.<\/p>\n

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.<\/p>\n

\"BY194
Product-reference illustration of a disconnected BY194 front beside external power meter historian retention review records. Surrounding records illustrate an engineering workflow; installed functions depend on exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Estimate capacity using measured record sizes<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Decide how detail ages into summaries<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Test retrieval and restoration as separate tasks<\/h2>\n

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.<\/p>\n

The NIST OT security guide<\/a> 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.<\/p>\n

\"BY194
Product-reference illustration of a disconnected BY194 front beside external power meter historian retention review records. Surrounding records illustrate an engineering workflow; installed functions depend on exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Assign ownership and product requirements<\/h2>\n

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.<\/p>\n

For a system using the BY194 multifunctional power instrument family<\/a>, 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.<\/p>\n

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<\/a>. That connects storage decisions to the actual measurement system rather than a generic database capacity target.<\/p>\n

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.<\/p>\n

Educational background<\/h2>\n

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.<\/p>\n