On-device AI for Wearables: Federated, Privacy-Preserving Anomaly Detection

Edge-first anomaly detection on wearables is no longer a research demo — it is a production requirement. Users demand privacy, battery life is finite, and continuous connectivity is unreliable. This article gives engineers a practical blueprint for building anomaly detection that trains with federated learning, preserves privacy, and runs entirely on constrained smart devices.

We’ll cover architecture, model choices, the federated training loop, on-device inference optimizations, an implementation sketch, and a deployment checklist you can use today.

Why on-device anomaly detection for wearables?

• Privacy: raw sensor streams (ECG, accelerometer, gyro) are personally identifying. Keeping raw data on the device reduces exposure.
• Latency and reliability: anomalies often require immediate feedback — detect falls, arrhythmias, or device tampering offline.
• Bandwidth and cost: sending continuous streams is expensive and power-hungry.
• Personalization: models tuned to each user’s physiology and behavior catch subtle anomalies faster.

Federated learning (FL) helps you get the statistical benefits of centralized training while keeping raw data local.

Federated learning primer (practical view)

Federated learning coordinates model updates across many devices. A typical round:

1. Server sends global model weights to a cohort of clients.
2. Clients train locally on-device for a short epoch budget or batches.
3. Each client sends model updates (gradients or weight deltas) back.
4. Server aggregates updates and forms a new global model.

Privacy boosters you should add:

• Secure aggregation so the server cannot inspect individual updates.
• Differential privacy (DP) at the client: clip and add noise to updates before leaving the device.
• Sparse updates and compression to reduce upload size and exposure.

Trade-offs: privacy-preserving aggregation increases compute and communication, and DP introduces accuracy loss. The trick is co-design: choose compact models that tolerate DP noise and require fewer rounds.

Choosing models for wearable anomaly detection

Constraints: memory (tens of KBs to a few MB), CPU (single-core microcontroller to mobile SoC), latency, and battery.

Model families that work well:

• Classical statistical models: ARIMA, thresholding, z-score. Very cheap, interpretable. Use as a baseline.
• Lightweight neural nets: 1D CNNs and small LSTMs (one or two layers) for time-series. Use depthwise separable convolutions.
• Autoencoders for reconstruction-based anomaly detection: compact encoder-decoder where anomalies have high reconstruction error.
• One-class classifiers: lightweight SVM variants or shallow dense networks trained on normal data only.

Practical guidance:

• Favor models under 1–2 MB when possible. For microcontrollers, target <256 KB.
• Quantize to 8-bit integers; consider 4-bit quantization if your framework supports it.
• Prefer models with few matrix multiplications and small activation memory.

Data pipeline and privacy considerations on-device

Sensor preprocessing should be deterministic and minimal on-device: resampling, normalization, and windowing. Keep raw traces short and volatile; only keep summaries or transient windows used for feature extraction.

Feature extraction options (compute-light):

• Time-domain: mean, std, skewness, kurtosis, peak-to-peak.
• Frequency-domain: energy in low/high bands via cheap DFT approximations.
• Event features: step counts, RR intervals, zero-crossing counts.

Store only ephemeral buffers for training. When sending model updates, apply DP: clip per-example updates to a norm bound and add calibrated Gaussian noise. Use per-device budgets and audit privacy loss centrally.

System architecture: devices, aggregator, and backend

• Device: collects data, locally trains, computes model updates, performs inference and alerts.
• Aggregator server: orchestrates rounds, schedules cohorts, aggregates updates with secure aggregation.
• Model management backend: stores global models, metrics, and A/B test configurations.

Key engineering points:

• Device scheduler must avoid training while charging is low or CPU is busy.
• Use a rolling cohort selection: pick available devices with recent activity and battery & network constraints.
• Provide a fallback: a tiny rule-based detector if the model or on-device runtime fails.

Federated training loop (practical pseudocode)

Here’s a minimal client update loop you can implement on-device. The code shows local training for a single round (pseudocode, not framework-specific):

# Fetch global weights into local model
model.load_weights(global_weights)

