DVT Automated Test System

Design verification testing (DVT) is the gauntlet every power supply goes through before production. At TDK-Lambda, engineers were running these tests partly by hand: cycling units through temperature extremes (-40°C to +85°C), measuring efficiency, ripple and noise, load regulation, harmonics, inrush current, hold-up time, OCP characteristics, and dozens more parameters. A full DVT run could take the better part of a day, tying up both the test bench and the engineer.

I designed and built the system that automated the whole thing. Configure the product, set it running, come back tomorrow to a complete report. The experience of building this production system, and watching how engineers used it, is what later inspired the py-dvt-ate simulation platform.

The system controlled a full bench of instruments from over 15 manufacturers: Chroma AC sources, Kikusui and Chroma electronic loads, Lecroy and Rohde & Schwarz oscilloscopes, Vitrek power analysers, Thermotron and Espec thermal chambers, and others. Every manufacturer speaks a slightly different SCPI dialect, so I built a unified driver layer over VISA that abstracted the differences. Test code talked to clean interfaces, not raw SCPI strings with manufacturer-specific quirks baked in.

Where commercial instruments didn't exist for what we needed, I designed custom ones. Hold-up time tests required switching high-capacitance loads, and nothing on the market did this, so I built a USB-controlled capacitive load bank switch that started as an Arduino prototype and ended up as a production PCB.

Tests were plain VB.NET classes decorated with custom attributes. The framework discovered them via reflection at startup, no registration needed. It read each test's attribute metadata to determine which instruments and conditions were required, then wired everything up automatically.

Execution followed the natural structure of a DVT run: iterate through temperature groups, run each test within a group, step through every generated condition within each test. A cooperative abort mechanism let engineers safely stop a multi-hour run at any point, putting all instruments into a safe state before shutting down. That abort mechanism was unglamorous but critical; when you're driving a 3kW load at -40°C, you can't just kill the process.

This was the key to scaling across product families. Test conditions were defined as axes in XML (line voltages, load percentages, temperature points), and the framework generated the full test matrix via Cartesian product. Symbolic values like 'MinimumLineVoltage' or 'MaximumLoadCurrent' resolved against the actual product specification at runtime. The same test definition worked for a 100W single-output and a 600W quad-output without any code changes.

Multi-output power supplies have complex power budgets. A quad-output supply might have a 600W total converter limit, individual module limits of 200W each, and per-output maximums that depend on what the other outputs are drawing. The software modelled this three-level hierarchy (converter, module, per-output) and automatically distributed load across parallel electronic load channels, respecting all constraints simultaneously.

Getting this right meant the system could test worst-case load combinations that engineers would struggle to set up manually. The maths had to match what the hardware actually does; getting it wrong meant either under-testing the product or tripping protection circuits and halting the run.

After a run, the system generated reports with oscilloscope waveform captures, measurement charts, and pass/fail verdicts against specification limits. I built this on a format-agnostic element model: the report was composed as abstract elements (tables, charts, images), then rendered to Word, PDF, or HTML depending on what the engineer needed. This separation meant adding a new output format never touched the test or measurement code.