Power electronics
Battery Management System Design
Kyros Engineering designs battery management hardware and firmware — cell monitoring and balancing, state-of-charge estimation, protection architecture, charger and load coordination, and the fault behaviour that has to be provably correct before a pack ships. We work across the boundary where BMS, power electronics and system firmware meet, which is where most pack programs actually get stuck.
Scope this with usA BMS is not one design. It is a measurement problem, a control problem and a safety argument sharing a board, and the three have different failure modes and different reviewers.
Programs stall when those are owned separately — the pack integrator assumes the BMS vendor covered a fault case, the BMS vendor assumes the system firmware handles it, and nobody has written down which is true.
Measurement before cleverness
State estimation is only as good as the front end feeding it. We size the measurement chain against the accuracy the estimator actually needs.
- Cell voltage accuracy budgeted end to end, including reference drift over temperature and life
- Current sensing chosen for the real dynamic range, not the peak alone
- Temperature sensing placed where the thermal model says it matters, not where routing was easy
- Isolation and common-mode handled as a design constraint from the start
- Calibration and its traceability decided before production, not after the first drifted unit
Protection architecture and the safety case
The question a reviewer asks is not whether protection exists — it is what happens in each single-fault condition, and how you know. We build the fault table early and design the hardware and firmware boundaries to match it, so protection that must be fast lives in hardware and protection that must be smart lives in firmware.
Where the system boundary usually leaks
Most of the expensive surprises live in the seams.
- Charger handshake and fault propagation between charger, BMS and system controller
- Contactor and pre-charge sequencing, including behaviour on interrupted sequences
- Sleep, wake and quiescent current in a pack that must sit on a shelf
- Firmware update of a BMS inside a sealed pack
- Communications — often CAN — where the fault semantics were never fully specified
When to call
You probably want this if…
Frequently asked
Do you design a BMS from scratch or integrate an existing one?
Both, and the honest answer for many programs is integrate. A well-chosen monitoring front end plus a rigorously specified protection and communication design beats a bespoke BMS in most cases. We will tell you which situation you are in before you spend on the wrong one.
Can you help with the safety argument, not just the design?
Yes. We build the single-fault table early and design the hardware and firmware boundaries to match, so the evidence is a by-product of the design rather than an archaeology exercise before review.
What does a BMS engagement usually start with?
A two-week architecture diagnostic at $6,000, which for pack work generally means the measurement budget, the fault table, and a clear statement of which subsystem owns which failure. You keep that document regardless of what follows.
Pack program stuck between vendors?
We will write down who owns which fault. That alone unsticks most of them.