From system architecture to defensible technical decisions.
Independent battery and BESS analysis focused on system interfaces, field diagnostics and performance—connecting equipment behavior, controls and data to practical decisions.
System integrationBattery, BMS, PCS, EMS and cross-vendor interfaces
High-power testingBattery and EV/ESS test systems
Technical leadershipR&D across hardware, software, controls and testing
What I work on
Architecture, behavior and evidence—considered together.
A performance issue may begin at an interface, a control limit, a measurement, or the design assumption itself. A useful answer depends on seeing how the full system works.
01 / System integration
System interfaces & integration diagnostics
Analyze documented configurations, operating data and interface behavior across battery packs, BMS, PCS, EMS, gateways and communications. Identify inconsistencies, control dependencies and interface assumptions that help explain unexpected system behavior.
02 / Performance diagnostics
Performance diagnostics & root-cause analysis
Investigate anomalies, dispatch shortfalls, alarms and unexpected behavior using available operating records and equipment documentation. Cross-check hardware limits, control sequences, signal quality and operating context before assigning a root cause.
03 / Battery health
Battery health & degradation assessment
Evaluate SOH, usable energy, aging trends and battery-test evidence against documented baselines. Account for measurement quality, temperature, loading and operating history rather than relying on a single reported KPI.
04 / Technical evaluation
Technical options & decision support
Compare documented requirements, reported power and energy limits, operating evidence and integration options. Make assumptions, uncertainties and trade-offs explicit so clients can evaluate practical alternatives and identify what needs further validation.
For BESS owners and operators. A single issue can generate dozens of alarm messages. A typical first step is alarm and event analysis from the exports you already have: group repeated alarms into traceable events, connect them to available operating context, and separate observed behavior, supported hypotheses and the evidence still needed from the OEM or integrator. Scope is bounded—one site, one agreed period, one or two decisions—with no new telemetry pipeline.
Evidence for the next decision. Independent diagnostic input for operational troubleshooting, integration discussions and technical due diligence teams. Deliverables connect supported findings, remaining uncertainty and the next useful check—giving clients and their technical partners a clear evidence base for further evaluation.
How I work
“Understand the physical system. Test the evidence. Make the decision explicit.”
System context
Evidence
Alternatives
Decision
I begin with the actual equipment architecture and intended operating behavior, then examine measurements, commands, communications and control limits. I compare plausible explanations with available evidence rather than treating the first correlation as a root cause.
The output: a bounded technical assessment that explains what is known, what remains uncertain, which options are credible and what to verify next.
M5BAT Pb1 / Exide1 · Flooded lead-acid storage · Public operating data
Less throughput does not, by itself, prove less capacity. The audit separates telemetry defects, recorded command changes and a remaining battery-health concern.
A separately filtered field-resistance indicator increased, but neither that signal nor the energy decline establishes a direct percentage of capacity loss or a unique root cause.
Observed absolute AC throughput
−78.0%
Recorded absolute command energy
−77.4%
2022 → 2024, analyzed records. These are energy changes, not capacity-loss estimates; the cause of lower commands remains unresolved.
Capacity rises briefly within an overall declining trend. Check measurement history and persistence before calling it recovery; the observations do not establish a single physical cause.
Voltage rebound varies across cells, rest times and the aging sequence. Compare baselines and conditions before inferring degradation; neither rebound nor a smoother trend establishes ground-truth SOH.
These are independent public-data studies, not client project outcomes, verified site recoveries or quantified financial savings. Methods, data coverage and reproducibility are case-specific; the studies do not establish a universal SOH model or transferable thresholds across chemistries.
Emerging application
AI infrastructure loads & BESS sizing assumptions.
Understanding how workload behavior and customer-side power architecture shape upstream BESS requirements is an emerging application of my battery, controls and systems-integration background.
Understand the load before sizing the buffer.
AI compute demand depends on workload behavior and rack-level power architecture. PSU, BBU, UPS and workload power-control strategies may affect the load variability seen upstream—but a backup battery is not automatically an active power-smoothing device.
My focus is on comparing load and buffering scenarios using documented equipment configurations, declared control functions and available measurements, then highlighting the assumptions that require customer or vendor validation.
The technical questions
What load envelope is credible when detailed workload traces are unavailable?
Which buffering and power-control functions are actually enabled and verified?
How do load uncertainty and transient behavior affect assumptions about BESS power and energy?
This is a developing technical focus, not a representation of completed hyperscale data-center projects or verified project savings.
About the practice
Anthony Chou, Ph.D.
Battery & Energy Systems Consultant · Systems Integration & Diagnostics
I bring experience across battery systems, power-electronics interfaces, BMS/PCS/EMS integration, controls, communications and data analysis. My work has included taking newly developed high-power battery and EV/ESS test systems through integration, testing, debugging and customer-site operation.
I have led multidisciplinary R&D teams and worked across equipment vendors to connect system architecture with real operating evidence. That combination helps distinguish a hardware limitation from a control, integration, measurement or requirements problem.
BESS Diagnostics is my independent practice based in Houston, Texas. I typically work remotely, with targeted site or vendor engagements when they are useful to the technical decision.
Start a conversation
What technical question or operating issue are you trying to resolve?
Whether the challenge involves system architecture, integration, performance or battery health, share the known evidence, operating context and decision at hand. An initial technical conversation can clarify the next useful step.