Always-on condition monitoring. No cloud required.
AI condition monitoring with Logic-Based Networks tracks asset health continuously from the embedded MCU in the sensor assembly — classifying every sample, generating alerts only when they are needed, and consuming power measured in milliwatts. Assets monitored around the clock, from the hardware they already carry.
Analysis where the data is.
Condition monitoring is not new. Vibration analysts have been placing handheld probes on bearing housings and reading frequency spectra for decades. The constraint was always economic: specialist technicians, expensive instruments, and limited time meant that most assets were surveyed quarterly at best.
Wireless sensors and cloud analytics extended the reach — but the fundamental architecture remained: data flows from sensor to gateway to cloud, where analysis runs on servers. Most of the time, the data is queued and processed hours or days after collection. An LBN running on the sensor closes this gap entirely. There is no transit delay, because there is no transit. The analysis happens where the data is, at the moment the data exists.
Microsecond classify-and-act loop
From raw ADC sample to health state classification typically completes in microseconds. For a sensor sampling at 10 kHz, the MCU classifies at sample rate without falling behind. For longer-window features — one-second FFT windows, for example — inference runs once per window, with remaining MCU cycles available for other tasks.
Milliwatt continuous operation
52× less energy per inference than neural network equivalents means continuous condition monitoring is feasible on battery-powered or energy-harvesting sensor nodes — for months or years on a single cell. The same workload under a neural network architecture would exhaust most industrial battery packs in days.
Simple integration
Sensor data in, classification result out. The AI SDK integrates with existing firmware as a C library — no runtime dependency, no background thread, no cloud connection. The preprocessing layer — binarisation, feature extraction — is included in the SDK alongside the inference engine.
Rotating machinery, electrical equipment, and fluid systems.
Condition monitoring tracks the evolution of an asset's health state over time. A single anomalous reading may be noise; a sustained pattern of anomalous readings indicates a real change in condition. LBNs running continuously accumulate this evidence at sensor rate and produce health state outputs that an application layer can trend and act on.
Rotating machinery
Motors, pumps, fans, compressors, gearboxes, and turbines are the primary targets for condition monitoring. Their mechanical signatures are well-characterised, and the fault classes — bearing defects, imbalance, misalignment, looseness, gear faults — are stable across equipment types within a class.
Electrical equipment
Transformer health, switchgear contact wear, and motor winding deterioration produce thermal and acoustic signatures that correlate with remaining service life. AI classification adds automation to the interpretation layer of established condition monitoring disciplines such as partial discharge detection.
Fluid systems
Pumps, valves, and piping systems develop characteristic acoustic and pressure signatures as seals wear, cavitation develops, and blockages form. Flow-based condition monitoring augments traditional pressure and temperature monitoring with pattern-based classification of the acoustic and vibration evidence.
As the asset ages, the baseline shifts.
Condition monitoring models are trained on the normal operating signature of the equipment. As an asset ages, its normal signature drifts — the wear that is not yet a fault but represents accumulated service. Models classifying against a fixed baseline may produce false positives as the asset's nominal state evolves. Two approaches address this.
Collect data from the in-service asset and retrain the model in ModelMill at defined intervals. The new model reflects the current nominal signature. Practical for assets with long service intervals and well-defined operating regimes. The retraining workflow is identical to the initial training workflow.
Tune the decision boundary in the model to accommodate expected drift within the normal class whilst remaining sensitive to fault-class signatures. ModelMill provides tools for this during the benchmarking phase. Appropriate for assets whose nominal signature evolves predictably over a known service interval.
Sixty days. Your data. Your assets. Your model.
The Literal Labs 60-day PdM Pilot Programme takes your existing sensor data to develop a validated, ready-to-deploy predictive maintenance model — built to your assets, tuned to your failure modes, and tested against your own benchmark.
- Fixed 60-day execution timeline with defined milestones
- Time to Value typical within 6 months of deployment
- Limited spaces available
We align to your business targets and review your sample data.
We develop a predictive maintenance AI model based on your data and defined success criteria.
Performance comparisons produced against common or your own baselines.
Joint review of results and agreement on next steps — field trial or deployment.