Automated Test Rack Acceptance Plan for Australian-Made Systems

In brief

An automated test rack should be released only against a written acceptance plan that proves measurements, fixtures, safety states, failure handling, traceable reports, and handover; an instrument list alone does not validate the delivered workflow.

Key takeaways

• Define the DUT, measurement limits, pass/fail logic, fixture states, software outputs, and throughput target before quotation.
• Use separate checklists for factory acceptance and on-site commissioning because they validate different conditions.
• Require a known-good run, a forced-fail run, safety-state checks, and a report that preserves measurement and configuration traceability.
• Use Australian-made wording only after a product-specific origin assessment; document Australian engineering work and export screening as separate evidence sets.

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.

Quotation readiness checkpoint

Before hardware is selected, review the scope as a complete DUT workflow. This checkpoint is earlier than FAT: it decides whether the request contains enough evidence for an engineering quotation or is still only a rack concept.

Scope area	Evidence to provide before quotation	Rework trigger
Measurement method	DUT variants, stimulus levels, limits, uncertainty assumptions, and at least one known-good plus one known-fail case	The request names instruments but not what each channel must prove
Fixture and switching	DUT drawing, connector access, switching path, contact method, interlock map, expected cycle count, and safe-unload behaviour	The fixture is treated as mechanical hardware only, with no repeatability or failed-test recovery requirement
Software workflow	Operator steps, user roles, recipe handling, report fields, export format, and exception handling	A pass/fail report cannot reproduce the test condition, instrument identities, or software version
Factory acceptance scope	Measurement sequence, safety and fixture states, calibration status, failure cases, and report export to demonstrate before delivery	The planned demonstration contains only a clean pass run and no forced-fail, emergency-stop, or communications-loss case
Site commissioning scope	Local power, network paths, accounts, file permissions, production samples, and handover training	The quotation does not identify the buyer-controlled dependencies needed for normal operation

If one of these rows is unresolved, record it as an assumption with an owner and closure gate. Hiding the gap inside an instrument allowance transfers it into software, fixture, or commissioning rework later.

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 a rack being considered for Australian-made wording, document the work performed in Australia: system architecture, rack and fixture integration planning, instrument configuration, software workflow, validation, FAT/SAT records, documentation, and accountable commercial delivery. Then conduct a separate product-specific origin assessment that identifies the last substantial making step and checks the overall impression of the proposed words and imagery. Qualified global components can be described accurately, but neither their use nor the local engineering record alone decides whether the finished rack satisfies a made-in representation.

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 a precise description of local work; a made-in claim still needs a separate origin assessment
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

Decision rule and quantitative release logic

Assign every requirement a unique identifier and classify it before FAT as release-blocking, conditionally deferrable, or informational. The acceptance summary may report coverage as accepted applicable requirements / total applicable requirements, but 100 percent of release-blocking requirements must pass. A high overall percentage must never offset an open safety, measurement, data-integrity, or forced-fail requirement.

For each numerical limit, the plan should define which result is compared with the limit and how measurement uncertainty is treated. NIST’s traceability guidance is useful here: a calibrated instrument alone does not make the final rack result traceable; the complete measurement process, calibration chain, configuration, and associated uncertainty must be documented. The JCGM guidance provides the general framework for evaluating and expressing uncertainty. The project must choose its actual decision rule rather than silently treating every displayed digit as equally certain.

For repeatability, record individual runs and vary the factors that create risk: DUT reload, fixture closure, switch route, cable remate, recipe, operator, or thermal state. Define the maximum permitted spread or failure count before testing. An average that falls inside a limit is not a pass if one run violates a release-blocking requirement.

Illustrative worked example — not a customer case

Assume a hypothetical rack must verify eight DC channels, four digital inputs, two interlocks, a barcode-to-report link, and a 90-second cycle-time target. The approved FAT contains 18 requirements: 12 measurement/workflow items, four safety and fault-recovery items, and two documentation items. The team uses a reference load for the normal run, injects one out-of-limit resistance, disconnects one programmable instrument, and opens the guard input during an inhibited state.

Seventeen requirements pass. The report-font issue is pre-classified as deferrable and receives an owner and closure date; all release-blocking items pass. Three complete reload runs record 86, 88, and 87 seconds, so the cycle-time requirement passes without averaging away an over-target run. The evidence package retains each raw result, the fixture and software revisions, instrument identities, limit-table checksum, event log, and signed disposition.

This example demonstrates a decision method only. It is not a real customer project, an XGY Tek FAT record, proof of a product capability, or a recommended universal sample count. Real limits, uncertainty treatment, run count, and safety tests must be set from the verified DUT and intended use.

Product fit

Where XGY Tek fits

XGY Tek can scope an automated test system together with its control software and custom fixtures when the DUT, measurement sequence, safety states, report fields, and acceptance gates are defined. The final architecture depends on the validated project requirements.

Product family

Automated Test Systems

Custom automated test systems scoped around the DUT, measurement sequence, fixture interface, safety states, reporting requirements, and acceptance evidence.

View product

Product family

Software Control & Reporting Interfaces

Custom software control and reporting interfaces for instrument sequencing, operator workflow, traceable data capture, pass/fail logic, dashboards, and test-system handover.

View product

Product family

Test Fixtures

Custom test fixtures scoped around DUT geometry, contact method, RF or power path, safety interlocks, operator workflow, cycle life, and acceptance evidence.

View product

FAQ

Frequently asked questions

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.

When is a custom automated rack the wrong answer?

A custom rack is usually premature when the test method is still unstable, the DUT interface changes frequently, or the work is occasional engineering characterization. A flexible manual or semi-automated bench can reduce fixture and software rework until the measurement method and release criteria are stable.

Can an automated rack be described as Australian-made?

Only after a product-specific country-of-origin assessment supports the made-in representation and its overall impression. Australian engineering, integration, validation, documentation, and accountable delivery records are relevant, but do not by themselves establish that the finished rack was last substantially transformed in Australia.

Keep exploring

Related technical resources

Related articles

Technical Article

Custom Test Fixture Scoping Before Quotation

What engineering teams should provide before requesting a custom RF, power, semiconductor, or electronics test fixture quote.

Read article

Procurement Checklist

Semiconductor Test Fixture Validation Checklist

A semiconductor test fixture validation checklist covering probe access, SMU paths, RF cables, thermal conditions, repeatability, reports, and acceptance evidence.

Read article

Procurement Checklist

RF Test Equipment RFQ Checklist for Global Buyers

A practical RFQ checklist for RF test equipment buyers covering frequency range, bandwidth, power, calibration, fixtures, acceptance evidence, and export screening.

Read article