ANALYSIS The operating-data test Fresh signals. Consistent timestamps. Clear control authority. Auditable results. Hero image: AI-generated conceptual illustration, not a photograph of an actual facility. A battery can be available on a trading screen and still be unable to deliver the power a trader expects. A stale state-of-charge reading, a disconnected temperature sensor or a misunderstood export limit can separate the commercial model from the physical plant. As storage portfolios become more complicated, the quality of the operating data deserves the same scrutiny as the algorithm consuming it. That is the issue behind a fresh industry discussion about battery analytics. Energy-Storage.news listed an October 16 interview with Arenko engineering director Dan Taylor on standardisation, third-party choices and outcomes in battery energy storage data. The public listing establishes the discussion, not a new product launch or a quantified performance improvement. This analysis examines the operating implications, rather than treating the interview as evidence of undisclosed results. The distinction is important on a quiet news weekend. Better analytics can support better decisions, but installing software does not establish how much extra revenue a project will earn. Owners need to know what information is available, whether it is trustworthy and who has authority to act on it. The shared connection makes the problem concrete Arenko’s August announcement about Ørsted’s Iceni project offers a practical example. The company said its Nimbus platform had been selected for a 300 MW / 600 MWh battery associated with the 2.9 GW Hornsea 3 offshore wind farm. The announced operating target was the first quarter of 2027. Those figures describe a planned project and a software selection, not proof that the battery is already trading. The arrangement is more demanding than sending a charge instruction to an isolated storage site. Arenko says Iceni will share transmission infrastructure and an onshore grid connection with Hornsea 3. That means battery decisions must account for another large asset and for the connection through which electricity moves. Available battery power alone is not the complete operating constraint. A hypothetical example shows why. A battery might have spare discharge capability while wind generation is already using the permitted export capacity. An optimiser that sees only battery state of charge could recommend a commercially attractive dispatch that cannot be delivered at the connection point. The relevant information must arrive together, with consistent timestamps and a clear definition of each limit. A measurement is not automatically a usable signal Operational telemetry includes measured power, voltage, current, temperatures, equipment status and estimates such as state of charge. These are not interchangeable. Some originate in meters, others in control systems, and some are calculated by battery management software. Their update rates, accuracy and failure modes can differ. Combining them requires more than collecting a large volume of records. A missing value must not silently become zero. A stale reading should not look like a fresh observation. Charging and discharging need consistent sign conventions. Time zones and clock drift must be resolved before an analyst concludes that equipment missed a command. The commercial consequence is straightforward: a model can optimise against an operating condition that no longer exists. Even an excellent price forecast cannot repair a mistaken view of available energy or equipment availability. Data validation therefore belongs before dispatch recommendations, not only in a monthly performance report. Separate monitoring, diagnosis and control Three functions often sit under the analytics label. Monitoring identifies what the plant reports. Diagnosis investigates why its behaviour differs from expectations. Control changes what the plant does. Buyers should distinguish those functions because they involve different responsibilities and different consequences when something goes wrong. An independent analytics provider might identify an unusual temperature pattern without having permission to change operating limits. A trading platform might submit a dispatch schedule while a local controller enforces equipment and connection restrictions. Battery protection remains a separate safety responsibility; a cloud dashboard is not a substitute for the protections designed into the system. Arenko describes Nimbus as connecting technical and commercial performance, with asset-control and trading products. That illustrates the breadth of the software stack. It does not mean every owner should buy the same architecture. The procurement question is which party owns each decision, which information supports it and how the site behaves if communications fail. Revenue claims need a fair comparison Evaluating a software service by gross trading revenue alone can produce misleading results. One battery may face different market prices, connection restrictions, outage periods or warranty limits from another. A higher revenue number does not establish that the algorithm was better if the underlying opportunities were different. A useful evaluation records the instructions sent, the limits known at the time and the plant response. It also distinguishes market opportunity from technical availability. If a rack was unavailable, the owner needs to know whether a lost dispatch reflects an equipment problem, a communication problem or a trading choice. Any comparison should also identify costs and constraints. Extra cycling can create revenue while consuming warranted throughput. Auxiliary demand and conversion losses affect the energy that reaches the meter. Software fees matter. The aim is not to discourage optimisation, but to avoid paying for a headline improvement that disappears when the full operating boundary is included. Data access becomes a lifecycle issue A storage project may outlast its first software contract. Owners therefore need usable historical data when they replace a service provider, investigate a fault or support a warranty claim. A dashboard screenshot is much less useful than a time-aligned record of commands, measurements, alarms and configuration changes. Contracts should make the practical details explicit: which records can be exported, in what format, at what resolution and for how long. They should identify who can change settings and whether those changes are logged. Access rights must be paired with security controls so that easier analysis does not create uncontrolled remote access to plant equipment. This is different from tracing a cell through its manufacturing supply chain. The operating question is what a commissioned asset was instructed to do and what it actually did. That history can matter when counterparties disagree about availability, delivery or the cause of an equipment problem. What owners should ask next The most useful demonstration is not a polished forecast chart. It is a walkthrough of an imperfect operating day: a communications interruption, a restricted export window, a component outage and conflicting sensor readings. The provider should explain what was detected, which decisions changed and what evidence remains available afterward. Owners can also ask how proposed revenue improvements will be tested against an agreed baseline. Results should be reproducible from accessible records, with exclusions and assumptions visible. A service that cannot explain its measurement boundary is difficult to evaluate, however sophisticated its marketing sounds. The near-term lesson is narrower than saying artificial intelligence will transform storage. Battery software already has to coordinate physical equipment, market instructions and shared infrastructure. The commercial value of more advanced models depends on that foundation being dependable. For operators, th