How to Read OBC Test Reports and Production Records
How to read OBC test reports and production records: check unit identity, configuration, conditions, criteria and scope before relying on any supplier document.
Knowing how to read an OBC test report means checking five things before relying on it: which unit was tested, which configuration it carried, under which conditions, against which criteria, and what scope the document actually covers. A report that fails any of these checks may still contain useful information, but it cannot support a buying or release decision on its own. This article teaches the reading method for test reports, validation summaries and production records, so a buyer or supplier quality engineer can judge any supplier document in the time it takes to read its first pages. The method applies equally to a DC-DC converter or a 2-in-1 unit: read the identity, conditions, criteria and scope for each function, not only for the charging side.
Key takeaways
- A report proves a unit, a configuration and a date, or it proves nothing the buyer can rely on.
- Read identity first, results second. A strong result for the wrong unit or the wrong configuration is not evidence for this programme.
- A validation summary must state its scope, methods, sample identity, conditions, criteria, results and deviations, or it cannot be relied on.
- Production records prove consistency only when they are tied to units or batches, with the test version recorded.
- Scope is the most common reading failure. Type reports, company certificates and undated files each prove less than they appear to.
A Test Report Proves an OBC Unit, a Configuration and a Date — or Nothing
Every supplier document makes an implicit claim: this record describes this product, in this configuration, at this time. Reading a document well means testing that claim before reading the results. Start with the identity block: the model name, the configuration or revision, the serial numbers where the report is serialized, the date, and the author or laboratory. If any of these is missing, the document cannot be tied to the units under discussion, and everything after it is unanchored.
Configuration deserves special attention. An onboard charger (OBC) programme involves several versioned items at once: hardware revision, software or firmware version, connector and harness part numbers, and the CAN database revision. A report that names the model but not the configuration may describe an earlier revision, a different software build or a different connector set. Ask which configuration the report covers, and compare it with the configuration being quoted or released. If the two do not match, ask for the report that does, or record the mismatch as an open item.
Date matters for the same reason. A report from an earlier design stage, an earlier revision or an earlier production run describes a unit that may no longer exist in that form. Check the date against the configuration history, and ask whether anything versioned has changed since the report was issued. A document with no date cannot answer that question, and should not be filed as current evidence.
This article covers reading method only. Which documents to request in the first place is covered in OBC and DC-DC 3D Models and Drawings: What to Request First for the mechanical and drawing package, and in Evaluating an OBC or DC-DC Sample: What the First 72 Hours Should Prove for the sample evidence package. Use those lists to request the documents, and this article to read what arrives.
OBC Test Reports: Identity, Conditions, Criteria and Results
A test report is only as good as its identity section. Before reading any result, check the fields in the table below against the programme record. Each field has a comparison target: a report field that cannot be compared with anything the buyer holds is a field the buyer cannot rely on.
| Report field | Compare it against |
|---|---|
| Model and configuration | The quoted or released configuration, including hardware and software revisions. |
| Serial numbers or sample identity | The units under discussion, or the sample identity agreed for the check. |
| Test date | The configuration history: has anything versioned changed since this date? |
| Laboratory or author | The named lab or author, and whether the method used is stated. |
| Standard or method | The requirement the check was meant to satisfy, as written in the programme requirements. |
| Conditions | The conditions the programme requires: the operating points, environment and load state the check must cover. |
| Criteria | The pass and fail limits agreed before the check, not limits chosen after the result. |
| Results | The criteria, unit by unit. A summary result with no per-unit data cannot show a marginal pass or a single-unit failure. |
| Deviations | The agreed method. Any deviation must be stated, with its effect on the result. |
| Approval | A named approver and a date. An unsigned, undated report is a draft, whatever its file name says. |
Conditions and criteria are where most reading errors happen. A result stated without its conditions cannot be compared with another result, and a result judged against unstated criteria cannot be called a pass. Ask for both in the report itself, not in a covering email. If the report states conditions in general terms, ask for the specific operating points: the input and output conditions, the load state, and the environment in which the check ran. General conditions hide the cases that matter, such as combined load on a 2-in-1 unit or sustained operation at the top of the temperature range.
Results need the same discipline. A single summary line, such as "pass", tells the buyer nothing about margin. Ask for per-unit results where the report is serialized, and for the measured values behind each pass or fail decision. A marginal pass, repeated across units, is a different risk from a comfortable pass, and the buyer cannot tell them apart from a summary alone. Where a check failed and was re-run, the report should show both the failure and the re-run, with the correction recorded between them. A report that shows only the final pass hides the history the buyer needs to judge the fix.
The checks themselves belong to the validation programme, not to this article. What performance testing should cover is set out in How EV Charger Performance Testing Ensures Reliable Performance Before Mass Production, and the validation context for protection and environment in IP67, -40°C, and Automotive Validation Explained. This article does not list test types. It teaches the reader to check whether any report, for any check, carries the identity, conditions and criteria that make its result usable.
OBC Validation Summaries: Minimum Contents Before You Rely on Them
Suppliers often provide a validation summary instead of the full set of test reports. A summary can be a legitimate way to present a large validation programme, but only when it carries enough content for the buyer to judge it. A summary that states conclusions without scope, methods or deviations is a claim, not a summary. The table below lists the minimum contents a validation summary should carry before the buyer relies on it.
| Minimum content | Why it is required |
|---|---|
| Scope: models, configurations and revisions covered | Without scope, the summary cannot be tied to the programme. A summary covering a different configuration proves nothing for this one. |
| Methods and standards used | Without methods, the buyer cannot judge whether the checks match the requirements. Name the method for each check, not only the programme as a whole. |
| Sample identity and build stage | Which units were checked, at which build stage, and how they relate to the production configuration. DV, PV and small-batch evidence must be distinguished. |
| Conditions | The conditions each check ran under, stated specifically enough to compare with the programme requirements. |
| Criteria | The pass and fail limits agreed before the checks, stated per check. |
| Results summary | Results per check, including failures and marginal passes, not only an overall conclusion. |
| Deviations | Every deviation from the agreed method, with its stated effect on the result. |
| Date, revision and author | The summary's own identity, so it can be filed, superseded and compared with later summaries. |
Ask for the full reports behind any summary conclusion that matters to the release decision. A summary is a map to the evidence, not a substitute for it. Where the supplier cannot provide the underlying reports, record that limit in the programme file, and treat the summary's conclusions as uncorroborated for the affected checks. Where the summary covers several configurations, ask for the results broken down by configuration. Combined results hide the configuration that performed worst.
One question exposes most weak summaries: "Show me the check, the unit, the condition and the criterion behind this conclusion." A summary that can answer that question for each conclusion is usable. A summary that answers with a general assurance is not. File the answer with the summary, so the next reviewer does not have to ask again.
OBC Production and End-of-Line Records: Consistency Evidence
Test reports prove that identified OBC or DC-DC units were checked. Production records prove, or fail to prove, that production units keep matching the validated configuration over time. The two kinds of evidence answer different questions, and a buyer needs both: validation evidence for the design and the process, and production evidence for consistency.
Read a production record by asking what it ties together. A useful record ties a finished unit or batch to its configuration, its component lots, its end-of-line test result, and the test software version and limits used. The test version matters: changing a limit changes what "pass" means, so a result without the test version cannot be compared with a result from another batch. Ask what is recorded per unit and what is recorded per batch, and whether the record allows a unit to be traced back to its component lots and forward to its shipment.
End-of-line records deserve a specific check. Ask what the end-of-line test covers, what limits it applies, and how a failure is dispositioned: rework, retest, scrap, or use-as-is with approval. A record that shows only passes, with no failure handling, tells the buyer nothing about what happens when a unit fails. Ask for the failure-handling rule in writing, and for a sample record showing a failed unit's path, with identifying details removed if needed. The point is the process the record shows, not any specific unit's history.
Consistency also depends on the test equipment itself. Ask how test equipment is calibrated, how often, and what happens to results produced by equipment found out of calibration. Ask whether the calibration record is filed with the production record or held separately, and how the buyer can check it. These are process questions, and they need process answers: a description of the calibration record and the out-of-calibration rule, not an assurance that equipment is maintained.
Finally, ask how long production records are kept, and in what form the buyer can obtain them. Record retention and access are terms to agree in writing before volume starts, not details to discover when a batch question arises months later. Do not assume a retention period. Agree one, record it, and link it to the traceability terms in the supply agreement.
Scope Traps in OBC Documents: Type Reports, Company Certificates and Undated Files
Scope traps appear when an OBC document proves something real, but less than the buyer assumes. The document is genuine. The error is in reading it as proof for a wider scope than it covers. The table below states, for each common document type, what it can prove and what it cannot. Read the scope statement on the document itself: covering emails and file names routinely overstate it.
| Document type | What it can prove | What it cannot prove |
|---|---|---|
| Type report | That identified sample units, at a stated configuration and build stage, met stated criteria under stated conditions. | That production units, at a different configuration or build stage, will perform the same way. That link needs production evidence. |
| Company certificate | That a company's system or process was assessed against a stated scheme, for a stated scope, on a stated date. | That a specific model complies with a specific requirement. Model compliance needs model-scoped evidence. |
| Serialized test report | That identified units, named by serial number, produced stated results under stated conditions. | Anything about units outside the named serial range, or about configurations other than the one recorded. |
| Validation summary | That a validation programme reached stated conclusions, where the summary carries the minimum contents in the previous section. | Anything beyond its stated scope, and nothing at all where scope, methods or deviations are missing. |
| Undated file | That a document exists, in the form presented. | Currency, configuration match, or supersession. An undated file cannot be placed in a configuration history. |
| Datasheet | Intended performance in summary form, at a stated revision. | That any unit was tested, or that any result was achieved. A datasheet is a claim to be evidenced, not evidence itself. |
Two reading habits prevent most scope errors. First, read the scope statement before the results. The scope statement says what the document covers; the results say what happened within that scope. Reading results first invites the reader to assume the widest possible scope. Second, compare the document's scope with the programme's scope in writing. Note the comparison in the supplier file: document scope, programme scope, match or mismatch, and the action taken. A mismatch is not a reason to discard a document. It is a reason to request the document that does match, or to record the gap as an open item.
For CAN-related documents specifically, the DBC file and protocol document need the same scope reading: revision, matched protocol revision, and the configuration they describe. OBC DBC Files and CAN Matrices: What to Expect Inside explains what those files should contain. A DBC revision that does not match the released software revision is a scope mismatch, however complete the file itself looks.
OBC Document-Check Checklist
Use this checklist for every supplier document the programme relies on. Check identity and scope first, results second. A document that fails an identity or scope item should not be filed as supporting evidence until the gap is closed or recorded as an open item.
- ☐ Model, configuration and revision are stated on the document and match the programme configuration.
- ☐ Serial numbers or sample identity are stated where the document is serialized, and match the units under discussion.
- ☐ Date and revision are stated, and the document is the current revision for the configuration.
- ☐ Author or laboratory is named, and the method or standard used is stated.
- ☐ Conditions are stated specifically enough to compare with the programme requirements.
- ☐ Criteria are stated, agreed before the check, and applied per unit or per check as appropriate.
- ☐ Results are stated per unit or per check, including failures, marginal passes and re-runs with corrections recorded.
- ☐ Deviations from the agreed method are stated, with their effect on the result.
- ☐ Scope statement is read and compared with the programme scope in writing; any mismatch is recorded as an open item.
- ☐ The document is filed with its identity, scope comparison and reading notes, so the next reviewer can rely on the file without re-reading the whole document.
Related reading: OBC and DC-DC 3D Models and Drawings: What to Request First · OBC DBC Files and CAN Matrices: What to Expect Inside · Evaluating an OBC or DC-DC Sample: What the First 72 Hours Should Prove · EV On-Board Charger Performance Testing: What Manufacturers Should Check
FAQ
Which report proves the tested OBC unit matches the quoted OBC unit?
A serialized test report that names the model, the configuration including hardware and software revisions, the serial numbers, and the date, and whose configuration matches the quoted configuration. A type report proves the design was checked on sample units, but it does not by itself prove the quoted unit matches. Compare the report's identity fields with the quotation and the agreed configuration, and record the comparison. If the report names a different configuration, ask for the report that matches, or record the mismatch as an open item.
Should I request full OBC test reports or summaries?
Request both, for different purposes. Use the validation summary to understand the programme: its scope, methods, sample identity, conditions, criteria, results and deviations. Then request the full reports behind any conclusion that matters to the release decision, and read them with the identity and scope checks in this article. A summary without underlying reports is uncorroborated for the checks it summarises. Agree the document set in writing before the gate review, so the request does not arrive after the decision.
What should an OBC validation summary state at minimum?
Scope covering models, configurations and revisions; methods and standards used; sample identity and build stage; conditions; criteria agreed before the checks; results per check including failures and marginal passes; deviations with their effects; and the summary's own date, revision and author. A summary missing any of these cannot be relied on for the affected checks. Ask for the missing content, or for the underlying reports, and record the gap until it is supplied.
How often should OBC production records be reviewed?
Agree the review cycle and the review triggers in writing before volume starts, rather than assuming a fixed period. A review cycle should state how often records are reviewed, who reviews them, what the review checks, and what triggers a review outside the cycle, such as a batch finding, a change notice or a failed end-of-line trend. Record the agreement in the supply terms, and file each review with its findings and actions. A cycle that is never written down is a cycle that slips without notice.
Related Echelon Products
See the full range on the products page.
Confirm cooling, protection, CAN, efficiency and ratings for the specific model in its datasheet before you specify it. Do not treat a rating stated for one model as true for every model. The dual-input unit's CAN and diagnostic features vary by model; confirm them for the specific unit under discussion.
Next Step
Take the next supplier document that arrives and read it with the checklist above, identity and scope first. Note what it proves, what it does not prove, and what is missing, and file the notes with the document. The habit takes minutes per document and prevents the most common evidence error: relying on a genuine document for a scope it never covered.
To start that conversation with Echelon, share your vehicle and battery requirements through our contact page, and see how a custom programme is scoped on our OEM/ODM page.
About Echelon Charger
Echelon Energy Technology specializes in onboard chargers, DC/DC converters, and integrated EV power solutions for commercial and specialty electric vehicles.
For technical discussions, product selection, or OEM/ODM cooperation:
Email: nancy@tici-energy.com
WhatsApp: +86 18114665311
