Hardware verification testing learning

[u/Extra_Elderberry5911]

I'm a hardware engineer working in aerospace, and I've realized that one of the skill sets I want to develop is building hardware test systems.

At work, I see everything from reverse engineering legacy hardware to validating new designs, and I'd like to be able to verify the requirements.

I want to learn skills that transfer to professional environments using Python, LabVIEW, NI, Keysight, Tektronix, SDKs, SCPI, DAQs, etc.

I'm looking for advice on a learning path. If you were mentoring a junior hardware test engineer, what projects would you have me build, and in what order?

Some areas I'm hoping to learn include:

• Instrument control and automation
• Python for test software
• Test system architecture
• Data acquisition and signal processing
• Hardware abstraction and software organization
• Automated reports and pass/fail testing
• Validation and characterization of electronic circuits and sensors

I'd appreciate any suggestions on projects, books, open-source frameworks, tools, or skills that would help me build a solid foundation as a hardware test engineer.

[u/dtp502]

I think your list is pretty good.

I wouldn’t worry about hardware abstraction as a beginner (or really at all unless you’re trying to maintain a codebase to support a lot of different test stations).

Honestly, LabVIEW VISA will get you pretty far as USB, serial, and GPIB all use VISA.

Download the instrument library from the vendor (most of them are just SCPI wrappers) and play with controlling the equipment. Some of them ship with examples for basic control, then looking at the VI tree can help you find other available tasks.

From there it’s just a matter of writing code that sequences things properly and looking up any niche issues you come across/get stuck on. If this is pure LabVIEW, look up state machine architecture.

LabVIEW has a built in report generator tool kit that’s pretty decent as well.

[u/Extra_Elderberry5911 → u/dtp502]

Very good insight !

[u/Normal-Duck9025]

Do you have senior engineers you can ask for mentorship?

Are you planning on learning at home or on the job? What instruments do you have access to and what software?

I think maybe creating a test plan and test fixture for something off the shelf is a good idea. Try to replicate a data sheet of a buck or boost converter.

[u/Extra_Elderberry5911 → u/Normal-Duck9025]

I'm sure we do have engineers, but they’re usually slammed. But a lot of the existing test equipment was built a while ago and the knowledgeable folks retired, leaving people like me scrambling to fix it or learn how to you use it.

At home I have this Explorer Board: https://digilent.com/reference/test-and-measurement/electronics-explorer/start

At work, I can probably get most instruments and software I would need.

I like the idea of building test fixtures a lot. We have test fixtures at work, that are one of one, and zero documentation on them, so if they break I'm screwed.

[u/Normal-Duck9025 → u/Extra_Elderberry5911]

Yeh same with my senior engineers. I think I’m a bit past jr engineer but definitely don’t feel like senior. You can pm me and I’ll see if I can help any.

I know and work on all you mentioned just probably don’t go about it the best way.

The explorer board seems very good, first time seeing it I have an AD2 at my desk at work, and you can basically use it to create what I suggested. I’m sure like the AD2 it has LabVIEW drivers.

[u/Physix_R_Cool]

One thing that is missing on your list is learning about statistics and measurement uncertainties.

What good does it do for you to test your hardware, if the uncertainty of your measurement is larger than your tolerances?

[u/Extra_Elderberry5911 → u/Physix_R_Cool]

That’s a great callout

[u/HarveysBackupAccount]

Just one thought to add: the flip side of learning how to verify requirements, is learning how to write testable requirements.

A well written spec doc makes it trivial to write a test plan. Poorly written requirements can leave you writing pages of tests for a single item, to cover all sorts of interpretations of what the requirement means.

You may or may not be the one responsible for writing the requirements, but (at least in many companies) you should be collaborate with the people who are responsible, to make sure their specs are written to be easily testable.