Inspiration
Predictive-maintenance prototypes often demonstrate a classifier but hide the cost of deploying it at the edge. I wanted the optimization itself to be the project: one transparent model, two directly comparable inference paths, and evidence that another developer can reproduce on an Arm64 machine without a cloud account, API key, or proprietary dataset.
What it does
VibraGuard consumes a 64-sample window from six simulated accelerometer and gyroscope axes. A small neural network distinguishes normal operation, rotor imbalance, bearing impact, and shaft misalignment, then returns a local control recommendation such as continue operation, reduce speed, or stop for inspection.
The repository includes a portable float32 reference and an INT8 Arm deployment path. On the measured Apple M1 Max, the deployment path achieved:
- 31.215 us -> 0.805 us median latency (38.77x faster)
- 199,188 -> 50,724 logical model bytes (74.5% smaller)
- 100% float32/INT8 prediction agreement on 2,000 deterministic native validation windows
These are host-specific measurements on deliberately separable synthetic fault motifs. They demonstrate implementation and quantization fidelity, not industrial diagnostic accuracy or a universal speedup.
How I built it
I generated six-axis vibration motifs from first principles, including a normal
fundamental, low-frequency imbalance, periodic damped bearing impacts, and an
axial second harmonic for misalignment. A deterministic NumPy trainer learns a
384 -> 128 ReLU -> 4 multilayer perceptron from 6,000 windows.
The reference path executes portable float32 C dense layers, compiled with the
same optimization level as the deployment path. The optimized path
uses symmetric INT8 post-training quantization, per-output weight scales, int32
accumulators, quantized biases, and precomputed layer requantization. On Arm64
processors with the dot-product extension, each kernel iteration uses
vdotq_s32 over 16 signed INT8 pairs. A widening-multiply NEON implementation
keeps the code usable on other Arm64 systems.
The checked-in binary contains both paths for transparent A/B testing. The benchmark warms both paths, alternates their order, processes identical inputs, stores all raw timing samples, and reports the median. The model generator also enumerates the exact constants required by each deployment variant rather than using the combined test-binary size as a proxy.
Challenges I ran into
The central challenge was making the comparison both fast and honest. Input quantization is included in the optimized timing; both paths receive the same float sensor windows; a nonzero checksum keeps calls observable; the model-size calculation includes scales and quantized biases; and the report explicitly separates synthetic correctness from real-world validity.
The second challenge was preserving decisions through quantization. Per-output weight calibration and an independently measured activation scale retained the float32 decisions while removing roughly three quarters of the logical model footprint.
Accomplishments that I am proud of
- A genuine Arm-native optimization, not just an AI application that happens to run on Arm.
- A 38.77x measured latency improvement with input quantization included.
- Deterministic, download-free training and native validation pipelines.
- A reusable C template with an Arm dot-product kernel and a NEON fallback.
- One-command tests, sanitizers, benchmark capture, and machine-readable evidence.
- Explicit model-card limitations for a safety-related use case.
What I learned
Small-model optimization is a systems problem. Weight format alone does not make a useful deployment: layout, accumulator width, activation calibration, requantization, vector support, measurement order, and reproducible evidence all matter. Arm's INT8 dot-product instructions make a particularly large difference for dense sensor workloads whose dimensions align naturally to 16-byte vectors.
What's next
The next responsible step is not a bigger synthetic score. It is a documented adapter for authorized real sensor recordings, evaluation across machine types and mounting positions, out-of-distribution detection, confidence calibration, and a fail-safe interface suitable for formal hazard analysis. On the systems side, I would add Linux perf counters and energy measurements on an embedded Arm board while preserving the current portable reference as the correctness oracle.
Setup and validation
On an Arm64 macOS or Linux host with a C11 compiler and Make:
make
./build/vibraguard demo --class bearing_fault
./build/vibraguard evaluate --samples 2000
For complete verification with Python and NumPy available:
make test
make test-sanitize
make benchmark
No runtime download, account, secret, paid service, or network access is used.
Development disclosure
OpenAI Codex assisted with implementation and documentation. The entrant must personally review and validate the final repository and submission. All reported performance and quality results in this draft were produced by local commands whose raw evidence is included in the repository.