# Prepare local dataset: windowed, preprocessed, and balanced
dataset = get_local_windows(max_windows=200)

# Local training loop: lightweight epochs
for epoch in range(1):
    for X_batch, y_batch in dataset:
        loss = model.train_step(X_batch, y_batch)

# Compute weight delta: delta = local_weights - global_weights
delta = model.get_weights_minus(global_weights)

# Clip update norm for DP
norm = l2_norm(delta)
if norm > clip_bound:
    delta = delta * (clip_bound / norm)

# Add calibrated noise (if using DP)
delta = delta + gaussian_noise(sigma=noise_std, shape=delta.shape)

# Compress / sparsify delta
delta = topk_compress(delta, k=topk)

# Upload the delta to server
upload(delta, metadata)

Notes:

• Keep max_windows small to limit on-device training time.
• Use topk_compress or quantization to shrink uploads; combine with secure aggregation.

On-device inference: optimizations that matter

• Use post-training quantization and integer-only ops to reduce memory and energy.
• Fuse operations (conv + batchnorm) at build time.
• Use streaming inference for time-series: update a rolling buffer rather than recomputing from scratch.
• Avoid dynamic memory allocation in the inference loop; pre-allocate activation buffers.

Example inference pattern (conceptual):

- Maintain a circular buffer of N samples.
- On new sample: push into buffer, compute features or run a single forward pass.
- If anomaly score > threshold, trigger local alert and optionally log a short trace.

Tune thresholds per-user during personalization rounds; global thresholds rarely fit everyone.

Evaluation and monitoring

Metrics to track:

• True positive rate and false positive rate (per user and aggregated).
• Time-to-detect latency and energy per inference.
• Communication overhead per round and per device.
• Model drift indicators: rising reconstruction error baseline, or increasing local loss.

On-device telemetry should be privacy-preserving: send aggregated, noisy metrics rather than raw traces.

Implementation tips and tooling

• Frameworks: TensorFlow Lite for Microcontrollers, PyTorch Mobile, ONNX Runtime for Mobile, TinyML toolchain for MCUs.
• For federated orchestration: open-source platforms like Flower, TensorFlow Federated (server-side), or a custom server with secure aggregation.
• Use hardware acceleration where available: DSP, NPU, or optimized BLAS libs.

Operational tips:

• Start with a simple rule-based detector in production while collecting labeled data for model warm-up.
• Canary new global models to a small subset of devices before full rollout.
• Implement versioning: the device should keep the last known-good model and roll back on runtime errors.

Compact example: tiny autoencoder architecture

A practical autoencoder for 1D windows (N timesteps × C channels): a 3-layer encoder and symmetric decoder with small channel counts. Keep the bottleneck small (8–32 dims). Train reconstruction MSE on-device; anomalies produce high error.

Advantages: unsupervised training (useful when anomalous labels are rare) and natural per-user personalization.

Summary checklist for engineers

• Design: pick an architecture sized for target device memory and CPU.
• Privacy: add secure aggregation and client-side DP (clip + noise).
• Training: limit local epochs and window counts; use sparsity and quantization for updates.
• Inference: quantize, fuse ops, use streaming inference, pre-allocate buffers.
• Orchestration: schedule training with battery/network checks; use cohorted rounds and canaries.
• Monitoring: collect aggregate telemetry with privacy-preserving noise; track drift signals.

Final notes

On-device, federated anomaly detection for wearables is achievable with careful co-design of model, privacy, and system infrastructure. Start small — a lightweight model and conservative DP settings — then iterate with controlled canaries and metrics. The payoff is significant: better privacy, instant detection, and personalized accuracy without shipping sensitive raw data off-device.

Checklist (copyable):

• Choose model family and size target
• Implement deterministic preprocessing and windowing
• Add client-side clipping and DP noise
• Use secure aggregation or at least compression & encryption
• Quantize and optimize inference runtime
• Canary and monitor model rollouts

Build with privacy and constraints in mind, and your wearable fleet will detect anomalies more accurately and more respectfully of user data.