High Level System Architecture
Live Telemetry Dashboard
ARIA's Setup
Top View of ARIA's Setup

About the Project

Track 1: Physical AI - Optimization Output.

Inspiration

Edge AI systems are often designed around a single fixed neural network. That approach is simple, but it creates an unavoidable trade-off: a small model is fast and efficient but may miss difficult events, while a larger model can be more accurate but consumes more compute, memory, and energy.

That led to the central question behind ARIA - Adaptive Runtime Inference Accelerator:

Why should an edge device run its most expensive model all the time when most sensor data does not require it?

ARIA was built around the idea of adaptive inference. Instead of deploying one neural network, ARIA keeps multiple versions of the same task available simultaneously:

Fast - lowest computational cost
Balanced - intermediate compute/accuracy trade-off
Accurate - highest-fidelity model

A lightweight learned Meta-Controller observes runtime behavior and determines which model should be used next.

The goal was not simply to switch between three models. The larger objective was to build a reusable runtime compute-management layer for Physical AI on microcontrollers.

The project was developed on the Renesas EK-RA8D1, powered by an Arm Cortex-M85, with two substantially different sensing pipelines:

ADS1263 32-bit ADC for analog signal/anomaly sensing.
ICM-20948 IMU using six-axis accelerometer and gyroscope data for motion/vibration classification.

Using two sensor domains was important because it allowed ARIA to demonstrate that the architecture is not tied to one particular input signal.

What ARIA Does

ARIA implements the following high-level pipeline:

Physical Sensor
      ↓
Signal Acquisition
      ↓
Feature Extraction
      ↓
Learned Meta-Controller
      ↓
Fast / Balanced / Accurate Model
      ↓
Classification Result
      ↓
Runtime Feedback
      └──────────────→ next decision

Instead of storing only one inference model, ARIA contains an entire model zoo.

For the ADS1263 demo:

ADS Fast
ADS Balanced
ADS Accurate

For the ICM-20948 demo:

ICM Fast
ICM Balanced
ICM Accurate

That means six independently trained and compiled neural-network variants are available inside a single firmware image.

There is no model download, filesystem load, SD-card access, or cloud request when ARIA changes model tiers. The model graphs are already compiled into the firmware and the runtime simply dispatches inference to the selected graph.

This is one of the most important architectural features of the project:

ARIA can dynamically change the amount of neural-network compute used by the application without reflashing the board or loading another model at runtime.

How We Built It

1. Cortex-M85 Runtime Platform

ARIA runs on the Renesas RA8D1 / Arm Cortex-M85 under FreeRTOS.

The firmware integrates:

Renesas FSP
FreeRTOS
Edge Impulse generated inference code
Edge Impulse EON compiled models
TensorFlow Lite Micro components
CMSIS-DSP
CMSIS-NN
Arm Helium / MVE support
ADS1263 SPI acquisition
ICM-20948 SPI acquisition
learned Meta-Controllers
DWT-based benchmarking
UART telemetry
ESP32 Wi-Fi dashboard bridge

All inference decisions happen locally on the RA8D1.

The ESP32 does not perform AI inference. It is used only as a telemetry and visualization bridge so that information such as active model, prediction confidence, latency, and sensor readings can be observed from a browser.

2. Six Models in One Flash Image

Each sensing task has three models representing different compute/accuracy operating points.

ADS1263 model zoo

Variant	Edge Impulse Test Accuracy	Compiled Model Object Flash
Fast	83.3%	3.50 KiB
Balanced	89.8%	4.93 KiB
Accurate	96.3%	15.48 KiB

ICM-20948 model zoo

Variant	Edge Impulse Test Accuracy	Compiled Model Object Flash
Fast	90.1%	3.87 KiB
Balanced	89.1%	4.03 KiB
Accurate	98.8%	5.30 KiB

These values are based on the compiled model object contribution:

text + data

reported by arm-none-eabi-size on the individual model .o files.

Together, the six model objects contribute approximately:

38,005 bytes ≈ 37.1 KiB

of compiled flash content.

The complete ARIA firmware, including the six models, FreeRTOS, DSP/runtime libraries, both Meta-Controllers, acquisition code, telemetry and application logic, measures:

text = 246,956 bytes
data =  48,604 bytes
bss  = 182,536 bytes

giving approximately:

Linked flash content ≈ text + data
                     ≈ 288.6 KiB

