Custom Automated Test Equipment Design Requirements:
What’s most important to get right and what you don’t need to worry as much about

Specifying design requirements for custom test equipment can be a bit frustrating.

You know what you need in your head, but you don’t feel like you have time to do a complete brain dump.  You’ve got to get back to your real job!

There’s also the aspect of what you need the automated test equipment to do immediately, versus what you’ll need and want from it in the future.

This article prioritizes the importance of design requirements from the perspective of the custom test equipment supplier, offering common examples to help you frame your thinking and get the test system development process kicked off sooner rather than later.

The list below is ranked from most important to least important (at least generally).  Priority is mainly driven by how much money it costs (as well as the calendar time required) to correct the issue if the requirement isn’t sufficient in the beginning. You’ll notice the trend from most important to get right to least important to get right generally flows from hardware-related requirements to software-related requirements.

Circuit board spin required

If your custom test equipment requires a PCB to be designed, you’ll want to pay close attention here.  PCBs are super expensive to design, between analysis, schematic capture, board layout, fab, assembly, and unit test, the NRE involved is often in the $10s of thousands just for this aspect of the custom test equipment.  So, if a board needs to be re-spun due to a missing or ill-defined requirement, the re-spin, while usually only a small fraction of the original NRE, is still significant.  There’s also likely going to be a delay in the delivery of the custom test equipment.  PCB designers are generally particularly anal/detail-oriented for good reason.  If it seems like they’re poking at some detail more than they need to, it’s not because they want to be a bother, it’s more likely because they care and recognize the implications of not being anal.

Gotchas to watch out for:

  1. Concurrent design – if the UUT is still being developed, changes to the UUT may force changes on the test equipment. This could be from a mechanical or electrical standpoint.
  2. Noise-related requirements on interface signals. Unexpected noise could require some additional filtering on the PCB.

New controller / measurement chassis required

This is pretty rare, but if it happens, it’s not fun.  Test system controllers/measurement chassis generally cost thousands or 10s of thousands of dollars.  This is a scenario where it can often make sense to give yourself a little wiggle room for your “nice to haves” or potential future expansion.

Gotchas to watch out for:

  1. A packed chassis with all module/card slots filled, requiring more channels. Make sure to clearly specify all of your I/O in detail.
  2. Tighter control loops required. Are you sure you’re specifying the highest rate you’ll need?
  3. Greater control or measurement determinism than offered by the hardware required.
  4. Max’d out processing power. How much head room will there be for future mods?

New modules needed

Different modules are intended for different types of inputs and/or outputs and various ranges and rates.

Gotchas to watch out for:

  1. What other I/O might be required if there’s a design change of the UUT? This is a challenge with concurrent design.
  2. What other test coverage might you need if the UUT either fails to perform or starts performing poorly after switching component suppliers?  You can go overboard with thinking about this too much, but you’ll want to give it a bit of thought.
  3. What if a newer version of the UUT needs some slightly different tests and you want the test system to support both versions.

Re-architecting of software needed

This is where it’s very helpful to articulate how the test system is likely to be utilized in the future.  While the first iteration of the system may suggest one approach, understanding where this is headed may push the test system designed down a different path.

Gotchas to watch out for:

  1. Adding new product lines that aren’t mentioned in the original scope that require a different set of test steps or sequencing.
  2. Wanting automated test report generation in the future.

New software function needed

We could be talking about adding in data logging, averaging some numbers, or adding in some digital filtering.  As long as the software doesn’t blow out of your hardware processor or I/O availability, this generally isn’t a huge deal and is pretty straightforward, although obviously requires additional NRE.

Gotchas to watch out for:

  1. Should you have data logging?
  2. Do you need an engineering/diagnostic screen?

GUI Design

GUI tweaks are often not a huge deal in the scheme of things, assuming the LabVIEW environment supports the feature.  Note however that, especially with plots and graphs, sometimes a desired UI user interaction is harder to implement in LabVIEW than it may seem on first blush.

Gotchas to watch out for:

  1. Obtain end-user input in the beginning to help understand the use case and level of capability expected.
  2. Account for some time to tweak the GUI after obtaining feedback from the end users.

Algorithm modifications requiring a re-compile

Sometimes algorithms need to be tweaked.  If the modification is just a refinement of the algorithm once in a blue moon, re-compiling is no big deal.  If it turns out there’s a parameter that needs to be updated on a semi-regular basis (say a couple times a year or more), it makes sense to try to see if the modification can be converted to run-time configurable vs compile-time configurable.

Gotchas to watch out for:

  1. Changes that affect FPGA resource utilization. Some changes can affect the utilization of an FPGA’s hardware resources (e.g., increasing the number of channels being filtered through an FIR).
  2. Changes to a processing algorithm or parameter might cause the time to process the data exceed the loop period required for a real-time control application.
  3. Re-verify the algorithm for all the corner cases plus any new ones caused by the new processing procedure. Don’t assume the new code will just work!

Parameter modifications requiring a config file update

This is usually the least concerning type of requirement change on a test system.  A good set of requirements will make it clear which parameters need to be updated often enough to warrant their placement in a configuration file.

Gotchas to watch out for:

  1. Make it clear which values need to be set at runtime, which are set at startup, and which are static.

Next Steps

We’ve been helping our customers develop solid design requirements for custom test equipment since 1993.  If you’d like us to help guide you through the process, reach out here for consultation.

Yes, I’d like help creating custom test equipment requirements »

If you’re in learning mode, check out these resources: