Battery Monitoring: From Inspection to Condition Care

1. Why periodic inspection is not enough

Conventional battery maintenance relies on manual inspection: engineers visit the battery room on a fixed cycle with a multimeter, measure string voltage, and note appearance and temperature. This approach has two structural gaps.

Coverage is the first. A string typically holds dozens to a hundred or more cells, and measuring every cell by hand is time-consuming, so sampling tends to replace full measurement in practice. Even when the string voltage reads normal, an individual degraded cell can stay hidden.

Timing is the second. Battery degradation is not linear, and internal resistance accumulates over weeks in the early stage. One measurement per quarter means the observation window in which intervention is still possible has already passed.

Online monitoring changes the sampling density: measurement moves from a snapshot at one point in time to a continuous time series, and the basis for judgement shifts from a single reading to a trend.

2. What the measurement layer collects

The core of the measurement layer is the division of labour between sensors and collection devices. Typical configurations fall into three signal groups:

• Per-cell voltage: collected cell by cell to reveal lagging cells and inconsistency within a string;
• Internal resistance: obtained by AC injection or DC discharge, the key quantity for degradation trends, where measurement precision and resolution set the boundary of early detection;
• Temperature: cell or module temperature, used to identify abnormal temperature rise and to trigger alarms.

Collection devices usually reach the platform over RS485, Modbus or Ethernet. In distributed locations such as battery compartments and substations, field collection units aggregate locally first and then upload to a central platform.

3. The platform layer: B/S architecture and multi-site centralisation

Collecting data is only the starting point; the platform layer answers who can see what, and whether it can be traced.

In the formal technical solutions we have been involved in, the battery monitoring platform uses a B/S architecture: once field data is uploaded, operations staff can review cell voltage, internal resistance and temperature curves in a browser and export inspection and statistical reports. In multi-site cases, separate battery rooms, substation DC systems or storage compartments connect to the same platform as independent sites, so comparison happens under one consistent definition.

Those solutions also include battery ledger management, linking battery model, commissioning date, host system and past measurement results. The ledger answers questions such as when a given battery was commissioned and how much its internal resistance has changed over the past six months, instead of requiring a search through field records each time.

4. Judgement and alarms: how thresholds and tiers are set

Online monitoring usually lands on alarms, and alarm design has to answer two questions first: where the thresholds come from, and who receives the notification.

Thresholds generally rest on three sources: the parameter range given by the battery manufacturer, a baseline formed from measurements taken soon after commissioning, and statistics accumulated from similar batteries in service. The baseline carries the most weight: for batteries of the same model under the same duty, the initial measurements alone define a comparable range.

Tiering exists to separate response actions. A limit-exceeded notice schedules a planned check; a sustained deviation raises a work order; a sharp change in temperature or voltage corresponds to a site condition that needs immediate confirmation. The three-tier alarm arrangement used in these solutions routes events of different severity to different people rather than piling everything into one alarm list.

One engineering precondition is easy to overlook: the alarm responsibility chain must be settled during project definition. Whether an alarm goes to the control room, the equipment department or an outsourced maintenance provider changes both the notification method and the escalation deadline; the degree of interface openness also determines whether the system can later interlock with existing monitoring.

5. From inspection records to condition-based maintenance

Chaining the three layers together produces a traceable battery record: the measurement history of each cell, the time and outcome of every alarm, and the basis for every replacement.

For maintenance managers, what changes is the evidence behind decisions:

• Replacement cycles move from a fixed service life to a judgement based on internal resistance and capacity trends;
• Inspection workload shifts from measuring every cell by hand to checking exception items;
• Audits and reporting can export data from the system instead of assembling paper records;
• Replacement budgets for a battery fleet can be phased by condition rather than spent in one cycle-end batch.

It is worth stating clearly that this kind of system provides a basis for judgement and does not replace electrical safety design or fire protection requirements. Ventilation, fire protection and insulation in battery rooms are governed by the relevant professional standards; the relationship between monitoring and those systems is data exchange and coordinated alarming.

6. Boundaries worth confirming before the project starts

If you plan to move ahead with battery online monitoring, settle the following before placing an order:

• Measurement range and precision: cell voltage range, internal resistance resolution and number of temperature points, all mapped to the actual battery model;
• Site scale and expansion: how many cells, how many sites, and how capacity growth will be connected;
• Interface and interlock scope: the data exchange boundary with existing monitoring, access control, fire systems or higher-level platforms;
• Alarm responsibility split: notification targets, response actions and escalation paths for each alarm tier;
• Deployment and network conditions: what network path exists on site, and how sites without or with weak connectivity buffer data locally.

The earlier these conditions are confirmed, the better the solution scope matches the actual operations process.