Computer Vision Edge
Turn local video into a bounded operational signal-with evidence, context, and human accountability kept close to the scene.
Edge computer vision is not a camera stream sent to an AI service. It is a local operating chain that acquires a permitted video source, applies an explicit visual method, filters its output by scene and purpose, and delivers a reviewable event to the people or systems that can act on it.
Place inference where the visual context is created
Computer vision at the edge processes image or video data on, or near, the equipment that receives the stream. The local node can select frames, run a model, apply zones and thresholds, retain configured evidence, create an event, and keep the defined local workflow available when a wide-area connection is slow or unavailable.
That proximity changes the architecture. A remote service does not need to receive every camera frame merely to decide that a vehicle entered a loading area, a person entered a restricted zone, an animal crossed a perimeter, or a visible condition warrants review. The remote consumer can receive the selected outcome and its permitted evidence reference instead.
Banalytics provides the edge operating layer around this workflow: an Agent runs on owner-selected hardware, connects approved cameras and local services, executes tasks, creates events and actions, retains configured data, and exposes selected views through the browser. The platform is not a claim that a visual model is universally correct; model suitability, operating policy, and the decision authority remain with the deployment owner.
Design a visual decision path, not just an inference call
| Stage | What the edge system does | What must be defined by the project |
|---|---|---|
| Acquire | Connect an approved local camera or video source and confirm usable framing, timing, and stream health. | Purpose, camera position, field of view, lighting range, access rights, retention, and source owner. |
| Prepare | Select a suitable frame path, cadence, resolution, and optional motion gate before inference. | Latency budget, expected object size, acceptable image quality, privacy masks or excluded areas, and failure behaviour. |
| Infer | Run the selected model locally or exchange data with a specified local model service. | Model version, target classes, known limitations, performance envelope, and conditions outside validation. |
| Filter | Apply confidence, object-class, zone, overlap, and repeat-event rules to the model output. | Which observation matters in which zone, what should be ignored, and the cost of a false alert or missed observation. |
| Act and review | Create a contextual event, retain allowed evidence, notify a responsible role, or publish a selected integration message. | Named recipient, review deadline, escalation path, audit evidence, and whether the outcome is advisory or control-relevant. |
A practical deployment begins with a narrow question: "What visual condition should a local team review?" It should not begin with a broad promise to recognise everything visible in the scene.
Connect the camera, model, event, and response as separate responsibilities
The Network Camera component connects IP camera streams through a direct URI, including RTSP, HTTP, or HTTPS where appropriate. ONVIF-capable equipment can use the dedicated ONVIF Camera component. A camera can then host local tasks for capture, recording, motion detection, or object classification.
YOLO Detection runs object detection through a selected YOLO worker. It can filter returned detections by target class and configured trigger or insensitive areas, optionally draw labels and bounding boxes, and emit a MotionEvent after configured conditions are met. Its event output includes accepted classes, triggered zones, approximate relative overlap area, and the originating task identifier.
The Event Manager then turns that observation into a site-specific workflow. For example, it can preserve approved evidence, create a dashboard-visible event, notify a responsible team, publish a concise MQTT message, or invoke an approved integration. Separating these responsibilities keeps camera transport, inference, rule logic, and business response independently testable.
Use local vision when visual evidence changes an operational response
| Operational question | Useful local vision pattern | Bounded outcome |
|---|---|---|
| Has a vehicle entered a loading or safety zone? | Vehicle classes filtered by a defined polygon and a controlled repeat interval. | Dock, gate, or safety review event with camera and zone context. |
| Is a person present where site policy requires attention? | Person class in a restricted area, with irrelevant background and public areas excluded. | Human review or security workflow-not an automatic identity or intent decision. |
| Is there a visible queue, occupancy change, or obstruction? | Class or coverage signal measured within a clearly defined scene. | Operational indicator for a supervisor or local process owner. |
| Has wildlife or another approved object appeared near infrastructure? | Target class and scene zones, assessed against season, light, and local false-positive history. | Observation and evidence package for the responsible environmental or safety team. |
| Does an asset show a visual condition that needs inspection? | Specialist model or deterministic image method with controlled input and documented acceptance criteria. | Inspection request with evidence; engineering judgement retains the maintenance decision. |
These patterns are deliberately operational, not biometric or behavioural profiling claims. A visual model can provide a useful observation without being a reliable basis for identity, intent, eligibility, safety shutdown, or other high-consequence decision.
Control load by reducing unnecessary inference, not by hiding overload
Inference cost depends on model, backend, image size, camera count, frame cadence, hardware, competing workloads, and scene complexity. Do not begin by classifying every frame from every stream. Establish the operational latency target, then choose the least expensive input path that still supports the decision.
- Gate on motion where appropriate. Run classification after motion detection when the business question does not require continuous visual analysis.
- Set a deliberate detection interval. YOLO Detection supports a classification delay, allowing the team to tune inference cadence independently from camera frame rate.
- Use zones and class filters. Excluding roads, reflections, screens, trees, or irrelevant areas reduces nuisance events and makes validation more meaningful.
- Observe the runtime. High worker wait time, stale frames, unavailable cameras, CPU pressure, memory pressure, or full storage are operational conditions, not invisible background noise.
- Test the actual scene. Day/night transitions, weather, seasonal background changes, camera angle, glare, compression, and object distance can change both accuracy and cost.
System Monitor exposes host CPU, memory, disk, thread, media, WebRTC, and user-activity state as system events. Pair those signals with camera and worker health so a missing result is distinguishable from a confidently negative visual observation.
Measure whether the workflow is useful in its real environment
Confidence is a model score, not a guarantee that a detection is correct. A threshold that works in a daylight test may perform poorly at night, in rain, during maintenance, or after a camera is moved. Validation must cover representative conditions and the real cost of false positives, false negatives, delayed review, and missing evidence.
- Specify the observation. Define class, zone, time window, minimum evidence, and intended responder.
- Record a representative baseline. Include normal activity, difficult conditions, camera outages, and known nuisance sources.
- Run in shadow mode. Compare events with human review before they influence a production workflow.
- Review errors by cause. Separate model errors from bad framing, lighting, stream loss, misconfigured zones, and delayed processing.
- Version the deployment. Track model, worker, threshold, zone, camera configuration, and rule changes so results remain explainable.
- Keep a human decision point. Start with alerting or inspection; do not grant unvalidated vision output autonomous safety, disciplinary, or access-control authority.
Data governance belongs in the same design. Limit collection to the stated purpose, restrict who can see live or retained visual data, define evidence retention, and ensure a camera can be disabled or reconfigured by the accountable owner. Local processing can reduce unnecessary data movement, but it does not remove those obligations.
Keep raw video local unless a defined use needs it elsewhere
For remote operation, Banalytics uses portal signalling to establish authenticated browser-to-Agent peer-to-peer sessions. The local environment remains the operational endpoint; browser access, media, data, file transfer, and shared access use the resulting WebRTC channels. See Portal Integration and Access Sharing and P2P Communication Settings for the documented model.
Integration should export the minimum useful result: an event type, source and zone, time, class, status, evidence reference, and routing context. MQTT or another approved interface can distribute that outcome to local dashboards, maintenance, logistics, or enterprise systems without making raw video the default integration payload.
Choose edge computer vision when the local scene and response matter
- The deployment has a specific visual question, accountable response owner, and a permitted way to review evidence.
- Moving every frame upstream would add cost, delay, privacy exposure, or an avoidable dependency on external connectivity.
- The system can distinguish camera, worker, host, and transport failures from genuine negative observations.
- The team can validate the method across real operating conditions and maintain versioned thresholds, zones, and models.
- Initial automation remains bounded: notification, triage, inspection, or a controlled hand-off rather than an unreviewed high-consequence decision.
The value of computer vision at the edge is not that it makes every camera intelligent. It is that it turns selected scenes into timely, controlled, and reviewable operational evidence while preserving local ownership of the source system.