Data acquisition and analysis software

data loggerdashboardremote condition monitoring

Industrial Sensing Monitoring
Product overview
Banalytics acquires raw data from cameras, DAQ hardware, and process instruments, hands it to your own processing or analysis module over a locked interface, and turns the structured results back into monitoring dashboards, alarms, and historian records. Your algorithm never leaves the module boundary; only structured outputs, health status, and timestamps cross it.
Banalytics provides operational visibility across your sensing pipeline - from device connectivity and data freshness to processing readiness, result delivery and edge-node health.

Problem this solves
Research and DAQ teams need to know their sensing pipeline is healthy: devices connected, data flowing, processing module alive, without building device connectivity and health monitoring themselves, and without exposing their proprietary algorithm to a third-party platform.

How it works
Field devices (cameras, DAQ hardware, sensors) → Banalytics acquisition (buffering, timestamp sync, local storage) → your processing module (over ZeroMQ IPC/TCP, shared memory, or in-process) → Banalytics orchestration (events, dashboards, historian, MQTT) → external consumers (SCADA, maintenance systems, downstream services).

Architecture example
Site A (Test Bench): 4 acoustic-emission sensors + DAQ hardware, ZeroMQ IPC to an in-process analysis module.
Site B (Production Line): 6 vibration sensors, Modbus RTU, Python analysis module over ZeroMQ TCP.
Site C (Remote Pump Station): 2 ONVIF cameras + pressure transducers, cloud-hosted module over TCP.
All sites → Banalytics Dashboard · Event History · MQTT to SCADA.

Who this is for
Research, DAQ, and measurement teams;
instrumentation engineers;
plant reliability teams who need operational visibility into a sensing pipeline without exposing their processing algorithm.

Key features
Acquisition buffering and timestamp synchronization across devices.
Transport-tiered architecture (ZeroMQ IPC/TCP, shared memory, in-process) matched to throughput and latency needs.
Event Manager and Actions for alarms and rule-based responses.
Cesium/Mapbox/OpenStreetMap/SVG/3D dashboards for monitoring views.
Event History as a queryable, timestamped historian.
MQTT publish for downstream integration.
Locked module-interface contract that keeps your processing algorithm private. Vendor-independent acquisition across ONVIF, RTSP, Modbus, and USB devices.

Technical specifications
Supported protocols: ONVIF, RTSP, Modbus (RTU/TCP), MQTT (v3/v5), ZeroMQ (IPC/TCP), USB, OPC UA, I2C
Deployment: runs alongside your existing processing or analysis module via a locked interface contract; no mandatory cloud migration; acquisition and storage remain local.
Module interface: input/output categories, timestamps, and health tags are defined per engagement; your algorithm never leaves your own module.
Alerts: dashboard alarms and notifications driven by device, health, and processing status. Historian: Event History provides a queryable, timestamped record of acquisition and processing events.
Scalability: transport tier (in-process, shared memory, ZeroMQ IPC, ZeroMQ TCP) is selected to match throughput and latency needs, from a single test bench to a multi-site deployment.

Way of work
Phase 0: Technical demo (free). Architecture walkthrough using your own use case, no data required.
Phase 1: PoC (always free). Validate the module-interface contract, health tags, and dashboards/alarms/event history using mock or replayed data; no real hardware, no device-specific engineering.
Phase 2: Funded Pilot. Connect real devices at one site and validate acquisition, processing, and monitoring on live data. Commercial once a scoped rollout-assistance engagement is purchased, or a custom device/3rd-party software integration is required.
Phase 3: Production. Harden and scale to additional lines or sites; ongoing support agreed separately.