What a Battery Test Report Must Document

A complete battery test report is more than a chart of capacity versus cycle number. To be useful for engineering decisions, reproducible by another lab, or defensible in a regulatory or contractual context, a report needs to document four things unambiguously: what was tested, how it was tested, what the results were, and whether those results meet the applicable requirements.

  • Test identification: Cell or pack identifier, serial number, test program name, tester ID, channel number, test start and end date/time.
  • Procedure documentation: The complete procedure that was executed — ideally as an embedded snapshot extracted from the data file itself, not a separate document that may have been edited after the fact.
  • Test conditions: Temperature setpoints and actual temperature record, C-rate used, voltage limits, rest periods, cycle count, and any protocol deviations noted.
  • Results: Per-cycle and summary metrics — capacity, energy, coulombic efficiency, energy efficiency, ESR trends, and any auxiliary measurements relevant to the test objective.
  • Pass/fail determination: Which specification or acceptance criterion was applied, and whether the result meets, exceeds, or fails it.

MIMS Client Report Outputs

MIMS Client generates several report-relevant outputs directly from the data file:

  • Charts: Any chart configured in MIMS Client — capacity fade, dQ/dV, efficiency trend, temperature overlay, multi-cell comparison — can be printed or exported as an image. Charts include configurable header and footer text fields for report identification, and axis labels with engineering units.
  • Statistical tables: For multi-cell test matrices, MIMS can generate statistical summary tables showing mean, standard deviation, minimum, maximum, and range for any selected metric across the cell population. These tables are print-ready and export to the same chart output.
  • Data tables: The View Data screen can display filtered subsets of the raw data record — specific cycle ranges, specific report types, specific channels — and print or save as text. This is useful for including selected data tables in formal reports without exporting the full time series.
  • Embedded procedure view: MIMS Client can display the procedure embedded in the data file in full Build Test grid format, and this view can be printed as part of the report package. The embedded snapshot is tied to the data — it reflects the exact procedure state at test start, regardless of any subsequent edits to the procedure file.

The Embedded Procedure as a Traceability Record

In validated environments — aerospace, medical, grid storage bankability programs — proving that a specific procedure was applied to a specific cell on a specific date is a fundamental documentation requirement. The Maccor data file satisfies this automatically because the procedure is embedded at the moment the test starts.

This means the data file is simultaneously the results record and the provenance record. Extracting the embedded procedure from the data file and including it in the test report package provides a single, coherent document set where the test conditions and the results are permanently linked — without relying on a separate version control system for the procedure file.

For regulated programs: Request an embedded procedure extract from each data file as part of the standard report package. The extract can be saved as a .bt2 file and re-opened in Build Test for verification, or printed from MIMS Client for inclusion in the physical report.

Report Structure by Audience

The depth and format of a battery test report varies substantially depending on who will read it and what decisions it needs to support:

AudienceCore ContentTypical Format
Internal engineering reviewCapacity fade curves, CE trend, anomaly flags, comparison to previous buildsMIMS chart exports in a shared folder or slide deck; informal
Programme milestone reviewSummary metrics vs. specification, statistical spread, RPT checkpoint resultsFormal report document with embedded charts and data tables
Customer / OEM submissionFull test conditions, procedure documentation, all required metrics per agreed test planFormatted PDF with traceability appendix
Regulatory / certification bodyTest conditions, pass/fail against cited standard, instrument calibration records, data integrity statementControlled document with revision history; may require raw data submission
Grid storage bankabilityRTE over full program, partial SoC protocol, instrument calibration, complete cycle-by-cycle recordFormal deliverable specified in the financing term sheet

Chart Templates for Consistent Reporting

MIMS Client's chart template system is particularly valuable in reporting workflows. A template saves the complete chart configuration — axis selections, scale ranges, channel pairings, header/footer text, annotation styles, and statistical options. Opening any data file and applying the template instantly produces a chart formatted identically to all previous reports.

For labs that run recurring test types — formation cycles, cycle life programs, HPPC matrices — defining a template per test type ensures that all reports across the program are directly comparable, even when produced by different analysts on different days. Template files can be shared across MIMS Client installations, so the same formatting applies on every workstation in the lab.

Annotations and Comments in the Data Record

MIMS Client supports annotations that are attached directly to specific points or regions in the data record — a cycle number, a time range, a specific data point. These annotations persist in the MIMS database and appear on charts whenever that region is displayed. Common uses include flagging the cycle where a procedure restart occurred, marking cycles excluded from analysis due to a chamber fault, noting a thermal event, or identifying the RPT cycles within a long cycling program.

Because annotations are tied to the data rather than to a specific chart file, they appear automatically in any future chart that covers the annotated region — including charts produced by other analysts using the same data file. This makes annotations a useful shared communication layer within a team working on the same dataset.

Frequently Asked Questions

Can MIMS Client produce a report automatically at the end of a test?

MIMS Server can be configured to generate ASCII exports automatically at the end of a test, and these can be fed into a scripted report generation workflow. MIMS Client itself is an interactive tool rather than a batch report generator — charts, statistical tables, and data views are produced on demand by the analyst rather than triggered automatically. For high-throughput labs, the ASCII end-of-cycle export pipeline combined with a Python or R script is a practical approach to automated report production.

How do I include temperature data in a capacity fade report?

Auxiliary thermocouple or thermistor inputs are co-logged in the data record with the same time and cycle index as the electrical data. In MIMS Client, add the relevant auxiliary channel to the second Y-axis of a cycle-based chart. Temperature versus cycle number can then be plotted alongside capacity versus cycle number on the same chart, making any temperature excursions that correlate with capacity anomalies immediately visible.

What should I provide as raw data if a customer or regulator asks for it?

The raw binary .DAT file is the authoritative record. For a customer or regulator who cannot read the binary format directly, an ASCII export of the full time series with all relevant fields is the appropriate deliverable — this is the complete record in a universally accessible format. The end-of-cycle summary file alone is not sufficient for this purpose, as it does not contain the full resolution record. Include the embedded procedure extract alongside the ASCII export to provide a complete, self-contained submission.