Nobody can measure a lithium-ion cell's state of charge directly. There is no gauge inside the can. You infer it from terminal voltage, current and temperature, and every inference drifts: current sensors carry offset, the voltage curve goes nearly flat across the middle of the range, and cold weather bends everything. Keeping that estimate honest over years of service is what this position exists for, and it is one of the remote battery management systems engineer jobs that sit squarely in battery software rather than in the lab. Hours are full-time, the salary is $95,000 per year in USD, and the role is open worldwide, so any country works as a base.
Ask what a battery management systems engineer does all day and the honest answer is that they decide how much the pack controller should believe its own sensors. The BMS protects and balances cells and reports usable energy and power limits to the vehicle or the site controller. None of those decisions is better than the state estimates feeding them.
Here you will develop state of charge (SOC) and state of health (SOH) estimation algorithms, prove them against measured data, and write down the reasoning carefully enough that a safety assessor can follow it. Most of the battery management systems engineer job description follows from that sentence.
The starting point is coulomb counting. Integrate current over time, divide by capacity, and you have SOC. It responds instantly. It also accumulates error without limit, because a small offset in the current sensor integrates into a large error after a long drive or a week of grid cycling, and the capacity you are dividing by is itself shrinking.
So the count is corrected. The usual tool is a model-based observer, most often an extended or unscented Kalman filter wrapped around an equivalent-circuit model: an open-circuit-voltage curve plus one or two resistor-capacitor pairs to capture polarisation. The filter compares the voltage the model predicts with the voltage it actually measures and nudges SOC accordingly. Tuning is part craft. Trust the voltage too much and the estimate jitters during transients; trust it too little and you are back to an uncorrected integrator. Chemistries with a flat OCV curve, such as LFP, make the voltage correction weak across much of the range, and you will spend real time deciding where the filter is allowed to learn.
SOH asks a slower question: how much has this pack aged? Two symptoms carry most of the information. Capacity fade shows up when you compare charge throughput against SOC change over a long enough window. Resistance growth shows up in the voltage response to current steps, which you can extract from ordinary driving or dispatch profiles if you are patient about which events you accept. Both estimates feed back into the SOC algorithm and into the power limits, so a sloppy SOH quietly corrupts everything downstream.
The algorithms are built and simulated in MATLAB/Simulink. Expect cell and pack models, Stateflow logic for the state machines, and model-in-the-loop runs before anything reaches embedded code. Models often feed code generation, so write them with fixed-point behaviour and execution rates in mind.
Once the logic leaves Simulink it has to talk. The BMS publishes SOC, power limits, fault flags and cell data on CAN, and receives commands and contactor requests from other controllers. You will test that communication with Vector CANoe: checking DBC signal definitions, simulating the nodes that are absent, scripting test sequences in CAPL, and confirming timing, scaling and error handling. Among the battery management systems engineer skills this role leans on, fluency in MATLAB/Simulink, CAN and Vector CANoe is expected from day one.
A model is only a hypothesis until it meets measurement. A large share of your week goes into battery test data: pulse characterisation, drive and duty cycles, temperature sweeps, ageing campaigns. You parameterise models from some datasets and validate them on others you held back, and look hard at where the error grows (low SOC, low temperature, high current). A useful habit is to keep a small, deliberately ugly validation set, for example a hypothetical cold-soak test with a noisy current channel, and make every algorithm change survive it.
In automotive programmes the BMS is safety-relevant, which brings ISO 26262. You will document requirements so they trace from safety goals down to software, and contribute to analyses such as FMEA and FTA showing that a failed sensor or a wrong estimate leads to a safe state. Formal ISO 26262 functional safety training or a certificate is valued here. It helps you write requirements an assessor accepts the first time, though it is not a condition of entry.
Can this work be done remotely? Mostly, yes, and it is fair to be clear about the limits. Algorithm design, simulation, data analysis, CANoe test development and safety documentation run comfortably on a laptop and a good connection. Some tasks, such as flashing a controller or running a hardware-in-the-loop campaign, need equipment you will not have at home. Depending on the project, remote access to a HIL rig or time at a partner lab may be arranged, but this listing makes no promise of either. Engineers who do this well from home write precise test requests, read logs from others carefully, and design simulations that catch most problems before hardware is involved.
The employers for this kind of role are mostly electric vehicle makers and their suppliers, and companies building stationary energy storage for the grid, commercial sites and homes. Demand follows electrification: every new pack platform needs estimation, protection and diagnostics, and fielded fleets keep raising questions about ageing and warranty. Searches for battery management systems engineer jobs remote worldwide turn up a mix of these sectors.
The two often sit side by side, and the line between them is worth drawing. A power electronics engineer designs the hardware that moves energy: inverters, DC-DC converters, chargers, gate drivers, magnetics, thermal paths. A BMS engineer in a software role like this one is concerned with what the battery is doing and how much it can safely give or take. You will negotiate with power electronics colleagues over current limits and charge profiles, but your tools are estimators, models and communication tests, not switching waveforms.
You need a bachelor's or master's degree in electrical, electronics or control engineering and three to six years developing BMS software. That rules this posting out for anyone hunting entry level openings, and for people searching for battery management systems engineer jobs no experience.
For those still on the way, the path is fairly consistent. Take control theory and estimation seriously at university, build a cell model and a Kalman filter yourself on public battery datasets, and learn CAN well enough to read a trace without a decoder. A battery management systems engineer course from a university extension or tool vendor can fill gaps. First jobs are often in validation, test or calibration teams, where you see real data and real faults. A resume that shows a working estimator, its validation error and what you changed to reduce it says more than a list of tools.
The battery management systems engineer salary per year here is $95,000 USD, full-time, and you can work from wherever you live. If your background covers SOC and SOH estimation in MATLAB/Simulink, CAN testing in CANoe and some exposure to ISO 26262 work, send a CV that names the chemistries, tools and validation methods you have used, with one short example of an estimation problem you solved.