{"id":3708,"date":"2026-10-31T13:00:00","date_gmt":"2026-10-31T05:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3708"},"modified":"2026-10-30T19:09:20","modified_gmt":"2026-10-30T11:09:20","slug":"meter-quality-flag-mapping","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/tr\/blog\/meter-quality-flag-mapping\/","title":{"rendered":"G\u00fc\u00e7 \u00d6l\u00e7er Veri Kalitesi Bayraklar\u0131: \u0130yi, K\u00f6t\u00fc ve Belirsiz De\u011ferlerin E\u015fle\u015ftirilmesi"},"content":{"rendered":"

Power meter data quality flags should travel with the measurement from its source to the final dashboard, alarm or report. A numeric value alone cannot tell the user whether the device supplied it successfully, whether the gateway retained an older sample, or whether an operator substituted it. Define the meaning of each documented source state, map it explicitly to the receiving system, and test what happens when information is unavailable. Never convert an invalid reading into an apparently valid zero merely to keep a chart continuous.<\/p>\n

This guide focuses on preserving quality meaning across an integration. It does not claim that every meter exposes quality registers. For the BY194 power instrument family<\/a>, obtain the exact variant’s communication documentation before specifying any status field, timestamp or invalid-value convention.<\/p>\n

For the overall connection and commissioning context, see the power meter Modbus communication guide<\/a>.<\/p>\n

Separate measurement value from measurement quality<\/h2>\n

A value answers a quantity question, such as the reported current or accumulated energy. Quality answers whether that value is suitable for its intended use under the receiving system’s rules. The distinction matters because a syntactically valid response can contain a measurement that is unavailable, outside a documented operating condition, manually substituted or retained from an earlier acquisition.<\/p>\n

Modbus provides protocol transactions and exception responses. It does not assign a universal meter-quality register to all devices. The Modbus Application Protocol specification<\/a> should be read alongside the instrument’s own register manual. An exception response concerns the transaction; a documented quality field concerns the measurement or source state. A gateway can also generate its own quality assessment, which must not be mislabeled as a device-reported condition.<\/p>\n

Industrial information models can carry value and status together. The OPC Foundation DataValue definition<\/a> illustrates this separation using a value, status and timestamps. If your destination uses OPC UA, apply its documented status semantics. If it uses another system, define that system’s actual behavior instead of borrowing labels without their meaning.<\/p>\n

\"BY194
Product-reference illustration of the disconnected BY194 front beside data quality mapping records. Device-specific features and installed options require exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Identify every place that can change quality<\/h2>\n

Draw the actual data path in the commissioning record: meter, serial network, gateway, collector, historian and dashboard, as applicable. For each stage, ask whether it can retain a previous value, perform calculations, substitute a fallback, change units or overwrite a status. The goal is a traceable chain of responsibility, not an assumption that every installation has all these components.<\/p>\n

Record what the source supplies and what the integration infers. If the device exposes a documented status, preserve the original code with its interpretation. If the collector marks a sample unavailable after a failed read, identify that as a collector state. If a derived total depends on multiple inputs, record how the calculation handles an unsuitable input and where that rule is configured.<\/p>\n

Keep quality distinct from freshness. A sample may have been acceptable when acquired but unsuitable for a current display after a long delay. The gateway stale data guide<\/a> covers age and caching in more detail. Here, the important requirement is that no intermediate stage silently upgrades an unsuitable or unknown sample to an accepted current value.<\/p>\n

Create a point-level mapping table<\/h2>\n

The following table is an example of decisions to document, not a list of flags available on a particular meter. Replace the source descriptions with the actual documented states and the destination behavior supported by your software.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
Source or integration condition<\/th>\nMeaning to preserve<\/th>\nReceiving-system behavior to define<\/th>\n<\/tr>\n<\/thead>\n
Successful documented measurement<\/td>\nAcquisition succeeded within stated limits<\/td>\nMark accepted only after decoding checks<\/td>\n<\/tr>\n
Documented invalid measurement<\/td>\nDevice cannot provide the defined quantity<\/td>\nExclude from normal calculations and show unavailable<\/td>\n<\/tr>\n
Failed acquisition<\/td>\nCollector did not obtain a new usable sample<\/td>\nRetain failure reason and acquisition time<\/td>\n<\/tr>\n
Retained prior sample<\/td>\nDisplayed number is historical<\/td>\nShow age and avoid calling it current<\/td>\n<\/tr>\n
Operator substitution<\/td>\nA person supplied a replacement value<\/td>\nIdentify substitution and responsible record<\/td>\n<\/tr>\n
Unsupported point<\/td>\nExact variant does not provide the quantity<\/td>\nDisable the point rather than fabricate zero<\/td>\n<\/tr>\n
Derived value with unsuitable input<\/td>\nCalculation lacks adequate source evidence<\/td>\nPropagate unsuitable quality under documented rules<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Agree these decisions with the people using the data. Maintenance dashboards, energy analysis and alarms can require different handling, but the underlying source evidence should remain recoverable. A report may omit unsuitable intervals while a diagnostic view displays them with a clear marker. Those are different presentations of the same evidence.<\/p>\n

Avoid losing information in a simplified status<\/h2>\n

A receiving platform may offer only a small set of labels such as good, bad and uncertain. If a richer source vocabulary must be reduced, document the conversion and keep the raw source state in a separate field where possible. Otherwise, a later investigation may be unable to distinguish an unsupported quantity from a timeout or a manually substituted sample.<\/p>\n

Do not select a destination code because its name sounds close. Read the destination’s definition and determine what downstream calculations, alarms and displays do with it. In OPC UA, consult the StatusCode definition<\/a> as well as the receiving application’s documentation. A vendor’s local label can carry additional behavior that is not obvious from the screen.<\/p>\n

Define the default for unmapped states. An unknown code should trigger review and remain visibly unclassified or unsuitable according to the approved design. Treating every unknown code as good makes future software or firmware changes particularly dangerous. Preserve the original code so a corrected mapping can be applied without guessing what occurred.<\/p>\n

Define calculation behavior before commissioning<\/h2>\n

Decide whether a calculation requires all inputs to be accepted. For a total formed from several feeders, one missing input can make the total incomplete even if the arithmetic runs successfully. If a report intentionally uses a partial total, label the coverage and missing boundary clearly. Do not present it as the complete site value.<\/p>\n

For interval analysis, retain the start and end evidence and the quality of the contributing samples. A gap does not establish zero consumption. Interpolation or substitution may be useful for a specific analytical purpose, but it creates an estimate and should be identified as such. Keep the measured series and the estimation method separate enough for a reviewer to reproduce the result.<\/p>\n

Numerical representation is another layer. A nonfinite number, a documented sentinel and a communication error require different handling. The invalid numerical value guide<\/a> explains representation checks. A quality mapping should preserve the distinction between these cases while preventing unsuitable values from quietly entering ordinary arithmetic.<\/p>\n

Test the entire path with controlled cases<\/h2>\n

Start in a safe test environment or with a supported simulator where possible. Exercise a documented accepted sample, a failed acquisition, a retained prior sample and an unsupported point. Use device-specific diagnostic or invalid states only when the manual describes a safe method. Never create a hazardous electrical condition merely to provoke a status flag.<\/p>\n

For each case, record what appears at every available stage. Capture the raw source response or simulator input, gateway value and state, collector record, historian entry and dashboard presentation. Compare the observed outcome with the approved mapping table. A test that checks only the first gateway screen can miss a historian or chart that later removes the quality information.<\/p>\n

Include recovery. Restore a valid input and observe when the system accepts new data again. Confirm that old failure markers remain in historical records where appropriate and that a current accepted state does not erase evidence of the earlier gap. If the system uses manual acknowledgement, record that behavior rather than assuming recovery is entirely automatic.<\/p>\n

\"BY194
Product-reference illustration of the disconnected BY194 front beside data quality mapping records. Device-specific features and installed options require exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Make quality visible without overwhelming the reader<\/h2>\n

A normal dashboard can show an uncomplicated accepted reading while making exceptions easy to identify. Use clear text, a consistent visual marker and an accessible explanation of what the marker means. Color alone is insufficient because users can overlook it or interpret it differently. A retained value should show its acquisition time or age when the platform supports that information.<\/p>\n

Reports need an equally clear rule. State whether unsuitable intervals were excluded, estimated or included with qualification. When comparing two periods, check that their coverage is comparable. An apparently lower energy total can result from missing intervals rather than an operational improvement. Provide enough context for the reader to decide whether the comparison is useful.<\/p>\n

Document alarm behavior separately from display behavior. A screen may retain the last known value for orientation while the alarm logic treats the source as unavailable. Both can be reasonable when explicitly designed. The serious error is allowing a convenient display fallback to become an undocumented accepted input for an alarm or decision.<\/p>\n

Control changes to the mapping<\/h2>\n

Store the approved mapping with the device list, register documentation and receiving application configuration. Record who approved it and which software versions were tested. The NIST operational technology guide<\/a> provides broader configuration and change-management context for operational systems; it does not specify a universal meter-quality algorithm.<\/p>\n

Retest when the register document, firmware, gateway template or destination processing changes in a way that can affect quality. Review unknown states and repeated substitutions as actionable maintenance evidence. A daily flood of ignored warnings is a sign that the mapping or operational process needs attention, not a reason to relabel everything as accepted.<\/p>\n

Educational background on floating-point arithmetic<\/h2>\n

This MIT 18.S191 lesson by Alan Edelman covers floating-point arithmetic, providing background for the numerical representation checks discussed above. Numerical validity and a source quality flag are separate questions. The approved meter manual and receiving-system documentation remain the sources for the actual quality mapping rules.<\/p>\n