and:

Static RAM allocation ≈ data + bss
                      ≈ 225.7 KiB

This demonstrates that multiple independently compiled inference graphs can coexist on the MCU while remaining directly callable at runtime.

The Meta-Controller

The Meta-Controller is a small neural network trained to select the appropriate model tier.

For the ADS pipeline, its learned inputs include runtime quantities such as:

confidence average
confidence trend
signal delta
signal RMS

The controller therefore makes its decision from the state of the live inference pipeline rather than simply mapping an absolute sensor voltage to a model.

Conceptually:

runtime features
       ↓
tiny learned MLP
       ↓
Fast / Balanced / Accurate

The Meta-Controller itself is intentionally much smaller than the task models because its purpose is to decide how much inference compute should be spent, not to replace the task classifier.

Transient-Aware Escalation

During testing we discovered an important limitation of using only full inference-window statistics.

A sudden physical spike may be obvious at the ADC sample level, but after being averaged into a long inference window, its effect on RMS and confidence features can become significantly weaker.

That means a controller operating only once per complete inference window can react later than desired to a very fast physical event.

To address this, the final ADS pipeline includes a transient-aware safety/escalation path.

Importantly, this logic does not run as the normal routing mechanism for every sample.

Normal or gradually changing signals continue through the learned controller.

Only a sufficiently sudden positive or negative change activates transient escalation.

The behavior is:

normal / gradual signal
        ↓
trained Meta-Controller
        ↓
Fast / Balanced / Accurate

For a moderate sudden transition:

moderate sudden spike or dip
        ↓
Balanced immediately
        ↓
Balanced model remains latched
        ↓
real Balanced inference completes
        ↓
normal learned routing resumes

For a stronger sudden transition:

large sudden spike or dip
        ↓
Accurate immediately
        ↓
Accurate model remains latched
        ↓
real Accurate inference completes
        ↓
normal learned routing resumes

The transient detector evaluates the magnitude of the sample-to-sample change:

fabsf(current_sample - previous_sample)

so it reacts to both upward spikes and downward dips.

The thresholds are also based on recent signal behavior rather than simply assigning a model based on the absolute voltage level.

A strong transient can also preempt an existing Balanced transient request and promote the system to Accurate.

This creates a hybrid policy:

learned adaptive routing during normal operation, with fast transient escalation only when the physical input changes abruptly.

This distinction was important because forcing Accurate continuously would defeat the purpose of adaptive inference.

Arm Cortex-M85 and Helium / MVE

ARIA was designed specifically around the capabilities of the Arm Cortex-M85 rather than treating the board as a generic microcontroller.

The project is built with Arm Helium / MVE support enabled.

MVE support was verified in multiple ways:

Compiler architecture:
armv8.1-m.main+fp.dp+mve.fp

Preprocessor:
__ARM_FEATURE_MVE = 3

and through the final ELF build attributes:

Tag_MVE_arch: MVE Integer and FP

CMSIS-NN and CMSIS-DSP can therefore use Cortex-M85 vectorized implementations where supported.

This matters particularly for ARIA because the MCU is not executing one fixed model. It must support several quantized neural-network graphs and be able to move between them dynamically.

Helium helps reduce the computational cost of the kernels that dominate embedded inference, making the Fast/Balanced/Accurate approach more practical without requiring an external AI accelerator.

The system does not claim that every instruction in every graph is vectorized. Instead, the project enables and verifies MVE and allows the optimized CMSIS inference kernels to use it where applicable.

ADS1263 Demo

The first ARIA pipeline uses the ADS1263, a high-resolution 32-bit ADC connected over SPI.

The firmware performs the complete acquisition chain:

ADS1263
   ↓
DRDY polling
   ↓
SPI transfer
   ↓
signed 32-bit ADC conversion
   ↓
voltage conversion
   ↓
circular sample buffer
   ↓
model-sized inference window
   ↓
Edge Impulse inference
   ↓
Meta-Controller

The ADC uses hardware SPI with DTC-assisted transfers, while acquisition and inference execute inside a FreeRTOS task.

Different task models can require different amounts of history, so the capture system stores a larger circular buffer and extracts exactly the amount of input required by the currently selected variant.

ICM-20948 Demo

The second demo was intentionally made structurally different from the first.

Instead of one scalar ADC channel, the ICM pipeline works with six interleaved signals:

ax
ay
az
gx
gy
gz

