Innatera and 42 Technology team up to push neuromorphic edge AI into industrial and IoT products
Innatera has partnered with UK-based 42 Technology (42T) to deliver brain-inspired edge AI that runs with very low energy on devices that need to watch, listen, and respond in real time. The focus: anomaly detection, condition monitoring, and predictive maintenance in industrial, IoT, and smart-device use cases.
The collaboration combines Innatera's spiking neural network (SNN) hardware (notably the Pulsar MCU) with 42T's product design and industrial system expertise. The goal is practical: end-to-end solutions that run at the edge without leaning on the cloud, improving reliability, safety, and efficiency.
Why product teams should care
If your device needs always-on sensing with millisecond response and tight energy budgets, event-driven neuromorphic chips are built for it. They compute only when events happen, which means longer battery life, lower heat, and continuous monitoring without big cores waking up.
Quick primer: neuromorphic and SNNs
Neuromorphic processors mimic brain-like signaling using spiking neural networks. Instead of fixed-rate processing, they fire on events, which maps well to vibration, acoustic, or current signatures in machines. Learn more about SNNs here: Spiking neural network.
- Ultra-low energy for always-on sensing
- Fast, event-driven response
- High efficiency for continuous monitoring at the edge
What this partnership delivers
Innatera contributes the Pulsar neuromorphic MCU for low-latency inference. 42T brings system design, sensor integration, and productization to get from demo to deployed hardware. Together, they're targeting edge AI that runs locally, even in constrained environments.
- Industrial condition monitoring: Detect bearing wear, misalignment, cavitation, or imbalance early to reduce unplanned downtime.
- IoT and smart devices: Wake-on-event audio and vibration use cases for wearables and home devices with long battery life.
- Manufacturing automation: On-sensor inference for safety and quality checks without sending data to the cloud.
Product considerations before you scope a build
- Sensor stack: Vibration (MEMS accelerometers), acoustic (PDM mics), current/voltage taps, temperature-decide by failure modes you want to catch.
- Data strategy: Event-driven sampling and smart buffering; gather labeled baseline and fault data early.
- Firmware architecture: SNN inference on the Pulsar MCU; event filtering and wake-up gating on a companion MCU if needed.
- Model pipeline: Feature options (spike encoding, spectrogram-to-spike), on-device thresholds, and update paths.
- Toolchain + SDK: Confirm training workflow, quantization, profiling tools, and CI integration.
- Latency + energy budget: Define millisecond targets and energy per inference; size battery or PSU accordingly.
- Thermals + enclosure: Lower heat helps sealed designs; still validate in worst-case ambient and duty cycles.
- Security + safety: Signed firmware, secure boot, and watchdogs; if safety-related, map to your functional safety process.
- Connectivity: Edge-first operation; cloud is optional for fleet analytics and OTA updates.
- BOM and lifecycle: MCU cost tiers, sensor counts, NRE for tuning, and multi-year supply commitments.
Suggested 90-day pilot plan
- Weeks 1-2: Lock use case and sensors. Define KPIs and test environments.
- Weeks 2-4: Collect baseline and known-fault datasets on target machines; instrument for ground truth.
- Weeks 4-6: Train SNN prototypes; run confusion matrices; benchmark energy per inference and end-to-end latency.
- Weeks 6-8: Integrate on dev boards with the Pulsar MCU; implement event gating and OTA update hooks.
- Weeks 8-10: Shadow deployment on live equipment; track false alarms and missed detections.
- Weeks 10-12: Iterate thresholds, finalize BOM, plan DFM/DFT, and prep for certification as needed.
KPIs that matter
- Energy per inference (µJ) and daily energy budget
- End-to-end latency (sensor to decision)
- Detection metrics: precision, recall, false alarm rate
- Mean time to detection, maintenance lead time gained
- Unplanned downtime reduction and maintenance cost deltas
- Wake-up rate from event gating and MCU utilization
Risks to manage
- Generalization: Models trained on one machine may drift on another-plan for per-asset calibration.
- Sensor placement: Bad mounting kills signal quality-standardize fixtures and torque specs.
- Noise and drift: Use adaptive thresholds and periodic re-baselining.
- Explainability: Provide human-readable features (bands, harmonics) alongside SNN outputs.
- Supply chain: Validate MCU lead times, second sources for sensors, and lifecycle support.
- Tooling maturity: Confirm debug, profiling, and field-update tooling before scale.
Questions to ask Innatera and 42T
- Supported sensor interfaces and reference designs (audio, vibration, current).
- Model development workflow: encoding, training tools, quantization, and on-device update flow.
- Typical memory footprints, throughput, and energy per inference for your workload.
- On-chip learning vs. offline retraining; how thresholds are adapted in the field.
- Safety and reliability: watchdogs, failure modes, and certification experience.
- Productization: NRE, design transfer, test plans, and manufacturing support.
- Pricing tiers, supply commitments, and long-term availability.
Where it fits in your roadmap
Start with high-failure or high-downtime assets and add low-energy, event-driven sensing at the edge. Use local inference for immediate response, and send summaries to the cloud for fleet analytics and maintenance planning.
If the pilot meets your energy, latency, and accuracy targets, fold the module into your standard sensor node or controller, then expand to additional lines or devices.
For a refresher on the maintenance side, see predictive maintenance. If your team needs a fast upskill path on embedded and edge AI, browse curated options here: Complete AI Training - courses by job.
Your membership also unlocks:
