{"id":3747,"date":"2026-11-01T13:00:00","date_gmt":"2026-11-01T05:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3747"},"modified":"2026-10-31T19:12:20","modified_gmt":"2026-10-31T11:12:20","slug":"meter-alarm-hysteresis-review","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/ar\/blog\/meter-alarm-hysteresis-review\/","title":{"rendered":"\u0627\u0644\u062a\u0628\u0627\u0637\u0624 \u0627\u0644\u062a\u0641\u0627\u0636\u0644\u064a \u0644\u0625\u0646\u0630\u0627\u0631\u0627\u062a \u0639\u062f\u0627\u062f \u0627\u0644\u0637\u0627\u0642\u0629: \u0636\u0628\u0637 \u0648\u0627\u062e\u062a\u0628\u0627\u0631 \u0646\u0637\u0627\u0642\u0627\u062a \u0627\u0644\u062a\u0628\u0627\u0637\u0624"},"content":{"rendered":"

Power meter alarm hysteresis<\/strong> uses different activation and clearance conditions to prevent a noisy measurement from repeatedly raising and clearing the same alarm. In a simple high alarm, the application activates at an upper threshold and clears only after the value falls below a lower threshold. The difference is the deadband. Set it from the operating requirement and measurement behavior, then test both directions, timing, invalid data and restart behavior.<\/p>\n

This guide concerns an external monitoring application receiving power meter measurements. It does not establish that any particular instrument includes programmable alarms, relays or built-in hysteresis. Confirm the exact device and software documentation before implementation.<\/p>\n

Understand why a single threshold can chatter<\/h2>\n

Imagine a monitored quantity fluctuating around an alarm threshold. If activation and clearance use the same value, every small crossing can create another transition. That can fill an event list while obscuring the underlying operating condition. It may also encourage operators to ignore alarms that appear repetitive.<\/p>\n

Hysteresis introduces state memory. Between the activation and clearance thresholds, the application keeps its previous state. A value inside that band is therefore not enough by itself to determine whether the alarm is currently active; the preceding sequence matters.<\/p>\n

The OPC Foundation example for on-delay, off-delay and alarm deadbands<\/a> explains these mechanisms as ways to manage repeated alarm generation. Its example distinguishes amplitude deadband from persistence delays. Use those distinctions to specify behavior rather than treating every nuisance alarm as a reason to widen the threshold.<\/p>\n

Define the monitored condition before choosing a deadband<\/h2>\n

Record the quantity, engineering unit, source point, quality requirements and consequence of the alarm. An operational high-demand warning is different from equipment protection. A dashboard notification must not be assumed to provide a protective function or meet a safety response requirement.<\/p>\n

For a high alarm, define activation at H and clearance at H minus D, where D is the chosen positive deadband in the same unit. For a low alarm, the clearance threshold is generally above activation. Verify how the actual software implements equality: \u201cgreater than\u201d and \u201cgreater than or equal to\u201d are different at the boundary.<\/p>\n

Also establish whether the configuration expects an absolute amount, a percentage of a threshold, a percentage of span or a separate reset value. Two interfaces displaying \u201c5%\u201d may produce different reset thresholds. Translate the configured setting into an explicit engineering-unit value during review.<\/p>\n

Use the three-phase meter overview<\/a> for measurement context and the meter data quality mapping guide<\/a> when defining which readings are eligible to drive the application.<\/p>\n

\"BY194
Product-reference illustration of the disconnected BY194 front beside application alarm review materials. The surrounding materials describe an external engineering workflow; installed meter functions require exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Separate hysteresis from time delays and filtering<\/h2>\n

A deadband addresses movement around a value boundary. An on-delay requires the activation condition to persist for a defined period. An off-delay requires the clearance condition to persist before clearing. Filtering changes the input signal used by the alarm, which can affect its response to real changes.<\/p>\n

These mechanisms can interact. A wide deadband may keep an alarm active long after the process has returned near normal. A long delay may suppress a short event that matters. Smoothing may make a signal look calm while delaying an important transition. Choose each setting for a stated reason and test the combined behavior.<\/p>\n

The following comparison describes general application behavior. It does not provide recommended settings or guarantee an instrument response time.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n
Mechanism<\/th>\nWhat it changes<\/th>\nUseful test<\/th>\nRisk to review<\/th>\n<\/tr>\n<\/thead>\n
Activation threshold<\/td>\nValue at which a condition begins<\/td>\nApproach from the normal side<\/td>\nWrong quantity or unit selected<\/td>\n<\/tr>\n
Hysteresis\/deadband<\/td>\nClearance value and state memory<\/td>\nReturn into the band from both directions<\/td>\nAlarm stays active unexpectedly<\/td>\n<\/tr>\n
On-delay<\/td>\nRequired activation persistence<\/td>\nShort pulse followed by sustained condition<\/td>\nSignificant short events suppressed<\/td>\n<\/tr>\n
Off-delay<\/td>\nRequired clearance persistence<\/td>\nBrief recovery then sustained recovery<\/td>\nClearance is slower than operators expect<\/td>\n<\/tr>\n
Input filtering<\/td>\nSignal presented to logic<\/td>\nStep and noisy-input replay<\/td>\nReal excursions obscured or delayed<\/td>\n<\/tr>\n
Acknowledgment<\/td>\nOperator recognition state<\/td>\nAcknowledge while condition remains active<\/td>\nAcknowledgment confused with clearance<\/td>\n<\/tr>\n
Quality handling<\/td>\nEligibility of stale or invalid input<\/td>\nInject invalid-quality records<\/td>\nMissing data mistaken for healthy operation<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

The OPC Foundation example supports the conceptual separation of deadband and delay. The acceptance cases here are a practical test design, not a claim of conformance to the entire OPC alarm model.<\/p>\n

Work through a high-alarm example<\/h2>\n

Consider an illustrative application warning at 100 kW with an absolute 5 kW deadband. Specify activation at or above 100 kW and clearance at or below 95 kW. Those equality rules are chosen for this example only. They must match the implemented software before the test is accepted.<\/p>\n

Starting from normal at 94 kW, move to 98 kW and expect normal. Move to 101 kW and expect active if no on-delay applies. Return to 98 kW and expect active because the signal has not reached the clearance threshold. Finally move to 94 kW and expect clearance. Starting a separate test from normal at 98 kW should remain normal. The same intermediate value can therefore correspond to different states.<\/p>\n

These numbers demonstrate logic, not a recommended demand limit or a BY194 alarm capability. The actual warning threshold belongs to the site’s operational plan. A protection setting requires its own approved engineering basis and equipment designed for that purpose.<\/p>\n

Test delayed behavior with a controlled input sequence<\/h2>\n

Use an approved software replay, simulator or isolated test environment where available. Do not force a live electrical load into a hazardous operating state just to produce an alarm. Keep the test input, actual output events and clock reference in the record.<\/p>\n

For an illustrative on-delay, create one excursion shorter than the configured duration, then a sustained excursion longer than it. Confirm the first does not activate and the second does at the expected application timing. Test whether a return to normal resets the timer or pauses it; do not infer that rule from the setting label.<\/p>\n

Repeat for off-delay and for interrupted clearance. Include exact boundary values, a value just inside the deadband and a value just beyond clearance. Use the meter polling interval guide<\/a> to assess whether the measurement collection cadence can support the intended observation. A timer cannot recreate an excursion that was never sampled or delivered.<\/p>\n

Decide what happens when the data becomes unusable<\/h2>\n

A communication timeout is not evidence that the monitored condition has returned to normal. Define how the application handles stale timestamps, invalid numbers and bad quality. Possible policies include retaining the last process alarm state while separately raising a data-quality condition, or declaring the process condition unknown. The right policy depends on the application and must be explicit.<\/p>\n

Do not substitute zero for an unusable reading unless that behavior is specifically justified. For a high alarm, zero could falsely clear the state; for a low alarm, it could generate a misleading event. Keep communication health separate from the measured operating condition.<\/p>\n

Review gateway stale measurement data<\/a> when a system continues showing a plausible last value after collection stops. Test reconnection as well as disconnection. A batch of old values arriving later should not be mistaken for the current operating sequence.<\/p>\n

Define startup, acknowledgment and configuration changes<\/h2>\n

When an application restarts with a value inside the deadband, it needs a documented initial-state rule. It may restore a persisted state or begin in an unknown condition until sufficient evidence arrives. Neither behavior should be assumed. Include this case in acceptance testing because it exposes hidden dependence on history.<\/p>\n

Acknowledgment records operator awareness; it does not necessarily mean the measured condition has cleared. Confirm that an acknowledged active alarm remains visible under the site’s operating procedure. Test whether new excursions or repeated alarms create new acknowledgment requirements.<\/p>\n

Changing a threshold while the value is inside the band can also change the expected state. Record whether the application reevaluates immediately, preserves state or requires a restart. Avoid editing settings during an unexplained live alarm without preserving the original event sequence.<\/p>\n

\"BY194
Product-reference illustration of the disconnected BY194 front beside application alarm review materials. The surrounding materials describe an external engineering workflow; installed meter functions require exact variant documentation.<\/figcaption><\/figure>\n<\/p>\n

Keep configuration and acceptance evidence together<\/h2>\n

Save the source point identity, units, thresholds, deadband definition, delay settings, equality rules and quality policy. Retain the software version, effective time, test input sequence and resulting transitions. The NIST operational technology security guide<\/a> supports controlled configuration and operational logging as broader management practices; it does not prescribe this article’s example values.<\/p>\n

A useful acceptance record shows expected versus observed behavior for every case and identifies unresolved deviations. Repeating only a successful high crossing is insufficient. Test clearance, return into the band, stale input, restart and acknowledgment separately. Where timing depends on collection or server load, document that limitation rather than claiming a universal response time.<\/p>\n

For product selection, the BY194 multifunctional power instrument family<\/a> provides a relevant measurement starting point. Confirm the exact variant and communication option, plus the actual measurement fields supported. Alarm processing may belong entirely to external software; the family image and optional communication description do not prove an onboard alarm engine.<\/p>\n

Further learning: hysteresis as state memory<\/h2>\n

The NPTEL IIT Guwahati lecture below explains comparators and Schmitt trigger circuits. It is included for the general principle of separate transition thresholds and memory. Its circuit examples are not a wiring instruction for a power meter or evidence of any built-in alarm feature.<\/p>\n