Direct Answer
How should motor test data and acceptance be planned?
Plan motor test data by linking every requirement to DUT identity, setup, command sequence, timestamped raw channels, calculation definitions, versions, decision outputs, exceptions, reports and an agreed verification stage. Separate design review, supplier verification, factory review, site review and final handover. For each applicable stage, define the available DUT and utilities, method, condition, tolerance, evidence, witness, punch-list, retest and sign-off owner.
Data Record
Eight field groups that keep motor test evidence traceable.
| Field group | What the record should preserve |
|---|---|
| DUT identity | Model, variant, drawing and revision, serial or sample ID, included controller and feedback, fixture and setup revision. |
| Test context | Requirement ID, procedure and revision, operator or automation source, date/time, site, environment and relevant preconditions. |
| Command and sequence | Commanded state, setpoints, ramps, dwell, cycle, direction, repeats, limits, recipe and software version. |
| Raw measurements | Channel name, plane/location, timestamp, unit, range context, status and original recorded value. |
| Processing and calculations | Formula, constants, synchronization, filtering, interpolation, averaging, invalid-data rules and calculation version. |
| Decision outputs | Curves, maps, limits, pass/fail, engineering observations, comparison references and the decision each output supports. |
| Exceptions and retests | Alarm, interruption, missing channel, invalid condition, deviation, disposition, retest link and retained original record. |
| Report and export | Human-readable report, raw and processed export, file naming, language, template version, database link and retention. |
Verification Stages
Keep design review, factory review, site review and handover separate.
| Stage | Planning boundary |
|---|---|
| Requirement and design review | Confirm the DUT, method, data definitions, interfaces, responsibilities, open items and intended evidence before release. |
| Supplier internal verification | Check configured functions and records against the agreed design baseline; this is not buyer acceptance unless contractually defined. |
| Factory review or FAT | If applicable, define available DUT, utilities, conditions, witness, method, tolerance, record, exceptions and shipment-release decision. |
| Site review or SAT | If applicable, define installed interfaces, site utilities, production context, method, evidence, punch-list and sign-off responsibilities. |
| Final handover | Confirm documents, software/configuration, records, training, open items, changes, backups and the contractual acceptance owner. |
Acceptance Challenge
Questions to ask before approving the evidence plan.
- Can every reported value be traced to a DUT, setup, sequence, raw channel, formula and software or method version?
- Are torque, speed, power, electrical and thermal channels defined by location, units, timing and calculation meaning rather than by label alone?
- Are invalid runs, missing data, alarms, interruptions, manual edits and retests retained and linked instead of silently replaced?
- Do report limits and pass/fail rules identify the requirement revision, condition, tolerance source and owner?
- Are factory review, site review and final acceptance separated with their own available DUT, utilities, method, evidence and sign-off responsibility?
- Do photographs, component datasheets and generic demonstrations remain supporting context rather than proof of complete-system performance or acceptance?
Weiheng Data Traceability Plan v1.0
Preserve a reviewable path from the reported result back to the source run.
A report is not traceable when the underlying run, raw channels, processing version, exceptions or approval state can be silently replaced. Weiheng records released methods and permissions separately from execution, processing and approval so each result can be followed backward to source evidence and forward to its decision.
| Lineage layer | Minimum controlled record |
|---|---|
| Released method | Requirement ID, method/recipe ID, revision, owner, approval state and effective date |
| System configuration | Bench, fixture, controller, firmware, software, channel passport and permission baseline |
| Source evidence | Immutable raw-channel reference, timestamps, units, quality flags, event markers and original run identity |
| Processing | Calculation version, formula, filters, resampling, exclusions, generated dataset and report-template version |
| Change and exception | Old/new value, reason, user, time, affected requirements, override, invalid run, deviation and linked retest |
Open the combined Thermal, Durability and Data Traceability Plan v1.0.
Weiheng FAT/SAT and Measurement Acceptance Matrix v1.0
Assign every requirement to one method, condition, evidence record, owner, and sign-off stage.
R&D characterization, EOL screening, FAT, SAT and production release answer different questions. A controlled acceptance row names the DUT and boundary, method and condition, measurement chain, tolerance and uncertainty decision rule, evidence, responsibility, exception route and authorized sign-off. Silence is not compliance, and remote commissioning does not automatically replace SAT.
| Stage | Required evidence focus | Boundary |
|---|---|---|
| R&D characterization | Declared DUT, operating conditions and synchronized evidence | Characterization only; not every-unit release |
| EOL screening | Released sequence, unit identity, result, exception and disposition | Routine release method; not full design validation |
| FAT | Factory configuration, agreed samples/utilities, methods, evidence, deviations, punch list and witness | Factory scope only; not buyer-site installation |
| SAT / commissioning | Delivered configuration, site utilities/interfaces, agreed runs, training, open items and sign-off | Site scope only; excluded requirements remain excluded |
| Production release | Approved routine method, trained roles, reference checks, permissions, backup, change control and escalation | Controlled baseline; not permanent capability after uncontrolled change |
Open the printable FAT/SAT and Measurement Acceptance Decision Matrix v1.0.
Related Planning
Connect data requirements to the equipment and RFQ.
Use the Motor End-of-Line Test System for production recipes, pass/fail and traceability context. Use the Motor Test Bench RFQ Checklist to assign requirement IDs, statuses and supplier responses. For system architecture, continue to the Custom Motor Test Bench Configuration Guide; for pump projects, use the Pump Motor Test Plan and RFQ Checklist.
FAQ
Motor Test Data and Acceptance Questions
What motor test data should a test system record?
Record DUT and setup identity, requirement and method revision, commands and sequence, timestamped raw channels, calculation definitions, curves or limits, exceptions and retests, software or recipe version, reports, exports and sign-off context. Exact fields remain project-specific.
Why should raw and calculated data be separated?
Raw data preserves the original measurement record. Calculated data depends on formulas, constants, synchronization, filters and software versions. Keeping them linked but distinct makes reviews, corrections and comparisons traceable.
How should invalid motor test runs be handled?
Retain the original record, identify why it is invalid, record alarms or missing conditions, assign a disposition, and link any retest. Do not silently overwrite the failed or interrupted run.
Are FAT and SAT the same as final acceptance?
Not necessarily. They are distinct verification stages when included in the contract. Each needs its own scope, available DUT and utilities, method, tolerance, evidence, witness, punch-list, retest and sign-off responsibilities.
Can acceptance criteria be finalized after equipment delivery?
Some details may remain open early, but the decision logic, responsibilities and resolution stages should be visible before award. Leaving all criteria until delivery creates avoidable scope and evidence disputes.
Does a test-system photograph prove accuracy or acceptance?
No. A photograph can support visible physical integration. Accuracy, repeatability, functionality, standards and acceptance require agreed definitions, methods and project-specific records.