The IMU runs at approximately 100 Hz.

The model pipeline performs spectral feature extraction using six-axis motion data and produces three output classes:

fault
idle
normal

All three ICM variants use an EON-compiled TFLite classification graph with a 78-feature input and three-class output, quantized to int8.

The deployed input sizes are:

Fast:
100 frames × 6 = 600 floats

Balanced:
100 frames × 6 = 600 floats

Accurate:
200 frames × 6 = 1200 floats

The IMU pipeline also computes motion information such as gravity-removed acceleration activity and gyroscope RMS to support runtime behavior.

Having both ADC and IMU pipelines proves that the ARIA architecture can operate across two very different physical sensing domains.

Real Runtime Latency Measurement

Inference latency shown by ARIA is not a hardcoded benchmark.

The firmware measures actual execution time using the Cortex-M85 DWT cycle counter.

Conceptually:

uint32_t start = DWT->CYCCNT;

/* real model inference */

uint32_t end = DWT->CYCCNT;

The cycle difference is converted using SystemCoreClock.

This provides actual on-device timing for whichever model was executed.

The resulting values can be observed through both:

debugger-visible variables
the live telemetry/dashboard system

This was important because an adaptive inference system should make claims about compute cost using the runtime that actually executes the models, not desktop estimates.

Live Telemetry and Dashboard

ARIA includes an ESP32 telemetry bridge connected to the RA8D1 over UART.

The dashboard can display live information such as:

sensor value
active model
classification confidence
inference latency

The network is deliberately outside the inference loop.

Therefore:

Wi-Fi disconnected
        ↓
ARIA inference still works

and:

ESP32 disconnected
        ↓
ARIA inference still works

The ESP32 is a visualization layer rather than an AI dependency.

Challenges We Faced

Building ARIA required considerably more than exporting a model from Edge Impulse and calling run_classifier().

A large part of the project became systems integration work.

Edge Impulse Runtime Integration

The generated Edge Impulse environment was designed primarily around its own expected project structure. Integrating it into a custom Renesas FSP + FreeRTOS application exposed several linker and runtime dependencies.

Missing implementations such as allocation, timing, and porting functions had to be integrated correctly before the generated inference code could execute.

Multiple Generated Models in One Firmware

One of the largest architectural challenges was linking several independently generated model variants into one binary.

Generated Edge Impulse headers contain substantial definitions and implementation code. Naively splitting the ADS and ICM inference environments into separate C++ translation units resulted in duplicate definitions and linker conflicts.

The final solution keeps the relevant generated inference implementations together in a merged dispatcher environment while exposing lightweight C-compatible interfaces to the sensor tasks.

This allowed all six models to coexist in the firmware.

ICM-20948 SPI Bring-Up

The ICM initially returned:

WHO_AM_I = 0x00

even though the SPI completion callback was firing.

That made the problem particularly misleading: software synchronization appeared correct while the sensor communication itself was not.

The issue was eventually resolved by validating:

the correct SPI instance
correct SPI mode
hardware chip-select behavior
register-bank operation
correct ICM interface configuration

A critical detail was configuring the Renesas SPI-B peripheral in true four-wire SPI mode rather than the clock-synchronous configuration.

After correcting the configuration:

WHO_AM_I = 0xEA

was read successfully.

ICM Reset Behavior

Another subtle issue was that resetting the ICM also reset its interface-control state.

The firmware therefore had to:

disable I²C interface
        ↓
reset sensor
        ↓
wake sensor
        ↓
disable I²C interface again

before completing the remaining configuration.

This is the type of hardware behavior that is easy to miss when focusing only on the machine-learning portion of an embedded AI project.

Hard Fault During IMU Inference

The direct compiled ICM graph initially hard-faulted during inference.

At first, possibilities included:

MVE/Helium incompatibility
generated-model corruption
tensor allocation problems
incorrect DSP features

The actual cause was much simpler but harder to identify:

FreeRTOS task stack exhaustion.

Increasing the IMU task stack solved the inference failure while preserving the accelerated Cortex-M85 build.

This was one of the most useful lessons from the project: failures inside ML inference are not necessarily ML failures. In an embedded system they may come from the RTOS, memory layout, peripheral interaction, alignment, or stack configuration.

Combining Different DSP Pipelines

The ADS and ICM models were not interchangeable from a preprocessing perspective.

The ICM model required six-axis spectral processing producing 78 features. Reusing incompatible generated metadata from the ADS model would have produced incorrect inference input.

The final implementation therefore reproduces the required ICM spectral feature path locally before executing its compiled EON graph.

Reacting to Sudden Real-World Events

Another important challenge appeared only after the system was running on real hardware.

The Meta-Controller operates on inference-window-level information. That is appropriate for normal adaptive control but can make a very short transient less significant after averaging.

A physical voltage spike could therefore appear instantly on telemetry while the model selector still waited for enough samples to form the next inference window.

That observation resulted in the final transient-aware escalation mechanism.

Rather than replacing the learned controller with fixed signal bands, ARIA keeps the learned path for normal behavior and introduces the transient mechanism only for abrupt changes.

This was an important design lesson:

A physically responsive edge system may require control at more than one timescale.

The learned controller operates at inference-window timescale, while the transient detector protects the much faster sample-level timescale.

What We Learned

ARIA taught us that deploying adaptive AI on a microcontroller is as much a systems-engineering problem as a machine-learning problem.

We learned that:

A model's accuracy alone does not determine whether it is the correct model to run.
Multiple neural networks can coexist efficiently inside a single MCU firmware image.
Runtime inference selection can be treated as its own machine-learning problem.
Model input windows introduce real control latency that must be considered separately from neural-network execution latency.
Very short physical events can disappear inside aggregate window statistics.
A combination of learned decision-making and narrowly scoped physical safety/escalation mechanisms can be more practical than either approach alone.
Embedded ML failures frequently originate outside the neural network itself.
FreeRTOS stack sizing, linker behavior, generated C++ structure, DMA/DTC operation, DSP preprocessing and peripheral configuration all matter to whether an AI system works in the real world.
Hardware acceleration must be verified rather than assumed.
Keeping telemetry outside the inference-critical path makes the system more robust and genuinely edge-native.

Most importantly, we learned that adaptive inference is practical on a microcontroller.

The device does not have to choose between permanently running a small model or permanently paying the cost of a large one.

It can choose dynamically.

Why ARIA Matters

Most embedded inference applications treat a trained neural network as a fixed endpoint:

sensor → model → prediction

ARIA adds another layer:

sensor
   ↓
runtime state
   ↓
compute decision
   ↓
appropriate model
   ↓
prediction

That changes the question from:

"Which model should we deploy?"

to:

"Which model should we execute right now?"

That approach can be useful anywhere sensor data is mostly routine but occasionally requires substantially more analysis, including:

predictive maintenance
machinery vibration monitoring
electrical fault detection
battery monitoring
laboratory instrumentation
vehicle impact detection
robotics
wearable motion monitoring
drone/UAV anomaly detection
remote sensing

In those applications, always running the largest model wastes resources, while always running the smallest model may sacrifice accuracy when it matters most.

ARIA demonstrates an alternative.

What Makes the Project Stand Out

The most important technical achievements of ARIA are:

Six real neural-network variants compiled into one firmware image.
Dynamic Fast / Balanced / Accurate inference without reflashing or loading models.
Two physically different sensor domains using the same adaptive-inference concept.
A trained Meta-Controller responsible for normal runtime model selection.
Transient-aware escalation used only for sufficiently sudden physical events.
Fully local Cortex-M85 inference with no cloud dependency.
Arm Helium/MVE enabled and verified.
CMSIS-NN/CMSIS-DSP optimized kernels where supported.
Real DWT-measured model latency rather than hardcoded timing values.
FreeRTOS-based acquisition and inference architecture.
Live browser telemetry without putting Wi-Fi in the inference-critical path.
Approximately 288.6 KiB of linked flash content for the complete application, including all six models and runtime infrastructure.

The result is not simply an ADC demo or an IMU classifier.

ARIA is a runtime inference-management framework designed to let embedded AI spend compute where it is actually needed.

Built With

adaptive-inference
ads1263
anomaly-detection
arm-cortex-m85
arm-helium
cmsis-dsp
cmsis-nn
dynamic-model-switching
edge-ai
edge-impulse
embedded-ai
eon-compiler
esp32
freertos
icm-20948
meta-controller
multi-model-inference
mve
physical-ai
predictive-maintenance
real-time-systems
renesas-ra8d1
spi
tensorflow-lite-micro
tinyml

A.R.I.A.- Adaptive Runtime Inference Accelerator