Event Detection Methods

Event detection converts telemetry into five-minute device flags that can be anomalous, nominal, or unknown. This page focuses on the evidence models. It is especially important to distinguish BESS status-based detection from BESS status-less detection: they run independently, answer the same availability question from different telemetry, and are merged only after each has produced its own result.

Nullable evidence semantics

Across the current pipeline, a device state has three values:

• True — sufficient evidence that the device is anomalous or unavailable.
• False — sufficient evidence that the device is nominal or has recovered.
• NA — no defensible conclusion from this method at this timestamp.

This is not cosmetic missing-data handling. It controls Event opening, closing, merging, hierarchy behavior, and BESS slow-close state.

For BESS, status-based and status-less flags are combined with three-valued logic:

True  OR anything = True
False OR False    = False
False OR NA       = NA
NA    OR NA       = NA

Therefore, one method can establish an Event even when the other is unknown, but one method's nominal result cannot erase another method's uncertainty.

PV power-based detection

PV power detection asks whether a device is producing a minimum fraction of its capacity while irradiance says it could reasonably be operating.

The current configuration uses:

• a POA gate of 125 W/m²; and
• an offline threshold of 0.005 times device or project capacity.

The relevant power channels include meter active power, inverter AC power, inverter-module AC power, and DC combiner power. Device capacity is converted to the units of each channel before comparison.

At each sample:

• measured power below the capacity threshold and POA at or above the gate produces True;
• measured power at or above the threshold under qualifying POA produces False;
• missing measured power produces NA; and
• samples below the POA gate produce NA, because darkness or low irradiance is not evidence of equipment recovery or failure.

An all-missing device series is treated specially to preserve existing operational behavior: it can be flagged under qualifying POA. Individual missing samples in an otherwise reporting series remain unknown.

Dawn handling

The pipeline guards against nuisance Events during asynchronous startup. For inverter modules, it identifies cases where some but not all sibling modules have started while POA is below 600 W/m² and treats those samples as unknown.

It can also backfill the first daily offline detection by up to 60 minutes using a reduced POA threshold of 75 W/m² (125 - 50). Backfill requires at least two consecutive qualifying samples. This recovers a more realistic Event start without letting a single dawn sample create an Event.

Temporal qualification

An isolated True between nominal samples is removed. During interval creation, an interior True–NA–True sequence is treated as one continuous run so a short communications gap does not fragment an outage. Leading and trailing unknown samples do not independently open or prolong a new Event.

A new PV Event normally requires 15 minutes of anomalous time while POA qualifies. The duration is not simply wall-clock duration: nighttime or below-threshold samples that were carried forward for state continuity are excluded.

Tracker and curtailment paths

Tracker flags compare measured tracker position against the expected true-tracking and backtracking pattern. Localized deviations stay at tracker-row level; simultaneous row conditions may roll up to the tracker zone. Tracker flags join the general PV detection results after the ordinary power hierarchy pass.

Curtailment is detected from curtailment-specific controls and setpoints. Curtailment flags deliberately bypass ordinary hierarchy sweep and rollup so a curtailment classification is not converted into a generic device-offline ancestor Event. Curtailment Events are also exempted from the ordinary minimum-duration rejection when the curtailment evidence overlaps the detected interval.

BESS status-based detection

Status-based detection interprets configured status and alarm tags. It does not infer unavailability from power.

Inputs

Status and alarm tags are retrieved for BESS PCS modules, PCS devices, banks, project breakers, and project reclosers. Each tag has a status lookup that identifies a binary layout. Each bit definition can include:

• bit position;
• nominal bit state;
• human-readable true and false states;
• description; and
• a configured failure mode.

Bit decoding

For each observed tag value, every configured bit is inspected. A bit becomes an alert when its actual state differs from its configured nominal state. A bit with no nominal state contributes descriptive status but does not create an alert.

The device flag at a timestamp is True when any of its reporting status tags contains an alert bit. It is False when reporting tags are present and none is alerting. If all relevant tag values are missing, the device flag remains NA.

Status descriptions from multiple tags are merged into one per-device representation. Failure modes from all abnormal bits are de-duplicated. A single mode is represented directly; multiple simultaneous modes remain candidates until Event-level inference.

Window continuity

The status lookup extends six hours before the nominal analysis start so the close decision can observe a sufficiently long recovery. A preexisting open Event seeds its device to True immediately before the retrieved series; that state is then carried forward through missing samples for that preexisting device. A device without a preexisting Event does not receive that assumption.

Missing status telemetry therefore behaves asymmetrically by design:

• for a new device condition, missing data is not evidence to open an Event;
• for a preexisting open Event, missing data is not enough to close the Event.

BESS status-less detection

Status-less detection infers unavailability without decoding status words. It uses real-power participation and, when available, charge/discharge availability. The name means “without status telemetry,” not “without state.” It still produces the same three-valued availability state as the status-based path.

The supported target device types are currently:

• BESS PCS;
• BESS PCS module group;
• BESS PCS module; and
• BESS string.

Each type has configured channels for real power, available charge power, available discharge power, and preferred capacity metadata.

Project activity gate

The project meter establishes whether the plant is active enough to judge a device by participation. Absolute meter power below 10% of project POI is indeterminate for opening a power-based device condition. If POI is unavailable, project AC capacity is used.

Project activity is debounced over 15 minutes with a 90% required fraction. A device group can still use the power path when its peer fleet is demonstrably active, even if the project-level gate is not yet active. The peer fleet is active when median absolute group power exceeds 5% of the group's median device capacity.

Availability path: preferred when supported

When a device has both charge-availability and discharge-availability tags, a valid availability signal, and usable capacity, availability takes precedence over the real-power path.

A device is unavailable when both available charge power and available discharge power are below 5% of device capacity. It is available when either is at or above that threshold.

Opening requires the project activity gate and a 15-minute rolling window with at least 75% unavailable samples. Closing uses a shorter five-minute rolling window with at least 75% available samples and does not require project activity. This asymmetry prevents opening an Event while the plant is idle but permits prompt recovery when availability returns.

Availability is carried forward as a state signal. An entirely missing tag remains missing; the pipeline does not synthesize zero availability from missing telemetry.

Power-participation path

If usable availability telemetry is absent but device power is available, the pipeline compares the device's absolute power with both its peers and a meter-derived reference.

The peer reference is the median absolute power of other devices of the same target type. At least two reporting peers are required. The meter reference is:

abs(project meter power / fleet size × 0.25)

When capacity is known, the meter reference is floored at 5% of device capacity.

With a peer reference, a device is low when its absolute power is below 10% of peer median and, when capacity is known, below 5% of its own capacity. It is active when it clears either of those thresholds. If a peer reference is unavailable, the meter reference is used.

For fleets smaller than ten devices, the rule is more conservative:

• low power must satisfy both the peer and meter low-power tests; and
• active power may satisfy either recovery test.

Power entry uses a 15-minute rolling debounce. The required fraction is 95% for small fleets and 90% otherwise. Power exit uses a five-minute window with a 75% required fraction.

Status-less unknowns

Status-less detection returns NA when neither availability nor power provides evidence. The following do not become automatic offline flags:

• tags that exist but have no values;
• missing capacity when the selected path requires a capacity comparison;
• an inactive plant without active peer evidence; and
• a device type with no supported telemetry path.

The status-less lookup also extends six hours into the lookback and applies the same preexisting-Event continuity seed as the status path.

Merging the BESS paths

Status and status-less detection do not have a primary/secondary relationship. Their results are merged per timestamp and device, after which hierarchy processing and interval creation operate on a single evidence set.

Some practical consequences:

• an abnormal status bit opens an Event even if power participation looks normal;
• clear status cannot close an Event while the status-less path is still anomalous;
• clear status plus unavailable status-less data yields unknown, not healthy;
• power-based recovery cannot erase an active decoded alarm; and
• a device with no status configuration can still receive an Event from availability or participation telemetry.

Failure-mode evidence remains path-specific. Status-derived abnormal bits can supply a specific failure mode. A purely status-less Event normally reaches the fallback assignment based on device type.

BESS slow close

After the two BESS paths are merged, BESS uses a six-hour recovery grace period. A False segment following a True segment is treated as continuous until the nominal segment has lasted six hours. This applies across analysis boundaries because both detection paths include the lookback.

The direct evidence before that grace period is retained separately:

• open plus directly anomalous evidence becomes active;
• open plus unknown evidence remains active;
• open plus directly recovered evidence, while the grace period still holds the interval open, becomes pending close; and
• after six hours of continuous recovery, the end time is set to the first recovered sample and the Event becomes closed.

The close timestamp is the beginning of recovery, not the time at which the six-hour confirmation completes. The grace period changes confidence in closure; it does not bill the confirmation interval as anomalous once closure is established.

Interpreting a detection

For a BESS Event, determine the originating evidence before interpreting the failure mode:

1. Check decoded status bits and their nominal-state configuration.
2. Check whether charge/discharge availability was valid; if so, it superseded the status-less power path.
3. Otherwise inspect meter power, peer median, device power, capacity floors, fleet size, and debounce state.
4. Compare the status and status-less flags before they were merged.
5. Inspect the direct evidentiary flag at the end of the window to distinguish active from pending close.
6. Finally inspect hierarchy transformation, because the final Event device may be an ancestor of the device where the evidence originated.