What RFQ Language Makes Battery Pack EOL Test Results Useful?

An EOL requirement in a battery pack RFQ only produces usable results when the RFQ forces the bidder to state four things before award: the exact parameters measured and their units, the numeric pass/fail limit for each one, the per-unit record fields delivered with production, and a sample data file exported from the supplier's current EOL station. Without those four, "EOL tested" is an adjective in a quotation, not a specification, and nothing in the purchase order entitles you to the evidence behind it.

I was standing at the end of a pack line, close enough to the fixture to smell the hot glue from the label printer, watching an operator drop a 48 V pack onto a bed of pogo pins. The monitor above the station showed PASS in a green box the size of a playing card. It had been green for every pack I had watched that hour.

Can you send me the record for that one, I asked.

The process engineer nodded, and two days later a screenshot arrived. Just the green box. No serial number, no timestamp worth trusting, no voltage, no current, no firmware revision, nothing that told me which physical pack that result belonged to or what the station had actually measured to earn it.

Everything I now put in an RFQ about end-of-line testing exists to prevent that screenshot.

What the quotation line item usually says

"EOL test — included." "Testing: 100%." "Electrical test per specification." A single row in the cost breakdown labeled Test with a number next to it.

Two suppliers can write those words and be selling completely different things. One runs an open-circuit voltage check and a hipot in thirty seconds and prints a label. The other holds a CAN conversation with the BMS, reads cell group voltages and thermistor channels, verifies insulation resistance, confirms the pack reports the right firmware revision, and writes sixty fields per unit into an MES. Both will tell you they do EOL testing, and both will be telling the truth.

You cannot tell them apart from the quote. You can only tell them apart from the RFQ you sent.

Naming parameters, units, and limits

The wording I use asks the bidder to list, for their EOL station: every parameter measured, the instrument or channel used, the unit of measure, the accept and reject limit, and where in the approved pack specification that limit comes from.

I do not write the limits myself. I am not the person who should be deciding what insulation resistance threshold is correct for a given pack design, and neither is a procurement template. What the RFQ does is force the supplier to state theirs in numbers and point to the line in the specification it verifies. When two bidders come back with different thresholds for the same parameter, that is a conversation about the pack specification, and it is a much better conversation to have in the bid cycle than in a containment meeting eighteen months later.

Two follow-up questions belong in the same section, because they cost nothing to ask and they tell you a lot:

• Are the limits hard-coded in the test program, or read from a configuration file?
• Who can change them, and what has to happen before a change takes effect?

A supplier who cannot answer the second one has a test station, not a controlled test process.

100% test or sample validation, and what happens to a fail

One sentence settles it: is EOL testing performed on every pack, or on a sample, and if it is a sample, how is the sample selected and what happens to the lot when a unit fails?

Sample-based validation is legitimate. For a low-volume, high-mix program it may be the sensible engineering choice. But it is a different product than 100% testing, it should be described differently in the bid, and it should be priced differently in the breakdown. What you do not want is a quote that says 100% and an audit that shows the tester running on one pack in twenty.

Then the failure path, which is where most RFQ packages are thinnest. Ask:

• Where does a failed pack go, physically?
• Is it quarantined and dispositioned, or does it go back on the bench for rework and retest?
• Does the record keep the failed result after a retest, or does the pass overwrite it?
• Is there a failure code, and is it a fixed list?

A station that overwrites a fail with a subsequent pass gives you a first-pass yield of 100% forever, and it also gives you no way to see a drifting process. The retest history is often the most valuable field in the whole file, and it only exists if you asked for it before the test software was configured.

The record is the deliverable

This is the part that people skip. EOL testing produces two outputs: a decision about the pack, and a record about the pack. The RFQ has to specify both, and the second one is the one you will actually use.

The field list I put in front of bidders, roughly:

• Unit serial number
• Work order or lot
• Part number, and the pack specification revision the test was written against
• BMS firmware revision, read from the pack rather than typed in
• Station ID
• Date and time
• Operator identifier
• Each parameter, with value, unit, limit, and per-parameter result
• Overall pass/fail
• Retest count
• Failure code, if any

Format matters less than export. One row per unit, one column per field, header row with names and units. A PDF of a screenshot is not a record. You cannot compute yield from it, you cannot trend a parameter against time, and you cannot join it to a field return three years later when a customer sends a pack back.

Ask for the data file before you talk about price

The single most useful thing in the whole package is a sample EOL data file from the supplier's current production, exported the way they would export it for you. Not a template. Not a mock-up. A real file from a real run.

When it arrives I look at five things, in this order. Does the header match the fields they promised in the bid? Do the serial numbers look like they belong to that part number and that customer? Is there a date range that reads like production rather than a demo? Are the units present, or implied and forgotten? And are there any failures in the file at all?

That last one is the interesting one. A file where every row passes tells you one of two things: either the export was filtered on the way out, or the station does not log failures. Both are answers, and both are worth a follow-up question before award. I have also received a file from a different product line, offered as representative of what I would get. That is an answer too.

If the file cannot be produced within a day or two, treat the delay as data. It usually means the records live on a local drive, in a folder with someone's initials on it, and that they get cleaned up periodically.

Equipment, calibration, and the question nobody expects

Ask for the test equipment identifier, the calibration interval, the last calibration date, and the software revision of the test program. Those are easy and most suppliers have them on hand.

Then ask how they prove the station itself can fail. A known-bad reference unit run at the start of a shift, a golden pack, a simulator that injects an out-of-limit value, something. If no one has ever challenged that station with a pack that should fail, the green box is a statement about the tester's wiring, not about the pack.

Tie this back to firmware as well. The test verifies a pack built to a specific specification revision with a specific BMS firmware revision. Ask what happens when the firmware rev changes: does the test program get re-verified, do any limits move, and who signs off on the change before the first pack runs against it. Suppliers who have thought about this answer in one sentence. Suppliers who have not answer with a pause.

Scoring bids so the test cost is comparable

In a weighted evaluation, EOL testing needs its own line in the cost model, separate from assembly labor and separate from any other test charge. If it is folded into a general test line, you cannot compare anything: a low test charge attached to a forty-second check and a higher one attached to a full functional sequence will look like a price difference when it is actually a scope difference.

I score the data deliverable separately too. Given two bids, I would rather carry a somewhat higher test cost attached to a controlled station, a stated limit set, and a real record export than a lower one attached to a screenshot. The second option is cheaper right up to the first field return you cannot investigate.

The line item that should make you stop

A single word — test — with no parameters, no limits, no record description, and no sample file, on a program where the pack has a BMS and a CAN interface, usually means the supplier's EOL process is a ship check tuned to get product out the door. Sometimes that is genuinely all the program needs. But you should be the one deciding that, in the RFQ, rather than discovering it during a PPAP review.

None of this is free. Requiring a sample data file, a failure path, and a field list adds a week to the bid cycle, and it costs the supplier engineering time that will show up somewhere in the price. On a low-volume, high-mix program, a fully MES-integrated record with forty fields can be out of proportion to what you are buying, and a locked spreadsheet with a signed traveler may be the right answer.

The point of putting it in the RFQ is that you get to choose which one you are buying. The alternative is finding out at the audit, when the green box is already on the screen and the program is already awarded.