An Australian-made automated test rack should be purchased with an acceptance plan, not only an instrument list. The instrument list says what hardware is included; the acceptance plan says what the delivered system must prove before it is released into production, validation, or compliance work. In the first review, define at least 5 hard fields: channel count, voltage/current or frequency range, fixture state, software/report output, and FAT/SAT pass/fail criteria. For engineering teams, that distinction prevents a common problem: a rack can contain the right instruments but still fail the real workflow because fixture loading, safety interlocks, reporting, calibration records, export documentation, or operator steps were never defined. A useful acceptance plan reads less like a brochure and more like a release gate.
Start with the device under test
The first section of the acceptance plan should describe the device under test, the measurement points, the expected operating conditions, and the pass/fail logic. A useful brief names the product family, sample variants, connector types, power levels, RF ports, environmental conditions, and any limits that must be applied by serial number or configuration. If the DUT changes across production batches, the plan should state whether the rack needs recipe handling, operator prompts, barcode capture, or product-specific limits.
This is also where engineering should identify what is genuinely measured and what is only checked for presence or continuity. A fixture may confirm that a DUT is seated correctly, while a spectrum analyzer, VNA, source measure unit, programmable supply, or electronic load performs the actual measurement. Separating these responsibilities makes the factory acceptance test easier to write and easier to audit later.
Define measurements, limits, and uncertainty
The acceptance plan should list each measurement step with the stimulus, expected response, tolerances, and unit of record. For RF systems, this may include frequency range, output level, path loss, S-parameters, harmonic checks, modulation settings, or switching states. For power systems, it may include voltage/current profiles, sink/source behavior, transient steps, protection thresholds, and thermal or safety constraints.
Where calibration matters, the plan should identify which instruments require current certificates, which fixture paths need compensation, and whether any reference devices are used during acceptance. Teams working under quality systems often need traceability, calibration dates, instrument serial numbers, software versions, and environmental conditions captured in the report. Defining those fields before purchase is much easier than adding them after operators have started using the rack.
Include fixtures and switching in acceptance
Fixtures and switching are often where automated systems become fragile. A rack can pass a software dry run but fail once a real DUT is loaded because the connector access is tight, the interlock sequence is unclear, or the RF/power path changes under movement. For that reason, the factory acceptance test should include the fixture behavior, cable strain relief, switching map, interlock states, emergency-stop response, and any required load or termination conditions.
For high-voltage, high-current, RF, or mmWave benches, acceptance should also cover operator safety and repeatability. That can include checking that shield doors, grounding points, discharge delays, and warning states behave as expected. It can also include repeated load/unload cycles to confirm the fixture produces stable measurements rather than a single good run.
Specify software outputs before the rack is built
Automated racks are usually judged by the reports they produce. Before quotation, define whether the system must output CSV, PDF, database rows, dashboard views, screenshots, raw instrument logs, or operator sign-off records. The report should include the DUT identifier, test recipe, date/time, operator, station ID, instrument IDs, software version, calibration status, pass/fail result, and measured values.
If the rack needs to integrate with MES, PLM, ERP, or a local file server, that should be part of the scope. Even a simple folder export can become a support issue if naming rules, retry behavior, permissions, and network availability are not agreed in advance. The acceptance plan should include at least one sample report and one sample failed test so the buyer can see how exceptions will be handled.
Separate factory acceptance from commissioning
Factory acceptance testing confirms that the rack meets the agreed scope before shipment or delivery. Commissioning confirms that the rack works at the customer’s site with local power, network, operators, fixtures, and production samples. These are different events and should be documented separately.
A practical split is to verify the measurement sequence, safety functions, fixture operation, data capture, and sample reports during factory acceptance. During commissioning, confirm installation, operator workflow, local data paths, user roles, handover training, and any site-specific limits. This separation helps purchasing understand what is included, helps engineering avoid scope creep, and helps operators receive a system that matches the real workflow.
Release gate checklist
The acceptance file should define what blocks release. Without explicit rejection criteria, a rack can be accepted because it technically runs a sequence even though operators cannot safely or repeatably use it. Use the release gate below as a starting point.
| Gate | Pass condition | Release should be blocked when |
|---|---|---|
| Measurement method | Known-good DUT produces expected values within agreed limits | Values pass only after manual adjustment, hidden offsets, or undocumented operator intervention |
| Negative test | Known-bad or forced-fail condition produces the expected failure record | Software reports pass, blank, or ambiguous output after a forced failure |
| Fixture operation | Loading, clamping, interlock, and unload steps are repeatable | Contacts shift, operators can bypass required states, or fixture wear is not visible |
| Safety state | E-stop, door, discharge, over-limit, and communication-loss states behave as documented | The rack leaves a DUT energized, hides an interlock fault, or requires unsafe manual recovery |
| Report traceability | Report links DUT ID, recipe, limits, measured values, station, software, instrument IDs, and calibration status | A result cannot be reproduced from the report and acceptance file |
| Handover | Operators can run, stop, recover, export, and explain the test using the handover procedure | The supplier engineer is still required for normal operation |
The most important line is the negative test. A system that only demonstrates a good run has not proven its failure handling. For production, compliance, and supplier qualification, the failure record is often more important than the pass record because it determines whether bad units are contained or silently escape.
Standards context for the acceptance file
The standards context should be visible in the acceptance plan. SCPI matters because a mixed-vendor rack is only maintainable if commands, error handling, setup recall, and status polling are documented instead of hidden inside a one-off script. PXI/PXIe matters because modular racks often depend on chassis timing, trigger routing, module slot planning, and shared control software rather than independent bench instruments. ISO/IEC 17025 matters when measurement evidence needs traceability, calibration status, uncertainty awareness, and records that can survive a quality review.
For an XGY automated test system, that means the acceptance document should include the command/control boundary, the PXIe or instrument topology, the fixture I/O map, the calibration certificate list, and a report sample that proves traceability fields are captured. The document should answer three questions without a follow-up meeting: which hardware made the measurement, which software version and recipe ran it, and what evidence proves the result was produced under the agreed conditions.
The same acceptance document should carry hard numerical boundaries. Identify whether the build is a 19-inch rack or bench station, list the SCPI / PXIe / fixture interfaces, record the target cycle time in seconds, define at least 1 known-good run and 1 forced-fail run, and require at least 11 fields in the report: DUT ID, station ID, recipe, operator, date/time, software version, instrument IDs, calibration status, measured values, limits, and pass/fail result. If the rack handles RF or power paths, add the highest frequency in Hz/GHz, maximum voltage in V, maximum current in A, and the interlock or discharge state that blocks unsafe unload.
The acceptance file should be version controlled or at least revision controlled. If limits, recipes, fixture wiring, calibration intervals, or report formats change after commissioning, the revision history should show who approved the change and what evidence was rerun. That discipline is not bureaucracy; it is how a test rack remains defensible after the first production issue, customer return, or quality audit.
Australian-made and export evidence
For eligible XGY Tek racks, the Australian-made claim should be tied to documented work performed in Australia: system architecture, rack and fixture integration planning, instrument configuration, software workflow, validation, FAT/SAT records, documentation, and accountable commercial delivery. Qualified global components can be used where they fit the requirement, but the public claim should not imply 100 percent Australian components unless the internal record supports that stronger claim.
Export projects need one extra gate before order release. Record destination, end user, end use, technical scope, documentation language, delivery terms, and any customer compliance requirements. The quote should state that supply is subject to export screening rather than promising availability for every country or every use case. That language is not a sales weakness; it is how serious engineering suppliers keep procurement, compliance, and delivery aligned.
| Export and origin item | What the rack file should show | Why it matters |
|---|---|---|
| Australian engineering scope | Architecture notes, integration plan, software workflow, FAT/SAT method | Supports precise Australian-made wording |
| Component position | Qualified global components selected against the rack requirement | Avoids unsupported component-origin claims |
| Export destination | Destination, consignee, end user, and end use before order release | Prevents compliance review after build completion |
| Delivery documentation | Packing, configuration, report, and handover records | Helps the receiving team inspect and accept the rack |
| Change control | Revision log for post-FAT changes | Shows what must be retested before shipment or commissioning |
Engineering FAQ
What is the minimum acceptance evidence for an automated test rack?
The minimum evidence is one complete run with a known-good DUT, one run that exercises a known failure or forced limit, the exported report, the instrument and software version list, and proof that safety states work. For RF, power, semiconductor, or high-voltage systems, the acceptance file should also include the fixture path, calibration state, interlock behavior, and any reference device used during the check.
Should factory acceptance and on-site commissioning use the same checklist?
They should share the same measurement logic but remain separate checklists. Factory acceptance should prove the agreed rack design, measurement sequence, fixtures, reports, and safety functions before delivery. On-site commissioning should prove local power, network paths, operator accounts, barcode or MES connection, environmental conditions, and training at the buyer’s facility.
When is an automated rack not ready for quotation?
The rack is not ready for quotation if the DUT variants, pass/fail limits, report fields, safety states, fixture concept, and throughput target are still undefined. In that condition, a supplier can quote hardware, but the project risk remains hidden in software behavior, operator workflow, and acceptance disputes.
What fields should appear in the final rack report?
A useful report records DUT ID, station ID, recipe, operator, date/time, software version, instrument IDs, calibration status, measured values, limits, pass/fail result, and fault or retest notes. If the data supports production release or quality review, those fields are not optional decoration; they are the audit trail.
Can an automated rack be described as Australian-made?
Yes, but only when the records support it. The rack file should show Australian engineering, integration, validation, documentation, and accountable delivery. Use qualified global components wording for parts unless stronger component-origin claims are supported.
Quotation package
For an automated test rack quote, share the DUT description, drawings or connector details, required measurements, pass/fail limits, target throughput, safety constraints, preferred instruments, software stack, report examples, calibration requirements, and handover expectations. If the project includes a custom fixture or control interface, include those details in the same package rather than treating them as separate afterthoughts.
XGY Tek scopes automated test systems, fixtures, and control interfaces around production and validation workflows. The most useful conversations happen before the rack is designed, when acceptance criteria, data fields, commissioning steps, and operator training can still be designed into the system rather than patched on later.