SOC, SOH, and SOP Explained: What Your Battery Management System Actually Tracks
When a battery management system says a pack is at 60%, that number looks simple. It is not. A lithium battery has no float gauge or dipstick. The BMS estimates what is happening inside the cells from voltage, current, temperature, time, and a model of how that cell behaves.
The three estimates that matter most are State of Charge (SoC), State of Health (SoH), and State of Power (SoP). SoC tells the product how full the battery is. SoH tells it how much of the original battery is still left after aging. SoP tells it how much power the pack can safely deliver or accept right now.
For a simple product, these may only drive a few LEDs. For a robot, medical device, handheld instrument, or industrial product, they can decide whether the product finishes a task, shuts down gracefully, limits power, schedules service, or triggers a warranty event. That is why these are not just dashboard numbers. They are part of the product design.
Quick definitions
State | Plain meaning | Main use |
SoC - State of Charge | How much usable charge is left now | Runtime display, low-battery warning, mission planning |
SoH - State of Health | How much capability remains compared with new | Service planning, warranty, end-of-life detection |
SoP - State of Power | How much power the pack can safely deliver or accept now | Peak-load control, derating, fast-charge limits |
The important point: all three are estimates. The BMS measures voltage, current, and temperature directly, then infers the states from those measurements.
SoC: the fuel gauge that is not directly measured
State of Charge is the percentage of usable charge remaining inside the pack. In everyday language, it is the battery fuel gauge. In engineering language, it is a hidden-state estimation problem.
The most common SoC methods are used together:
Coulomb counting. The BMS integrates current over time: current out reduces SoC, current in increases SoC. This works well during active charge and discharge, but it drifts because of current-sensor offset, noise, integration error, uncertainty in true capacity, and clock error. Over time, an uncorrected coulomb counter becomes inaccurate.
Open-circuit voltage lookup. A rested cell has a voltage that maps to SoC for that chemistry. This can reset drift, but it only works well when the pack has rested long enough for voltage to settle. Under load, internal resistance pulls voltage down; during charge, it pushes it up. That makes terminal voltage a poor SoC indicator during real operation.
Model-based estimation. A more advanced BMS uses a cell model - often an equivalent-circuit model with a Kalman-filter-style estimator - to compare predicted voltage against measured voltage and correct the SoC estimate. This can be much better than voltage-only or coulomb-counting-only methods, but only when the cell model is characterized and validated.
Chemistry matters here. LFP cells have a much flatter voltage curve through most of the usable range than typical NMC/NCA cells, which makes voltage-only SoC estimation harder. LFP packs therefore lean more heavily on coulomb counting plus good recalibration at the charge and discharge extremes, where the curve finally has some slope to lock onto.
SoH: how much battery is left after aging
State of Health describes how much of the pack’s original capability remains. A new pack starts near 100% SoH. Many applications treat around 80% of original capacity as a common end-of-life reference, but the real threshold depends on the product.
There are two useful ways to think about SoH:
Capacity-based SoH asks: how much energy can the pack still store compared with when it was new? A pack at 80% capacity-based SoH has lost about 20% of its usable capacity.
SoH is harder than SoC because true capacity is usually measured by a controlled full charge-discharge test. Most products do not run perfect lab cycles in the field. A production BMS must infer SoH from partial-cycle data, resistance trends, charge-curve behavior, temperature history, cycle count, and accumulated operating stress.
SoH is not only a display feature. It affects warranty, service intervals, and customer expectations. If a product must still deliver a defined runtime after 500 cycles, the pack should be sized and managed for that end-of-life condition from the beginning.
Safety and compliance note
The BMS and certification path are connected. Standards and test programs evaluate whether the pack responds safely to abuse conditions such as overcharge, short circuit, over-discharge, temperature extremes, and abnormal operation. UN 38.3 is transport-focused; IEC 62133-2, UL 2054, and others address different safety scopes depending on product and market (IEC 60601-1 for medical systems, UL 2271/UL 2849 for some e-mobility products, IEC 62619/UL 1973 for industrial and stationary). Confirm the exact set with a compliance specialist for each target market. The practical lesson for OEMs: design the BMS for the required test path from the beginning, because waiting until the pack is built can force changes to thresholds, firmware, wiring, cells, enclosure, or samples.
For OEMs, the practical lesson is this: design the BMS for the required test path from the beginning. Waiting until the pack is already built can force changes to protection thresholds, firmware, wiring, cells, enclosure, or samples.
SoP: what the pack can safely do right now
State of Power is the maximum charge or discharge power the pack can safely accept or deliver right now. It depends on SoC, SoH, temperature, voltage limits, current limits, BMS limits, and pack resistance.
This matters when a product has peaks. A robot at 30% SoC in a cold warehouse may still have energy left, but the cells are colder, resistance is higher, and voltage sag under acceleration may be severe. If the pack allows the same peak current it allowed when warm and full, the product may hit undervoltage cutoff or overstress the cells.
A good SoP estimate lets the BMS or host system derate gracefully. Instead of suddenly resetting, the product can reduce acceleration, limit motor torque, slow a pump, or warn the user that only reduced power is available.
SoP is also a charging concept. Fast charging is not one fixed current. A pack that accepts high charge power at moderate SoC and warm temperature may need far lower charge power when cold, near full, or aged, and the BMS should enforce those limits. (Charging cold is where lithium plating starts, so this is a safety limit, not just a longevity one.)
Why the three states are connected
SoC, SoH, and SoP are not independent gauges. They form a chain.
SoH affects SoC. Coulomb counting expresses charge as a percentage of pack capacity. If the pack has aged from 100 Ah to 80 Ah but the BMS still calculates using the original 100 Ah, the SoC display will overestimate what is left. Accurate SoC over life requires the BMS to update its capacity estimate as the pack ages.
SoC and SoH affect SoP. A low-SoC pack has less voltage margin. An aged pack has higher resistance and less peak capability. A cold pack has even less available power. SoP must account for all of those, not just the original datasheet rating.
The estimates help correct each other. A full or near-full charge event may help recalibrate capacity. A long rest may help correct SoC using OCV. Repeated high-current events may reveal resistance growth. Better BMS designs use those moments to keep the state estimates honest.
This is why a cheap gauge can look fine when the pack is new and become unreliable after months of use. A BMS can't just report SoC. It must keep that SoC accurate as the pack ages.
Example: why SoC alone is not enough
Consider a warehouse robot with a 24 V pack. At noon, the display says 35% SoC. If the pack is warm, new, and moving on a flat floor, 35% may be plenty. Now change three conditions: the robot is near the end of the pack’s life, the warehouse is cold, and the robot needs to climb a ramp while accelerating. The same 35% SoC no longer means the same thing.
Aged cells have higher resistance. Cold cells have higher resistance. Low SoC gives less voltage margin. When the motor asks for its peak, voltage sag can push the pack below the system cutoff even though the gauge still shows charge remaining. That is a SoP problem, not just a SoC problem, and a better BMS warns the host, limits power, or prevents the peak before the system resets. The lesson for advanced products: the state estimates are control inputs, not just a user display.
This is why advanced products should avoid treating the battery gauge as only a user-display feature. The BMS state estimates are also control inputs for the product.
What should an OEM specify?
Do not specify “smart BMS” and stop there. Specify what your product actually needs to know and control.
Product need | Suggested requirement |
Simple runtime indication | Basic SoC, LED or simple gauge |
User depends on accurate percentage | Coulomb counting with recalibration |
LFP chemistry | Strong coulomb-counting approach; avoid voltage-only gauge |
Warranty or service planning | SoH reporting and stored usage data |
Robotics, tools, drones, motors | SoP or at least power/current derating strategy |
Fleet or rental products | SoC + SoH + logs of cycles, temperature, faults, and abuse events |
The practical specification should include: required SoC accuracy, accepted end-of-life error, whether SoH is needed, whether the host needs SoP or derating messages, communication protocol, update rate, fault reporting, and whether data logging is required.
How to validate battery state estimates
For an OEM pack, validate state estimation the same way you validate current, capacity, and temperature. Useful checks include:
SoC error after repeated partial cycles
SoC behavior after long rest periods
SoC accuracy at cold and hot temperatures
SoH trend after cycle-aging tests
Resistance-growth trend under high-current duty cycles
SoP or derating behavior at low SoC and cold temperature
Host communication timing and fault-message handling
This does not mean every product needs an EV-grade algorithm. It means the claimed accuracy should match the actual product conditions. A BMS that is accurate on a lab bench may not be accurate in a product that sees vibration, cold storage, pulsed loads, and partial charging.
Common mistakes
Treating SoC as a measurement. It is an estimate with error sources.
Using voltage-only SoC on a dynamic load. Under load, voltage sag corrupts the reading.
Ignoring aging. A 100% charged aged pack does not contain the same energy as a new pack.
Designing for energy but not power. A pack may have charge left and still fail a peak load.
Overbuying smart features. If the host never uses SoH, SoP, or data logs, those features add cost without value.
Underbuying for critical products. A medical device, robot, or high-value industrial product often needs more than a simple gauge.
What data should the BMS store?
For products that depend on accurate SoC, SoH, or SoP, the BMS should not only calculate states in the moment; it should also keep enough history to explain how the pack has been used. Useful records include charge and discharge cycles, maximum and minimum cell voltage, maximum and minimum temperature, over-current events, charge attempts outside the allowed temperature range, deep-discharge events, and communication or fault codes. This history turns the battery from a black box into a serviceable component.
That data matters in three places. First, it improves state estimation because the BMS can update its assumptions as the pack ages. Second, it helps service teams decide whether a pack is near end of life or has been abused outside its intended envelope. Third, it supports warranty decisions with evidence instead of guesswork. A pack that repeatedly hit high temperature, was stored fully charged in a hot environment, or was fast-charged cold tells a different story than a pack used within spec.
OEMs do not always need a full data logger, but they should decide early what information the product, service team, and warranty process need. If the host controller or fleet software expects this data, the communication protocol and memory strategy must be part of the BMS design from the beginning.
What accuracy means in the real product
Define accuracy in the context of the product, not just as a lab number. A handheld device may only need a user-facing estimate that avoids sudden shutdown. A robot may need enough accuracy to finish a mission and return to a charger. A medical or industrial product may need traceable state data for service and warranty. The same SoC error can be harmless in one product and unacceptable in another.
The best specification describes the consequence of being wrong. If a 10% error only annoys a user, a simple gauge may be fine. If a 5% error strands a fleet robot, shuts down a pump, or creates a service call, the BMS needs a better estimator and better validation.
What this means for your custom battery pack project
The right battery state estimation depends on the product. A handheld device may only need a rough charge indicator. A robot may need accurate SoC, SoH, and power derating so it does not stall in the middle of a mission. A medical device may need predictable runtime and service warnings. A fleet product may need logs for warranty and maintenance.
To specify it correctly, bring TapRen these inputs:
Required SoC accuracy and display type
Chemistry and cell format, if already selected
Duty cycle, including peak loads
Temperature range
Required cycle life and warranty expectations
Whether the product needs service or end-of-life warnings
Host communication protocol and data fields
Any logging, authentication, or fleet-management needs
TapRen can then match the BMS intelligence to the product: simple where simple is enough, smarter where the product depends on the battery knowing its own condition. The goal is not the most complicated BMS. The goal is a pack that reports useful states accurately enough for the decisions your product makes.
Ready to define the intelligence inside your custom battery pack? Request a custom battery pack quote and tell us what your product needs to know about its battery.
Editorial Note:
This article was developed with the assistance of AI tools to help organize the content, improve readability, and create supporting visual elements. TapRen engineers reviewed the technical content for accuracy and practical relevance.
Battery design requirements can vary significantly depending on the application, cell selection, operating conditions, certification requirements, and other project-specific factors. If you have a question about anything discussed in this article, notice something that deserves clarification, or would like to share your technical perspective, we welcome your feedback.
Please leave a comment or contact TapRen directly. We appreciate thoughtful questions and technical feedback that help us continue improving the quality and accuracy of our content.
Comments