Black Dragon Runtime

Black Dragon Runtime: the world's first Distributed Industrial Nervous System, optimized for Arm

Comment

Inspiration:

Modern edge AI systems typically follow a single execution path: Sense → AI → Decision → Action. That architecture works well for a lot of applications, but it forces every event — trivial or safety-critical — to wait for the same processing pipeline. In physical AI systems like robots, industrial equipment, autonomous platforms, and structural monitoring, that adds reaction latency exactly where it matters most, and makes the whole system dependent on one centralized inference path having enough headroom to keep up.

Black Dragon Runtime explores a different execution model. Instead of treating AI as one monolithic block, it separates decision-making into layers that operate at different timescales, concurrently rather than in a single serial chain:

Reflex — immediate, low-latency response to sustained anomalies

Prediction — short-horizon forecasting of where things are headed

Reasoning — stability-aware evaluation of whether an action actually helps

Adaptation — dynamic re-weighting of competing objectives as conditions change

The goal isn't simply to make AI faster. It's to make AI behave more like a nervous system — reacting immediately at the reflex layer while still benefiting from slower, higher-level intelligence layered on top. To demonstrate the idea concretely, we built a digital twin of a distributed structural-health monitoring system around a dense simulated optical sensing skin.

What it does:

Black Dragon Runtime is a layered execution architecture for Physical AI, demonstrated end-to-end on a structural-health monitoring digital twin. Rather than routing every decision through one inference pipeline, it distributes intelligence across four concurrent layers:

Layer 1 — Reflex Kernel. A lightweight, event-driven spiking layer continuously watches incoming signals and fires only on a sustained anomaly, not a single noisy sample. Designed for low-latency, event-driven execution on Arm edge processors — in our reaction-time benchmark it detects real faults in tens of milliseconds while producing zero false triggers under noise that made a raw single-sample interrupt fire falsely ~17 times per trial.

Layer 2 — Predictive Intelligence (Bat). Estimates short-term future degradation — temperature, stress, and damage trends — before failure actually occurs, producing an early lead-time warning rather than waiting for a threshold to be crossed.

Layer 3 — Stability Intelligence (Hermit Crab). Evaluates whether a candidate action actually reduces risk without trading away long-term stability — it vetoes actions (like "ignore and hope") whose short-term relief isn't worth their downstream cost.

Layer 4 — Adaptive Intelligence (Squid). Dynamically re-weights Safety, Productivity, Energy, and Structural Integrity as operating conditions change, so the same runtime behaves more conservatively under rising risk and more efficiently when things are stable.

Demonstration application. To validate the runtime, we built a complete digital twin: a distributed Optical Skin (simulated FBG mesh) alongside a traditional fixed point-sensor baseline, a finite-difference physics engine (heat, stress, fatigue damage, brittle rupture), the Reflex Kernel, the full cognitive architecture above, real-time actuation, and an interactive dashboard — compared quantitatively across four fault scenarios.

Across those scenarios, the runtime detects failures earlier and localizes them more precisely than sparse point-sensor monitoring in every case tested — for example, instant detection with zero-cell localization error on a localized thermal fault, versus 6+ seconds and a 12-cell error for the fixed-sensor baseline. Where early detection has time to translate into a mitigating action, it also substantially reduces structural damage (69–76% less damage than an unmitigated panel in two of the four scenarios); in the other two, the fault is effectively unpreventable by the time any sensing architecture could react, and the runtime is honest about that rather than claiming a universal damage reduction.

Arm optimization. The runtime was specifically optimized for Arm-powered edge devices, at every layer where that mattered:

Vectorized NumPy → float32 → INT8-quantized reflex kernel, with the int8 path retaining 99.8% detection agreement with the float64 reference at roughly 1/8th the memory footprint

The reflex kernel's core computation converted to TensorFlow Lite, INT8-quantized, and compiled with Arm's actual Ethos-U Vela compiler — producing a real, inspectable NPU artifact that runs 100% on the NPU (zero CPU fallback), estimated at 42.9 microseconds per inference on an Ethos-U55-256 configuration

A dedicated reaction-time benchmark (Reflex vs. Interrupt vs. Polling) measuring the metric that actually matters for a physical safety system — not just throughput, but how fast and how reliably the system notices something is wrong

Rather than reporting a single throughput number, we measured memory footprint, execution latency, reflex reaction time, quantization agreement, damage prevented, and localization accuracy — because for a Physical AI workload, those are the numbers that actually decide whether an architecture is deployable, not just fast in isolation.

Why it matters:

Black Dragon Runtime proposes an alternative execution architecture for Physical AI: instead of asking a single AI model to solve every problem on one timescale, it introduces layers of intelligence — Reflex, Prediction, Reasoning, Adaptation — operating concurrently, each at the timescale its job actually needs. The optical-skin digital twin demonstrates one application of this pattern, but the architecture itself isn't specific to structural monitoring — the same reflex/predict/reason/adapt split applies anywhere a physical system needs to react instantly and think ahead: robotics, industrial automation, autonomous vehicles, drones, and other Arm-powered edge deployments.

How we built it:

The simulation itself is Python/NumPy: a vectorized finite-difference panel (heat, stress, fatigue damage, brittle rupture), sensor models for both the optical skin and the point-sensor baseline, the spiking reflex kernel, and the cognitive layer, all wired together and covered by a pytest suite.

The Arm-specific work is the part we're most excited about, and it's real, not narrated:

We took the reflex kernel's hot loop and benchmarked four implementations of it — naive Python loops, vectorized NumPy at float64, the same at float32, and an int8-quantized fixed-point version — for both speed and memory footprint.

We expressed the reflex kernel's core per-cell computation as a small int8 TensorFlow Lite model and compiled it with Arm's actual Ethos-U Vela compiler, producing a genuine NPU-compiled artifact with a compiler-verified performance report: cycle counts, SRAM/flash use, and whether the graph fell back to the CPU at all (it didn't — 100% NPU resident on both Ethos-U55 configs we tried).

We built a dedicated reaction-time benchmark comparing three control-loop architectures — polling, raw interrupt, and the debounced reflex kernel — because for a physical safety system, how fast you notice and how often you cry wolf matters as much as raw throughput.

Challenges we ran into:

Getting believable, honest numbers out of the Ethos-U pipeline was harder than expected without physical hardware in hand: we didn't want to fake a "ran on Arm" claim, so we leaned on Vela — Arm's own compiler — since it produces genuine, compiler-verified performance estimates without requiring a physical board, and we were explicit in the write-up about which numbers are compiler-verified estimates versus what would need real silicon to confirm.

Tuning the reflex kernel's thresholds was its own rabbit hole — our first pass triggered on almost every step (false alarms two-thirds of the time), which taught us the hard way that "event-driven" only pays off if the event detector is actually selective. We also had to be honest with ourselves about the int8 quantization results: on a generic x86 dev machine, int8 arithmetic isn't always faster than float32 in NumPy — the real throughput win needs Arm's native int8 SIMD path, and it actually varied by host CPU when we re-ran it. Rather than paper over that, we reported the memory win (8x smaller) and the speed win (hardware-dependent) as two separate, honestly-scoped claims. We caught (and fixed) two real bugs the same way — a false-alarm counting bug that was inflating alarm counts, and a template-escaping bug that was silently producing broken HTML in one of our generated dashboards — both by actually re-running and re-checking output rather than trusting that "no error was thrown" meant "it's correct."

Accomplishments that we're proud of:

Getting a real, inspectable artifact out of Arm's actual NPU compiler — not a slide, not an estimate we made up, but a .tflite file and a CSV report anyone can open — feels like the accomplishment that actually answers "but where is Arm?" We're also proud of the reaction-time benchmark: it's a genuinely different lens than the Python-vs-NumPy comparisons most submissions in this space reach for, and it tells a real story (interrupt is fast but noise-fragile; polling is robust but slow; the reflex kernel is the only one of the three that's both fast and reliable).

What we learned:

We learned the Arm Ethos-U toolchain end to end — model quantization, Vela's compilation flow, and how to read its performance reports — and came away with a much sharper sense of where the real wins in edge AI optimization live: not in "make the number smaller," but in choosing which optimization (vectorization, precision, quantization) actually pays off on the target hardware you're deploying to, and being willing to say clearly when it doesn't (yet).

What's next for Black Dragon Runtime:

Validate the Ethos-U numbers on a real Corstone-300 FVP or physical Ethos-U55 board, upgrading "compiler-verified" to "measured on silicon." Port the int8 reflex kernel to a real CMSIS-NN C implementation for boards without NPU silicon at all. Scale the Bat forecaster onto an Arm64 server path (Graviton + Arm Compute Library) for the Cloud AI side of the same architecture. Generalize the four-layer runtime beyond the structural-monitoring demo — the reflex/predict/reason/adapt split is designed to be domain-agnostic, and proving that on a second physical-AI use case (robotics or drones) is the natural next milestone. Swap the simulated Optical Skin for real FBG interrogator hardware and close the loop on an actual physical panel.

Built With

Share this project:

Updates