Custom Test Equipment Pricing

It’s tough buying something that doesn’t exist yet.  The unknowns can cause angst and skepticism.  Let’s provide some insight on this topic for how we generally handle pricing at Viewpoint to help alleviate some of these feelings.

How is an automated test system / custom test equipment price calculated?

The main price driver for your test system is based on a description of the problem you’re trying to solve, in the form of requirements.  This info is used to determine both functionality and performance specifications.  Here’s the general thought process we follow:

1. Type of pricing needed – The first step is to determine if you need a ROM (Rough Order Magnitude), a T&M (Time and Materials) quote, or a fixed-price quote. As you progress down the line, there’s more and more rigor required to provide a price for the test system since there is increasing amounts of risk that the test equipment supplier is being asked to accept.
2. Requirements converted into system architecture –
   1. Determine if this is a new test system to be developed, or an obsolete test system that needs to be updated.
   2. Select COTS hardware.
   3. Identify any custom hardware needs (enclosure, cabling, signal conditioning, fixturing).
   4. Identify software tools and functions.
   5. Identify any components that you would like to provide (e.g., test fixture, measurement equipment, power supply).
3. Bottom-up cost calculation – for quotes this calculation consists of a pretty detailed spreadsheet. Function-by-function estimates and component-by-component calculations of the software and hardware required to make up the system are made.
   1. Capture cost-driving software functions and use engineering judgment on time to design, develop, integrate, and test.
   2. Get pricing on COTS hardware.
   3. Create rough costed BOM for custom hardware.
   4. Get quotes from any externally supplied hardware (e.g., enclosures, cables).
   5. Add in any additional cost adders from the “what’s going to drive the cost up” section.
4. Top-down gut check – previous similar projects are often used as a sanity check comparison point.

What’s going to drive the cost up?

1. Documentation – unless explicitly requested, we usually assume that you only want the bare minimum level of documentation. This usually includes items such as a BOM and a short operator manual.  For some systems, we provide much more polished levels of these sorts of documents, such as for system design, acceptance testing, systems interfaces, and so on, but they do cost money to create of course.  It’s all about communicating expectations with each other.
2. Additional process rigor – this is for scenarios where a particular process needs to be followed that includes milestones such as PDR, CDR, TRR, and so on.
3. Level of communication – we of course plan on communicating at important points throughout the automated test system development process. Adders come into play with requests such as weekly status meetings and reports.
4. Speculated change of requirements – if during the quoting process we’re left feeling like the requirements of the automated test system is somewhat of a moving target, we may try to capture some of that anticipated change up front or switch to a Time and Materials approach, at least until the requirements are nailed down adequately.

What’s going to keep the cost down?

1. Leveraging existing functionality – This can be huge. We’re a fan of leveraging what already exists, whether it’s a software module or framework that we’ve used over and over internally, and using COTS hardware wherever possible. Likewise, if any existing hardware can be reused, it often can be, unless it’s antiquated and hard to support in a software driver.
2. Solid requirements – This is all about understanding what you really need in the end. You don’t want things you don’t need, and you don’t want to not have something that you do.  It sounds obvious, but getting it right up front takes a bit of effort together.  Since test systems include hardware and associated limitations, sometimes a specific requirement may be costly to achieve and not be a high priority. Adjustments to requirements based on early cost assessments can also reduce cost.

Next Steps

Now that you know what to expect, if you’re ready, you can reach out here to get the process started.

If you’re just poking around, check out our automated test resources for more useful info.