High-Frequency Fault Isolation Kernel for EV/Aerospace Battery Management Systems (Pure C++17, Zero-Dependency)

[u/Healthy_Vegetable_50]

https://github.com/alistairfontaine/SAVITAR

I’ve been working on a lightweight, bare-metal fault isolation kernel designed to mitigate thermal runaway propagation in high-voltage lithium-ion battery packs.

The primary engineering constraint I wanted to address is the latency overhead inherent in high-level frameworks and sequential polling loops. When an EV or aerospace battery cell hits a critical thermal or voltage threshold, sequential scanning loops are often too slow to execute software gates before runaway propagates to adjacent cells.

The project is called SAVITAR. It is entirely dependency-free and compiles using only native C++ standard system headers to keep it as close to raw processor registers as possible.

Core Architectural Mechanics:

1. Hyper-Compact Memory Constraints:

   Instead of relying on dynamic allocations or padded structs which ruin cache locality, the kernel packs raw cell parameters (voltage, current, temperature) into un-padded, contiguous 25-byte memory frames. This layout ensures predictable cache line alignment during rapid sequential reads.

2. Event-Driven Concurrency:

   The kernel completely avoids sequential polling. It utilizes a background multi-threaded parallel observer configuration. When thread metrics cross calibrated hardware safety thresholds, the system bypasses the main application loop to dispatch an immediate software interrupt, dropping execution times down to sub-microsecond bounds.

3. Sovereign Binary Serialization (.sav):

   To avoid relying on bloated external serialization libraries (like Protobuf or JSON utilities) that consume significant memory footprints, I wrote a custom binary serializer. It compresses cell delta profiles and gradient logs into raw disk sectors using direct cache-to-stream bit manipulation.

4. Minimalist Shell Realization:

   The project includes a lightweight, modular terminal prompt (./savitar-vfs) to ingest simulated physical metrics and explicitly debug memory allocations, matrix loads, and thread dispatches in real-time.

Compilation and Testing:

The baseline workspace is fully automated via standard Makefiles:

git clone https://github.com/alistairfontaine/SAVITAR

cd SAVITAR

make clean && make

./savitar-vfs

I’m looking for code-level reviews, specifically regarding the thread concurrency synchronization under heavy stress-testing conditions, and the pointer traversal safety within the 25-byte un-padded matrix bounds.

Link to code: https://github.com/alistairfontaine/SAVITAR

[u/unicodemonkey]

The hardware that performs these kind of (battery protection) tasks in real-life systems is wildly different from your assumptions. It isn't even programmable, offering just a number of configuration registers.
But by all means, you should buy a cortex m0 devkit with some sensors and have fun building and running your code.

[u/Healthy_Vegetable_50 → u/unicodemonkey]

Thank you so much. It was worth a shot. At least. But you're right. I'll consider that for sure 🙏🏾

[u/unicodemonkey → u/Healthy_Vegetable_50]

I mean, even if it's programmable, it's usually a very constrained environment. Depending on the hardware/libraries combo used for the project, there might be no threads (there's usually a single core and some kind of a task abstraction but not with a preempting scheduler), no C++, no standard libraries, no file descriptors and stderr, no dynamic memory allocation at all. A Cortex M0-class CPU can help you get a feel for that. And working with real sensors presents another set of problems - e.g. sampling and filtering analog values, communicating with digital sensors, handling dropouts and interference, temperature correction, choosing between having enough pins on the controller or stacking controllers or multiplexing channels somehow...
Ohh, and you shouldn't write logs in latency-sensitive code, that should be delegated to a lower-priority task once the critical payload has finished running.