SDX
An always-on, on-device edge-AI platform that detects and classifies physical events on and around the vehicle body — without sending audio off the car.
Read about SDX →AI Project
We build AI-based solutions.
End-to-end delivery across hardware, software and data training — from sensor selection and model development to a production-intent module, and the commercialisation of the result. Two products, and they work together.
Our expertise is in physical AI
Where the sensing stops and the deciding starts.
Digital experience has become a purchase driver, and the compute that delivers it is moving onto the vehicle itself. That raises one architectural question — cloud, edge or hybrid — and the answer decides latency, privacy, reliability and cost all at once.
Sensors
Edge AI compute
Training data
System validation
Training data
The acquisition, validation and benchmarking engine. It produces the labelled data SDX is trained and evaluated on — and it is a product in its own right.
Read about training data →Product 01 · vehicle monitoring system
SDX
Sense. Decide. eXecute. A low-power embedded system that senses impacts, contact, people leaning or sitting on the car, scratches and break-ins — classifies them in real time on the device, and reports them through a companion app.
Why it exists
The damage nobody sees happen is the damage nobody can prove.
Vehicles are exposed, and detection has been stuck between three bad options.
Cloud-dependent
Streaming audio and video off the car burns power, raises privacy questions, and stops working the moment connectivity does.
Power-hungry
Continuous AI inference drains the battery, which is incompatible with monitoring a car that is parked — the situation that matters most.
False alarms
Naïve sensors fire on passing music, slamming doors and road vibration. Alerts that cry wolf stop being read.
The shift that makes SDX possible: a new class of low-power MCUs runs real neural networks on-device, so detection that once needed the cloud now fits in a battery-powered module.
Signal and noise
It catches what matters, and ignores the rest.
The second column is the harder engineering problem. A detector that catches everything is easy; one that stays quiet through ordinary life is not.
Detected
- Kick, punch or impactA high-energy strike on a body panel.
- A person sitting or leaning on the carSustained presence and weight on the body.
- Sustained contact near the bumperProlonged manual contact with the surface.
- ScratchingHigh-frequency rubbing along the paint.
- Breaking glassThe acoustic signature of a window going in.
Suppressed
- Loud music nearbyAnother vehicle's radio.
- Ground vibrationPeople walking or jumping close to the car.
- Adjacent car doorsOpening and closing beside you.
- Construction noiseAmbient site noise around the vehicle.
- Background noiseOrdinary sound, all day, every day.
The platform
Sense. Decide. eXecute.
One integrated stack — hardware, software, training data and testing services — tuned against two budgets that pull against each other: power, and false positives.
Sense
A calibrated multi-sensor front end
Acoustic, structural and inertial inputs, captured on a common timebase.
Decide
A two-level AI, on the device
Those inputs are unified into a single real-time decision core. Nothing leaves the car.
eXecute
The event, with confidence
The classified event is delivered to the vehicle or to the companion app.
System architecture
Four sensor types, one decision.
Each sees a different part of the same event. Fusing them is what separates a real detection from a car alarm.
- Microphone
- Air-coupled acoustic signature — impacts, glass break, voices, ambient noise.
- Vibration / contact mic
- Structure-borne energy travelling through the body panel itself.
- IMU / accelerometer
- Body movement, load and weight change — leaning, sitting, towing.
- Radar (optional)
- Approach and presence around the vehicle, for extended perimeter cover.
Sensor choice and placement are decided on measurement rather than assumption — which is what the training data platform below exists to provide.
How it works
Four stages, all of them on the device.
Sense
Microphones and an accelerometer capture the raw signal from the body of the car.
Extract
A small set of discriminative features is computed continuously from that signal.
Sniff
A low-power gate flags anomalies and rejects the obvious, without waking anything expensive.
Classify
Two specialised models name the event and return a confidence, locally, with no round trip.
The gate is the whole trick
An ultra low-power stage watches the sensors continuously and decides the exact moment to wake the full AI pipeline. The expensive part sleeps until there is a reason not to — which is what makes always-on monitoring possible on a battery.
Private by construction, not by policy
All processing happens on the microcontroller. No audio leaves the vehicle, and nothing depends on a connection being available. Models can be improved over the air without changing any hardware.
Performance
The targets the platform is built against.
Stated as targets, because that is what they are. A number without its conditions is not a number.
>90%
Detection rate, across event classes
>90%
Disturber suppression
<1 mA
Always-on sensing budget
Classification lands within 500 ms of an event beginning. The always-on budget is the hard constraint in the whole design: every duty cycle, every feature and every wake costs current, so freezing the hardware before the algorithm budget has been measured is the most expensive mistake a programme can make.
Where it scales
One multi-sensor core, four markets.
OEM automotive
Design-win driven, with functional-safety expectations and factory integration. The deepest and highest-value path, and our primary target.
Aftermarket
Retrofit-friendly and fast to market. Lower integration depth, price-sensitive channels, the quickest route to a fielded product.
Insurance & fleet
Verified event data for claims validation and risk pricing — as much a data service as a sensor.
Industrial & surveillance
The same core in adjacent applications, with different environmental and certification constraints.
The platform is silicon-agnostic: the same methodology is reused across several NPU-class MCU families rather than being tied to one vendor.
Product 02 · acquisition, validation & benchmarking
Training data
Performance is bought with data, so we built the machine that produces it — and we sell what it produces. An automated 360° test cage runs reproducible interactions across a whole vehicle and auto-labels every session into training-ready data. Campaigns run on your vehicle, your sensors, your event list.
Inside SDX
- It is how SDX is trainedEvery model in the pipeline learns from data this platform produced.
- It is how SDX is evaluatedDetection and suppression figures are only credible because the data behind them is controlled.
On its own
- As an acquisition serviceCampaigns on your vehicle, your sensors, your event list.
- As a benchmarking serviceCompare sensors, positions, processors and models on identical captured data.
What we produce
Three kinds, and they are not interchangeable.
Coverage per euro rises from left to right. Fidelity to the real world falls in the same direction. Knowing which to use where is most of the craft.
Real
Real event, real vehicle, real sensors, full chain. Ground truth for the domain — and the only data that can validate anything.
Expensive, slow, hard to label precisely, and poor at covering rare cases.
Semi-synthetic
Real signatures mixed into real backgrounds, with signal-to-noise, gain and position augmented. Best coverage per euro, and it keeps real sensor character.
Risks mixing artefacts and physically implausible combinations if left unconstrained.
Synthetic
Fully generated signals. Unlimited volume, perfect labels, and it covers events you cannot safely stage.
Carries a domain gap — a model can learn the generator's fingerprint instead of the world's.
The working rule: real data for validation and test, semi-synthetic as the bulk of training, synthetic to fill coverage holes. Synthetic never enters the test set.
The test cage
Reproducible, and configurable by what actually varies.
An app-driven actuator runs the same event, in the same place, at the same intensity, as many times as it takes. That is what separates a dataset from a collection of recordings.
- Vehicle side / zone
- Where on the body the interaction happens.
- Material
- Metal, wood or plastic — the contact surface changes the signature.
- Interaction duration
- Impulsive against sustained, which is what separates an impact from a lean.
- Intensity & custom parameters
- Tuned per campaign to fill the gaps a coverage matrix exposes.
What you receive
The deliverable, itemised.
Labelled sessions
Microphone, vibration and accelerometer traces on a common timebase, labelled as they land.
Coverage matrix
Which zones, materials, durations and intensities were captured, and where the gaps are.
Benchmark results
Sensors, positions, processors and models compared on identical data, with confusion matrices.
Day-in-the-life set
Long real-world capture for validation and test. Synthetic never enters it.
Field-to-model toolchain
From a captured trace to a tuned model.
Acquisition
Session-based capture
Microphone, vibration and accelerometer traces recorded together and labelled as they land.
Testing & tuning
Validate against measurement
Sensor position, thresholds and models checked with a confusion matrix rather than a hunch.
Day in the life
What the world actually throws
Long real-world capture surfaces field misclassifications and feeds them back into training.
A fourth strand runs alongside all three: profiling current draw, so the trade-off between duty cycle and detection is made on measured power rather than estimates.
Engagement model
How a programme runs.
Fast prototyping of a customised module into your application — hardware, software, training data and testing, optimised for power consumption and false positives.
01
Scope
Use cases, KPIs and the event list agreed with you; silicon and sensor shortlist defined.
02
Acquire
Cage and day-in-the-life campaigns on the target vehicle produce a labelled, platform-specific dataset.
03
Model & tune
The cascade is trained and quantised on the target MCU, with thresholds tuned against measured power.
04
Integrate
Evaluation kit to production-intent module: enclosure, in-vehicle calibration, power benchmarking.
05
Industrialise
Handover for certification, bill-of-materials management and the production ramp.
Want to see the data?
We can walk through the cage, a sample dataset and the coverage matrix behind it.