Edge Anomaly Detection
Detect unusual conditions close to physical assets, with data-quality context and controlled operational response.
An anomaly is a signal for investigation, not an explanation or a final decision. Edge anomaly detection keeps the inputs, timing, model execution, evidence, and first operational response close to the asset, so teams can act on a result they can inspect rather than on an opaque alert from a remote pipeline.
Detect deviation without confusing it with diagnosis
An anomaly detector identifies a measurement, event sequence, image, sound, or multivariate pattern that differs from an expected baseline. The baseline can be a simple threshold, a statistical distribution, a learned model, a peer comparison, or a domain-specific rule. In all cases, the result means that the condition deserves attention; it does not by itself identify the cause, prove a failure, or authorise a high-consequence action.
At the edge, anomaly detection can run close to cameras, instruments, controllers, and local services. This reduces the need to move raw high-volume data before an initial assessment can be made, and it preserves the source context needed for a technician, analyst, or domain operator to review the result. The remote system receives the selected outcome and evidence reference rather than becoming the mandatory path for every input.
Banalytics provides the local orchestration layer around this workflow. An Agent connects approved inputs, manages local components and tasks, retains configured data, receives structured results from a specialist model, creates events, and routes the approved outcome to dashboards and integrations. See What is Banalytics? for the platform scope.
Preserve the path from input to operational event
| Stage | Responsibility | Evidence that should remain available |
|---|---|---|
| Acquire | Read the source close to the asset and validate that it is present, correctly timed, and within the expected technical range. | Source identity, location, device health, timestamp, unit or format, and freshness state. |
| Prepare | Apply documented preprocessing, windowing, feature extraction, or selection rules. | Configuration version, input window, preprocessing revision, and any data-quality exclusion. |
| Score | Run a statistical, rules-based, or learned detector through an independent processing module or local task. | Model or rule version, anomaly score, threshold, confidence where applicable, and execution status. |
| Contextualise | Correlate the score with local state, related events, system health, and permitted retained evidence. | Associated measurements, camera or sensor context, host health, previous events, and time correlation. |
| Respond | Create a bounded operational event and hand it to the person or system responsible for review. | Severity, recipient, response expectation, acknowledgement, and downstream-delivery state. |
This separation makes the detector maintainable. A sensor integration can change without silently changing the model; a model can be upgraded without rewriting the maintenance workflow; and the receiving system can consume stable event metadata instead of depending on a proprietary raw feed. The acquisition-to-processing-to-orchestration model is described in How Banalytics Works for Industrial Sensing.
Choose the simplest detector that answers the operating question
| Pattern | Suitable input | Typical edge outcome |
|---|---|---|
| Threshold and rate-of-change rule | A single measurement with a known operating band or permitted change rate. | Explicit out-of-range or rapid-change event with source freshness and local context. |
| Baseline deviation | Repeated measurement or signal where normal behaviour varies by time, load, environment, or operating mode. | Deviation score and comparison window for a reviewer; baseline updates remain controlled and versioned. |
| Multivariate or feature-based anomaly | Several related sensor, waveform, image, or process features whose combination is more meaningful than one value. | Structured score from a specialist module, accompanied by the input-quality and model-version information needed for evaluation. |
| Visual or acoustic observation | Camera frames, recordings, or audio streams where the anomalous condition is spatial or spectral. | Selected detection or anomaly event, configured evidence reference, and human-review workflow; the model is not a safety authority. |
| Data-quality anomaly | Missing updates, corrupt payloads, impossible values, unexpected device state, or a stalled processing module. | Source-health event that prevents a data-path failure from being misread as a normal process condition. |
A complex model is not automatically a better operational detector. If a documented threshold or freshness rule identifies the relevant exception with fewer false alarms and clearer maintenance ownership, use it. Introduce learned models where they add measurable value beyond the simpler baseline.
Keep specialist analytics independent of the operational shell
An anomaly model may be delivered as a Python service, native process, C++ or CUDA pipeline, vendor SDK wrapper, or research module. Banalytics can own the device connectivity, local storage, event lifecycle, dashboard context, runtime monitoring, and downstream delivery while the specialist module owns the detection method. This avoids forcing every algorithm into the platform and makes it possible to change the model without rebuilding the surrounding operation.
The interface should state input schema, input window, units, source time, expected throughput, output fields, error behaviour, health signal, model version, and what happens when the module is unavailable. For local process exchange, ZeroMQ Socket can provide an explicit low-latency messaging contract where both sides share the same schema. MQTT, APIs, files, or other controlled interfaces may be more suitable for other boundaries.
For camera workloads, local YOLO detection can create object-detection events. Project teams remain responsible for proving that a model, threshold, and evidence path are suitable for the site, lighting, season, equipment state, and decision being supported.
Run in shadow mode before asking operators to rely on the result
- Define the operational question. Name the anomaly, affected asset or process, expected owner, and response that the detector is intended to support.
- Establish data quality first. Verify source timing, units, calibration, missing-data handling, retention, and local host capacity before interpreting a model score.
- Collect representative baseline data. Include normal operating variation such as load, weather, shift, product, season, maintenance state, and environmental noise.
- Run in shadow mode. Retain scores and evidence alongside the existing workflow without changing a high-consequence operational action.
- Review false positives and false negatives. Determine whether they originate in the model, the source, preprocessing, an incorrect baseline, or the chosen response threshold.
- Promote a bounded response. Start with an operator notification, inspection task, or selected integration event; retain human review and domain authority.
- Version and monitor the lifecycle. Record model and configuration revision, acceptance criteria, rollback path, and the owner of retraining or threshold changes.
Banalytics modules are independently versioned, helping a deployment inspect and manage the capability installed on an Agent. See Version and Module Management for the operational lifecycle model.
Route an anomaly to a responsible review, not an automatic conclusion
Banalytics Event Manager evaluates configured events and invokes preconfigured actions. A rule can retain an evidence record, notify a responsible team, publish a concise MQTT message, or deliver a carefully scoped integration payload. The event should preserve source, time, score or state, data quality, model or rule version, severity, evidence reference, and the expected response owner. See Event Manager for the rule-and-action model.
Monitor the edge node as part of the detection path. Banalytics System Monitor reports CPU, memory, disk, thread, media, WebRTC, and user-activity metrics as System state events. A resource-constrained host, full storage, stale sensor, unavailable model, and broken external consumer are distinct failure modes; each needs a different runbook and should not be collapsed into an undifferentiated “anomaly” alert.
For safety, regulatory, or high-consequence decisions, the designated dedicated system and accountable operator retain authority. Edge anomaly detection can reduce time to good evidence and support a better decision; it does not replace independently engineered protection, safety, or statutory control systems.
Use it when local evidence changes the quality or speed of the response
- Raw inputs are high-volume, time-sensitive, confidential, or operationally useful even when a remote connection is unavailable.
- The recipient needs local source context and evidence to distinguish a genuine deviation from a failed data path.
- A research or specialist model needs a stable operational shell for acquisition, health, storage, events, and selected delivery.
- The organisation can name the model owner, data owner, review workflow, acceptance criteria, and maintenance lifecycle.
- The detector can begin in advisory or shadow mode and be expanded only after it proves value in representative conditions.
Edge anomaly detection is successful when the organisation can answer a simple question after every event: what changed, how reliable is that observation, who should review it, and what information do they need to act responsibly?