From system architecture to defensible engineering decisions.
Battery and BESS engineering across system integration, field diagnostics and performance assessment—connecting equipment behavior, controls, data and technical risk to practical decisions.
System integrationBattery, BMS, PCS, EMS and cross-vendor interfaces
High-power testingBattery and EV/ESS test systems up to approximately 500 kW
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. The engineering answer depends on seeing how the full system works.
01 / Systems engineering
Architecture & multi-vendor integration
Review battery and BESS configurations across packs, BMS, PCS, EMS, protection, gateways and communications. Identify interface assumptions, control dependencies and constraints that affect actual system behavior.
02 / Field engineering
Performance diagnostics & root-cause analysis
Investigate anomalies, dispatch shortfalls, alarms and unexpected system behavior. 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
System trade-offs & engineering decisions
Examine sizing assumptions, available power and energy, integration options and technical risk. Separate verified requirements from uncertainty so stakeholders can compare practical alternatives without treating overdesign as the default.
Decision relevance. Independent technical input for architecture review, operational troubleshooting and engineering due diligence. The deliverable is a clear basis for action: supported findings, remaining uncertainty and the next useful check—not asset pricing or financial underwriting.
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 engineering 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 power interfaces & BESS sizing.
Connecting customer-side power design to 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 building defensible load and sizing scenarios from equipment configurations, declared controls and available measurements, then identifying the assumptions that require customer or vendor validation.
The engineering 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 the remaining uncertainty and transient requirements affect BESS MW, MWh and risk allocation?
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 engineering, 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, at scales up to approximately 500 kW.
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 engineering decision.
Start a conversation
What engineering decision are you trying to make?
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.