Edge Runtime Software
What runs at the edge when physical systems must continue operating without a perfect network.
Edge runtime software is the local execution environment that turns a computer near equipment into a dependable part of an operational system. It keeps devices connected, runs processing tasks, preserves local state, applies rules, and exposes only the data and control paths that need to cross the site boundary.
Runtime software is more than an application installed on a device
At the edge, an application has to live with the conditions of the physical world. Cameras disconnect. A serial device returns a timeout. A local disk approaches capacity. A network link drops while the process still has to record, detect, alarm, or control equipment. Edge runtime software provides the execution and operational model needed to handle those conditions locally.
A useful runtime therefore combines five responsibilities: device communication, local task execution, persistent configuration and storage, event-driven coordination, and observability. It is not simply a remote agent that forwards telemetry to a cloud service, and it is not a generic operating-system process manager. It is the software boundary that makes an edge node understandable and controllable as a system.
The Banalytics Agent is that runtime for camera, sensor, and physical-system workloads. It runs on operator-owned Windows, Linux x86_64, or Linux ARM64 hardware, while the web console supplies remote configuration and visibility. The runtime processes streams and events locally; the browser is not a mandatory hop in the real-time path. The platform overview is available in What is Banalytics?.
Make every runtime responsibility explicit
Banalytics describes local execution through a small set of distinct concepts. Components represent connected resources such as cameras, storage, brokers, connectors, and hardware interfaces. Tasks perform work on the data produced by those components. Tasks emit events. The Event Manager evaluates rules, and matching rules trigger actions.
This model is important in practice. A recording task can be restarted without rebuilding the storage configuration. A rule can be modified without altering the camera connection. A notification action can be changed without touching the detector that produced the event. The result is a runtime that can evolve without turning routine operations into a software redevelopment project.
What a production edge runtime must own
| Concern | Why it belongs at the edge | Banalytics runtime responsibility |
|---|---|---|
| Device connectivity | Physical devices are reached through local networks, serial lines, and vendor-specific interfaces. | Connects cameras and equipment through ONVIF, RTSP, USB, Modbus, MQTT, ZeroMQ, and related local interfaces. |
| Data handling | Video, waveforms, and telemetry often cannot or should not be continuously transferred upstream. | Buffers and records locally, keeps raw data on the operator's hardware, and publishes selected structured outputs. |
| Task lifecycle | Sources and processing workloads need deliberate start, stop, restart, and failure-recovery behaviour. | Runs components and tasks with configurable restart modes; lifecycle actions can restart the affected scope without a full-node reboot. |
| Event execution | Critical decisions should not wait for an external workflow engine to be reachable. | Evaluates local Event Manager rules and triggers notifications, recording, MQTT messages, device actions, scripts, or custom code. |
| Operational state | An edge node must report whether it can continue performing its assigned work. | Publishes runtime health, stream activity, storage state, and event history for operators and automation rules. |
The module architecture keeps these services composable. A deployment can begin with the core, local storage, and a small number of sources; add ONVIF, dashboard, AI, or integration capabilities only when the workload requires them. See Banalytics Modules for the available runtime capabilities.
Separate local execution from remote administration
An edge runtime should not confuse its control interface with its execution boundary. In Banalytics, the Agent runs locally and performs processing on the host. The browser console connects to that environment for configuration, live visibility, file transfer, and remote control through authenticated portal and WebRTC channels. The connection model avoids exposing an inbound port or requiring a VPN for ordinary browser access.
From version 2.0, module UI resources are supplied by the connected agent rather than maintained as a fixed portal catalogue. This allows agents running different module versions to expose the correct interface for their own capabilities. The architectural details and compatibility boundary are documented in Banalytics 2.0.0 Architecture; operational portal connectivity is described in Portal Integration.
This split has a practical benefit: a temporary loss of remote access is an operations issue, not automatically a loss of local acquisition, recording, rules, or device control. Each location remains an independently operating node while authorised users can still view multiple connected environments together when the remote path is available.
Measure the runtime that actually carries the workload
Edge workloads have more than one memory budget. A Java heap may be healthy while codecs, frame buffers, GPU drivers, native libraries, or WebRTC buffers create pressure elsewhere. Disk capacity may be more important than CPU for a recording node; CPU saturation may be caused by decoding or inference rather than the event engine itself.
The System Monitor exposes CPU load, JVM and system memory, disk capacity, thread counters, active users, WebRTC buffers, and media-stream activity. It publishes those measurements as events, which means the same runtime can surface a dashboard metric, retain a history item, or trigger an alert when a threshold is crossed.
Memory settings should follow observed load rather than a default copied from another host. JVM Settings documents the separate Java heap and native-memory limits used by media and AI workloads. The important operational rule is simple: reserve memory for the operating system, buffers, codecs, and native libraries instead of assigning all installed RAM to the JVM.
Recover the smallest affected scope first
Runtime recovery is safest when it follows the failure boundary. If one detector is stalled, restart that task. If a connector has failed, restart the affected component. Escalate to an Agent restart only when the local runtime cannot recover at a narrower scope. Banalytics supports lifecycle actions for both tasks and components, allowing operational rules to act on the appropriate unit.
A full Agent restart is intentionally different. The Reboot Agent action stops the Banalytics process; an external service manager such as systemd, a Windows service wrapper, Docker policy, or another watchdog must bring the process back. This is a useful last-resort control, but it should not substitute for a recovery model at the task and component layers.
For systems that run a specialist sidecar or protocol bridge, the Process component can supervise a local helper service. It is suitable for an explicit integration boundary; long-running, business-critical process behaviour should still be engineered with its own health checks, timeout policy, and permissions.
When edge runtime software is the right foundation
- Work must continue locally. Recording, detection, data collection, or machine response cannot depend on a permanent cloud connection.
- Several physical interfaces meet at one node. The node must coordinate cameras, sensors, storage, messaging, and potentially a custom processing module.
- The system needs an operator model. Teams require visible health, retained events, controlled actions, and a way to update capability over time.
- Domain software should remain independent. Existing C++, Python, CUDA, or vendor logic needs a stable operational envelope rather than a forced rewrite into a proprietary platform.
- One site is only the beginning. The design must accommodate a collection of autonomous local nodes without treating every new location as a separate product.
Banalytics is designed for this class of runtime. It is not a replacement for a general-purpose fleet scheduler or a universal container platform. Its purpose is narrower and more immediate: make the software that touches physical systems locally reliable, observable, and governable.