ATE Test Systems

An automated test system is specified from the requirement rather than assembled from a catalogue. What you are testing, what you have to prove, and how fast you have to prove it determine the architecture — and those three answers rarely point at the same hardware twice.

Intepro builds these as integrated racks: source, load, measurement, switching, fixturing and the test executive that drives them, delivered against an agreed acceptance procedure.

The term covers a wide range. At one end, automated test equipment is a bench instrument running a stored sequence. At the other it is a cabinet installation that takes a unit from a conveyor, powers it through a qualification profile, records every reading against a limit, and hands back a pass or a fail with the evidence attached. What makes both ATE is that the sequence, the limits and the record are defined once and executed identically every time — the point is repeatability, not automation for its own sake.

For power electronics the architecture is shaped by one thing that does not apply elsewhere: the system has to both supply and absorb real energy. A source drives the unit under test, a load absorbs its output, and above a few kilowatts the question of where that absorbed energy goes stops being academic. Dissipate it and you have bought a cooling problem and a standing electricity bill; regenerate it and you have returned it to the supply. That single decision drives the room, the ventilation, the switchgear and the running cost more than the instrument choice does.

Four things decide whether a system earns its cost, and only one of them is the hardware. Channel count sets the calendar, because a queue of units through a fixed sequence is a throughput problem rather than a power problem. The test executive decides whether the system survives its own instruments reaching end of life. Fixturing decides how much of the cycle time is a person connecting things. And the acceptance procedure decides whether delivery is an event or a negotiation.

The make-or-buy question usually turns on the second of those. Assembling instruments is not difficult; writing, validating and then maintaining a decade of programme-specific sequences, limits and operator flows is where the real cost sits, and it is the part that does not appear in a bill of materials.