Reproducible Edge Operations with Banalytics UseCases
Package a proven configuration, commissioning or service procedure as a selectable, parameterised scenario for an Agent.
Infrastructure configuration and service work are usually reproduced by memory, screenshots, spreadsheets and a patient engineer. That approach works once. It becomes fragile when the same camera, meter, machine cell, field cabinet or mobile unit must be prepared, checked or supported repeatedly. Banalytics UseCases provide a software interface for packaging a proven local procedure with its own inputs, validation and execution logic. Creating entities from a template is one useful outcome; depending on the installed module, a scenario can also coordinate scripts, native tools or another bounded operation.
A working procedure is not yet a repeatable operating pattern
Physical infrastructure is rarely uniform. Two sites may use the same camera model but have different retention folders, operating hours, network addresses and access rules. Two production cells may expose the same Modbus registers but use different unit identifiers, alarm thresholds and escalation paths. A competent engineer can accommodate these differences, but an undocumented sequence of clicks is difficult to review, test, transfer to another team or repeat six months later.
Reproducibility does not mean forcing every site into an identical configuration. It means separating the stable procedure of a proven pattern from the parameters that legitimately vary by site. Depending on what a module implements, the procedure may provision device acquisition and local storage, validate a dependency, coordinate rules and actions, or prepare a controlled service step. Its parameters may include a device address, a selected camera, a data directory, a schedule, a threshold, a recipient or an asset label.
This is particularly useful for a small team responsible for many sites: it moves knowledge from an individual’s working memory into a reviewable deployment artefact.
Package the procedure, not just the final configuration file
In Banalytics, a UseCase<CONFIG> defines a reproducible executable scenario for an Agent. Its implementation receives a typed configuration object and supplies a create() operation. The scenario can declare a group so the Portal can present related patterns together. At Agent startup, Banalytics discovers available UseCase implementations supplied by installed modules; the Portal requests the available scenarios and a form descriptor for the chosen configuration type, then sends the selected values back to the Agent for execution.
The scenario author owns the execution logic. Depending on the module, it may create or reuse components, create tasks beneath the correct parent, attach rules and actions, set configuration values, validate prerequisites, start an intended local workflow, or invoke a script or native tool that the module explicitly controls. The Command Action is one documented component that a scenario can configure or coordinate when an approved local command is part of the procedure. The existing USB monitoring scenario is a practical example of configuration assembly: depending on its parameters, it can select or create a local camera, create an acquisition task, attach motion detection and recording tasks, create local storage, and add scheduled event-driven actions.
| Layer | Responsibility | Example |
|---|---|---|
| Scenario package | Defines the stable procedure and the code that executes it. | “Camera monitoring with motion evidence and day/night operating modes.” |
| Configuration contract | Exposes the inputs that may vary and their dependencies, type, range and required state. | Selected camera, format, resolution, storage folders and operating times. |
| Agent execution | Runs the scenario close to the equipment and, where applicable, persists the resulting components and tasks locally. | Create or reuse a camera, storage destination, event manager and actions. |
| Operational result | Provides a known local state or a completed bounded procedure that can be inspected, monitored, adjusted and supported. | A visible acquisition, recording and event chain rather than an opaque installer. |
Deliver a shared procedure centrally or as an individual package
A UseCase lives in a Banalytics module. This makes the scenario portable with the software that understands the relevant devices, processing logic or domain rules. A platform team may include a broadly applicable scenario in a centrally managed module. A systems integrator, research group or equipment owner may instead distribute a purpose-built module for one programme, one asset class or one customer’s on-premise estate. The same model can support a locally delivered recovery package: after replacement hardware receives an Agent installation, an authorised administrator can provide an approved removable medium containing the organisation’s custom module and protected recovery material, then run the documented scenario locally.
This distinction matters. A generic monitoring scenario can be maintained as a common capability, while an organisation can keep its proprietary thresholds, custom processing module, naming convention or integration logic in its own package. An enterprise can develop a UseCase entirely for its own environment and distribute it only through its own controlled process. Banalytics does not need to receive the source code, participate in distribution, approve the logic or operate the procedure. In an isolated on-premise deployment, the Banalytics service need not know that the enterprise-specific module exists at all.
The Agent executes installed code locally; the equipment owner chooses which modules are installed and which scenario is applied. Where an Agent is connected to a Portal, organisations should still treat any software inventory or operational metadata exposed by that deployment as a separate architecture and governance decision, rather than as a reason to disclose proprietary code or configuration.
Use the Software Upgrade Center to manage the operational lifecycle of deployed software, and keep a clear record of the module version, supported Agent versions, parameter contract and rollback procedure for every approved scenario.
Make the scenario explicit about what it creates, checks, changes and never touches
A UseCase is application code, not a magic configuration import. Its quality determines whether a procedure is genuinely repeatable. The author should define the preconditions, input validation, component ownership, expected side effects and recovery behaviour before a deployment team uses it at scale.
- Define the operational outcome. State the outcome in operational terms: for example, “retain motion evidence outside opening hours and notify the local operator”, rather than “create five tasks.”
- Write the parameter contract. Classify every input as a site-specific value, a selected existing resource, a safe default or a secret that must be supplied through an approved local process. Use typed fields, ranges, dependencies and visible conditions so the form exposes only meaningful choices.
- Discover or create deliberately. Decide whether an existing camera, broker, storage location or event manager should be reused. A scenario should use stable identifiers or explicit matching rules; it must not silently attach to an arbitrary similar component.
- Design for repeat execution. Check whether the required component, task, rule or action already exists before creating another one. Define what a second invocation does: update named resources, leave them unchanged, reject the request, or create an explicitly separate instance. Idempotence is a design responsibility of the scenario author.
- Validate before activating. Confirm device reachability, permissions, storage capacity, protocol semantics and rule logic before starting control-affecting work. Begin sensitive automations in observation or notification mode.
- Treat local media as a trust boundary. A recovery scenario should invoke only a specifically approved module and explicitly selected script or tool. It should not automatically execute arbitrary content from a mounted drive. Define the administrator’s authorisation, package-integrity check, secret-handling method and audit record before using removable media in a protected environment.
- Expose evidence and health. The resulting configuration should be visible through normal Banalytics components and operational monitoring, not hidden inside an installer. Use Event Manager for explainable rules and System Monitor for Agent-node health.
Directions for custom UseCase modules
The following are design directions for teams building their own UseCase modules. They illustrate how repeatable configuration and service work could be automated; they are not a catalogue of prebuilt Banalytics workflows. Each organisation should implement, test, approve and operate the scenario that matches its equipment, safety boundaries and change-control process.
| Potential scenario | What a custom UseCase could standardise | What remains local or site-specific |
|---|---|---|
| Distributed video monitoring | Camera acquisition, motion detection, local evidence storage, scheduled modes, event creation and approved notifications. | Camera selection, retention location, schedules, privacy zones, named recipients and authorisation. |
| Machine or utility monitoring | Protocol connector, register or topic contract, normalisation, freshness checks, threshold rules, event history and escalation workflow. | Device address, unit ID, physical asset mapping, engineering thresholds and any permitted write authority. |
| Building plant-room baseline | Meter and controller onboarding, local trend collection, fault events, dashboard components and maintenance notifications. | BMS boundaries, building-specific schedules, credentials, safety interlocks and responsible maintenance team. |
| Mobile or remote asset kit | Agent services, position reporting, communications health, storage policy, local alarms and a standard operations view. | Vehicle or site identity, connectivity method, geofences, local regulations and operator permissions. |
| Research model pilot | Input acquisition, a local adapter around a Python or native model, result schema, evidence retention, health reporting and delivery of selected outcomes. | Model artefact, calibration data, acceptance criteria, dataset rights and the decision to promote results beyond shadow mode. |
| Community or small-city observation point | Sensor or camera onboarding, local storage, quality checks, non-emergency event rules and a controlled data-sharing path. | Purpose, lawful basis, data-sharing agreement, retention policy, access roles and the authority responsible for response. |
| Agent maintenance procedure | Health pre-checks, collection of diagnostic evidence, verification of configured storage policy, or controlled restart of explicitly approved components. | Maintenance window, permissions, retention policy, approved actions, escalation path and any decision to update or remove software. |
| Recovery or commissioning procedure | Validation of expected dependencies, start-up of an approved workflow, data-path verification and a structured completion event. | Acceptance criteria, site safety procedure, device credentials, rollback authority and the responsible engineer’s sign-off. |
| Replacement-hardware recovery kit | After an Agent is installed on replacement hardware, an approved custom module could run an explicitly selected local script or tool to install the organisation’s supported modules and recreate an approved initial configuration. | Administrator authorisation, trusted removable medium, key handling, package-integrity verification, hardware-specific values, protected-network access and the recovery audit trail. |
For field-device patterns, the scenario can build on documented interfaces such as Modbus Line and the embedded MQTT Server. The UseCase should encode the operational pattern around those interfaces; the protocol itself remains an explicit, testable contract.
Reproducible does not mean uncontrolled mass rollout
Every scenario should have an owner, an approved purpose, a stated compatibility range and a test environment. Before applying a scenario to a production site, test it against a representative Agent version and device interface, confirm how it behaves when a dependency is absent, and document how to disable or remove the resources it creates. A scenario should not bypass safety controllers, equipment vendor procedures or local change-control requirements.
For scenarios that integrate with another organisation, explicitly define the data schema, recipient, authentication, retention and revocation process. A local Portal Integration connection can provide authorised browser-to-Agent access for configuration and observation; it does not make the Portal the owner of the equipment configuration or its raw operational data.
Keep credentials and other secrets outside a reusable package whenever possible. A portable scenario should reference a local secret, existing protected component or secure commissioning step rather than embed the same password, token or private endpoint into every copy. When recovery material is provided on a removable medium, keep its handling entirely within the owner’s controlled environment; do not treat Portal metadata or a browser connection as a repository for those keys.
Begin with one procedure worth repeating
- Choose a deployment that has already been proven manually at least once and has a clear operational owner.
- Map its components, tasks, rules, actions, external interfaces and site-specific values.
- Define a small parameter contract and implement the UseCase in the module that owns the relevant capability.
- Test first-run, second-run, partial-failure, disconnected-device and removal behaviour on a non-production Agent.
- Apply it to a second comparable site, record deviations, and decide whether they belong in the common contract or a separate scenario.
- Publish the supported version, operating instructions and change record with the package.
The aim is not to remove engineering judgement. It is to reserve that judgement for the exceptional conditions that deserve it, while making the common infrastructure procedure visible, repeatable and supportable.