Banalytics can sit on both sides of an industrial sensing pipeline: acquiring raw data from field devices, handing it to your processing module, then orchestrating results into events, dashboards, historians, MQTT, APIs, and operator workflows.
// Industrial architecture
Banalytics on both sides, your module in the middle
The key pattern is simple: Banalytics owns device connectivity, buffering, lifecycle, dashboards, and event routing. Your module owns the sensing logic. Raw measurement data stays local, and only structured outputs leave the processing boundary.
Banalytics acquires raw signals, delivers them to the processing module, receives structured results, and publishes events to downstream systems.
01
DEV
Field devices
Connect cameras, DAQ hardware, acoustic sensors, and process instruments
Banalytics can receive high-speed images, trigger signals, waveforms, temperature, pressure, acoustic emission, and other raw measurements from local industrial equipment.
↓ vendor SDKs, triggers, and raw signals
02
ACQ
Banalytics acquisition
Buffer, synchronize, store, and deliver raw data locally
The acquisition layer keeps device integration and raw data movement out of your algorithm code. It manages connectivity, buffering, timing, local storage, and transport contracts.
↓ raw data down, results back up
03
ALG
Processing module
Run your signal processing, fusion, and event logic
Your module can be a separate process or an in-process component. It focuses on waveform analysis, image analysis, feature extraction, fusion, confidence scoring, and result generation.
↓ events, health tags, confidence scores
04
ORC
Banalytics orchestration
Route results into dashboards, rules, historians, and remote access
Banalytics receives structured outputs from your module and turns them into events, rules, alarms, dashboards, history, MQTT publications, API payloads, and operator workflows.
↓ structured outputs and event metadata
05
OUT
External consumers
Publish only what downstream systems need
SCADA, cloud historians, operator dashboards, AI pipelines, and maintenance systems consume structured events instead of raw measurement streams.
// Data transport
Moving data between layers without losing throughput
Different sensing projects need different data movement strategies. Banalytics can use simple local IPC for co-located modules, network transport for split systems, shared memory for high-throughput data, or an in-process component when IPC becomes the bottleneck.
Transport tiers let the same architecture scale from a local prototype to high-throughput industrial operation.
T1 ZeroMQ IPC
Best for co-located modules with moderate payloads. Simple, fast, and easy to monitor.
T2 ZeroMQ TCP
Useful when acquisition and processing run on separate machines in the same plant network.
T3 Shared memory
For large frames, waveforms, and high-rate data where zero-copy transfer matters.
T4 In-process
For cases where network and IPC limits are exceeded and the module must run inside the same address space.
// Delivery model
Three phases from PoC to deployment
Industrial sensing work is easiest to manage when the interface is locked before the hardware pilot begins. Banalytics lets you validate the contract with replayed or mocked data, then reuse the same monitoring model during the funded pilot and production deployment.
The same system model carries forward from interface definition to pilot and production.
01
IF
Phase 1
Define the module contract before real hardware is required
Agree on architecture, payload schemas, health tags, failure modes, timing assumptions, and replay data. The processing team can start against mocked inputs while the acquisition path is being prepared.
↓ interface locked
02
PIL
Phase 2
Run a funded pilot on real devices
Connect the actual cameras, sensors, digitizers, and triggers. Validate throughput, buffering, result timing, event quality, monitoring views, and failure recovery using production-style dashboards.
The separation of responsibilities keeps the system maintainable. Banalytics owns operational concerns around devices, transport, lifecycle, observability, and publishing. Your module owns domain-specific sensing intelligence.
The module boundary is explicit: raw data enters the module, structured results and health tags return to Banalytics.
CASE
Acoustic emission anomaly detection on a production line
High-rate sensor input, local processing, structured plant events
DevicesDAQ hardware and acoustic sensors stream raw waveforms into the Banalytics acquisition layer.
AcquisitionBanalytics timestamps, buffers, and stores raw data locally, then delivers frames to the processing module using the selected transport tier.
ModuleYour algorithm extracts features, detects anomaly candidates, computes confidence, and returns result metadata and health tags.
OrchestrationBanalytics turns results into events, dashboard state, historian records, MQTT messages, and alert rules.
ConsumersOperators, SCADA, maintenance systems, and AI pipelines receive structured outputs instead of raw high-volume waveforms.
// In short
The industrial sensing pattern in one paragraph
Banalytics connects to field devices, keeps raw data local, moves that data to your processing module through an agreed transport contract, receives structured results and health tags, and turns them into events, dashboards, rules, historian records, MQTT messages, and API outputs. Your module stays focused on the sensing problem while Banalytics handles the operational system around it.
Where to start:
Begin by defining the module interface: input payloads, result payloads, health tags, timing requirements, restart behavior, and the transport tier. Once that contract is stable, the acquisition and processing tracks can move in parallel.
