Custom Manufacturing Test Systems – How to Get the Most Bang for Your Buck on a Budget

Engineers can find themselves caught between (1) their budget and (2) their desire to get the project done right.

If you’re planning on working with a system integrator to develop a manufacturing test system and you’re looking for ways to get the most bang for your buck on a budget, this guide will get you well on your way.   At Viewpoint we often make suggestions to our customers to help make their project more budget friendly. These suggestions can help you reduce the cost of your test system by ~10-40%.

There are 4 main dimensions available to trade off:

Available Tradeoff Dimensions:
Reducing functionality
Shifting less specialized work internally
Increasing risk (for the customer or the integrator)
Increasing efficiency

Note: For the purposes of this guide, we’re treating all customer labor as “free” because often times customers value dollars out the door much more than their internal labor. We don’t necessarily think this is the optimal view, but we work within that reality. We think a more holistic approach would be to consider fully loaded internal labor costs balanced against each company’s core competencies and personnel availability/loading.

Some tips on how to get the most bang for your buck:

Leverage existing tools (that you may not know about) by being a little curious and a little flexible

Test management software provides easy test sequencing, integrated report publishing, operator interfaces, and test user management. They’re especially useful in manufacturing environments where a lot of common features are found between different test stations. In manufacturing environments, test management software can be set up to automatically select the correct test sequence when a part number/model is entered.

  1. National Instruments TestStand is the industry standard in test management software.
  2. Viewpoint’s StepWise is a test executive that is designed for a low-volume production environment.
  3. Utilizing features within National Instruments Measurement & Automation Explorer (NI MAX) when working with NI DAQ systems cuts down development time and adds flexibility to a test application.
  4. When it comes to generating reports within your application, leveraging a helper tool like Viewpoint’s DocX Toolkit can save development time and create professional reports.

“Recently we worked with a research group that needed a flexible data logger capable of accommodating a wide range of measurement types, durations, and frequencies. By using NI MAX to create data acquisition ‘tasks’, we provided them with the ability to customize their data acquisition settings within the limits of NI MAX tasks and execute them within an application, which logged the data and displayed results. Providing the interface to setup and validate all the input parameters that NI MAX accommodates within the scope of this project would have made development time take 3 times as long, providing an extreme cost savings of 67%.”

What to do: Get curious (and a little flexible) and ask your system integrator if there are changes that can be made to the requirements to be able to leverage existing tools.
How it saves: Reduces development time and decreases project risk. You’ll obviously need to pay for any licenses. If this tool can be used for multiple projects on the same license, then the savings can multiply.
Amount you could save: In many cases, leveraging an existing tool can save 30-40% of development time.

The Manual Test Panel – when adding features can save you money

Getting the best value doesn’t necessarily mean eliminating all non-core features. We often find situations where a small amount of development time can greatly improve the utility of the work we are already doing, in ways that save money in the long run. For manufacturing test systems, adding a manual test panel for troubleshooting can add a lot of value when you consider the amount of time that can be saved with the utility. We have seen engineering, quality, and manufacturing groups make use of this type of feature because it allows them to manually run isolated tests on a unit.

What to do: Add a test panel to your application for debug purposes.
How it saves: In order to improve the operator experience for a test system, you generally want to minimize the information displayed and minimize the flexibility of the tester, because you want to minimize the opportunity for mistakes. This is in direct conflict with the objective of a debug panel. A debug panel helps you do things like run partial test sequences and provides you with detailed intermediate data so that you can hone in on the location and cause of the bug faster.
Amount you could save:

Consider the potential time saved in the long run. A test panel could save hours per defective unit in troubleshoot time, or even 1-2 days per build when validating new hardware or software builds. Depending on the product lifecycle, the extra ~5-10 days of effort could save tens of thousands of dollars.

The (slightly) Bare-Bones UI

“One of the first questions I ask a customer when I’m quoting a project is who will be using the application. Why? Because I want to understand what the expected user interaction with the application is.”

User interfaces typically include access to test setup, station configuration, and test results. In some applications it is appropriate to create a more complicated user interface with access to all station configuration aspects – what lines contain what signals, instrument address, scaling of the output signal, etc. However, in many applications those parameters are seldom changed – perhaps only if an instrument is replaced. If an advanced user with extensive knowledge is always making those changes it is usually more appropriate to hide those parameters from the user interface and utilize a station configuration file. A station configuration file is faster to implement and it simplifies the user interaction at run time, which is a win-win for project budgets.

What to do: Simplify your user interface by utilizing text based configuration files.
How it saves: Less user interaction means less software to develop. Assuming only knowledgeable people will be touching configuration files saves in documentation and software checks.
Amount you could save:

It could take a week or more to create a complex user interface. A simple user interface can be done in about a day.

How Concurrent Development can cost you

How many times have you heard someone say “do you want the job done right or fast?” It may be cliché, but timelines play a part in an engineering budget. By setting realistic expectations and having conversations about schedule, overall budget can be decreased.
A common situation we face at Viewpoint is concurrent development of the product and the test system that will test that product. Concurrent development can be a helpful strategy when an aggressive schedule is unavoidable, however, it is a perfect catalyst for scope changes, TBDs, and pauses in work.

What to do: Avoid situations where the system integrator’s work is dependent on progress made by other parties. Instead, engage the system integrator as a consultant to assist in planning for their phase of the project.
How it saves: Allows the system integrator to have all of their requirements up front. This can avoid scope changes and inefficiencies created by work stoppages (which often occur when the integrator is missing information). Having the system integrator involved in the planning phase allows them to provide input in situations that will speed up their development time and provides them with necessary background knowledge when their phase begins.
Amount you could save:

Scope changes can increase development time by anything in the range of 5-50%.

“One example of the fallout of concurrent development at Viewpoint occurred when a customer engaged Viewpoint in the development of the control software for a large system. When the purchase order was issued the major components of the system were defined, but specific equipment and controllers were not. The customer agreed to provide us with the specific details of the system as soon as possible, but design obstacles ended up getting in the way and they could not provide us the information as quickly as we needed it. The gaps in information about how the components would be interfaced with led to an eventual work stoppage and a multiple month delay in the project. Additionally, this meant that later in development critical details of the control system were being discovered, expanding the complexity of pieces that we initially thought would be ‘simple’. If we had more of the details up front, we would have had a better understanding of the full scope of each feature and could have more efficiently implemented each item.”

Sometimes a Phased Approach can save you money within a fiscal year

When facing a situation where all the features cannot be implemented within the current timeline or budget, a phased function rollout may be an appropriate solution. A phased function rollout is where a plan is developed to deliver an initial basic application, followed by additional rollouts with added features. At Viewpoint, we often suggest phased rollouts when the customer has a set budget for their current fiscal year or when one test system is initially needed but over time more will be added.

What to do: Structure the development into a 2-phase approach, and only tackle phase 1 this year.
How it saves: Understanding the core elements that are key to your test system vs nice-to-haves for the long run won’t necessarily save you from a total test system cost standpoint, but if you’ve already got a set budget for the current fiscal year, it can help you get up and running and allow you to add in additional capability next year.
Amount you could save:

In many cases, only ~75% of the desired features are core functionality needed right away, meaning that the other 25% can be saved for future phases of development. Of course, the amount saved in the short term depends on the specific scenario. For example, saving detailed error logging and automatic database logging for a future phase could cut down phase one development time by ~5-7 weeks.

Create Well-Defined Requirements and Specifications

Yeah … Writing requirements isn’t exactly high on most peoples’ list of favorite activities (including ours). But we all know there’s a reason requirements are mentioned in every software development methodology, design process model, and engineering design manifesto that has existed. Planning is a critical step in the engineering process, and when details get overlooked during planning they usually come back as unexpected issues.
Another advantage to putting time into requirements is that it improves relationships between the customer and system integrator. It can be costly and time consuming for the integrator to extract information over phone and email. In those situations, details often change or get lost. We discuss communication a little later on, but documented clear requirements are one of the best ways to improve communication with your System Integrator from the beginning.
Just to clarify: The system integrator is NOT expecting you to approach them with a fully predesigned test routine that they will just code up and ship back. What the System Integrator needs is a clear definition of what needs to be measured & tested (and how), who needs to use it, and whatever other expectations already exist for the application. If you want more help with requirements check out:

• Viewpoint Requirements Help Path selection
• Viewpoint Requirements Tip Sheet
• Viewpoint Requirements and Specification Template

What to do: Create a system requirements specification prior to requesting a quote from the system integrator.
How it saves: A clear definition of work clarifies project requirements. This can reduce miscommunications or lost details.
Amount you could save: Changes in scope of work can more than double the cost of a project.

Explore multiple Hardware Configurations

When it comes to instrument configurations often the best solution doesn’t appear until several options have been discussed. We often have conversations with manufacturing test customers about whether it is more cost effective to develop software that supports multiple instrument platforms or whether it is better to purchase new equipment to get all stations on the same platform.

In situations where specialized or expensive equipment is involved, it often ends up cheaper to support multiple hardware platforms and integrate a station configuration. However, in certain situations it can be cheaper to purchase identical test equipment for all stations, which simplifies drivers and cuts down on software development time and complexity.

What to do: Request two cost estimates – one showing software support for multiple instrument configurations and one showing software support for a single instrument configuration with new equipment being purchased.
How it saves: A single set of NI DAQ equipment is fast to develop acquisition software for. On the other hand, the cost of replacing specialized equipment can far outweigh the price of developing software.
Amount you could save:

Depending on the complexity of the instrument, it can cost ~1-6 weeks to develop and test one instrument driver. If 2 unnecessary instruments can be eliminated, that is reducing up to 12 weeks of development cost.

Putting extra research into the hardware components of a system can also pay off. Finding the most appropriate commercial off the shelf (COTS) components, or knowing when to develop a custom solution is a common situation where a system integrator can provide insight.

“At Viewpoint, we have seen cases where the savings have been astronomical – in one of our bigger projects the savings turned out to be about $1 million! Viewpoint was tasked with designing over 100 units of the same test fixture for high-volume production test of extremely precise medical device. Initially the project was quoted at approximately $2.5 million, but after some research we found that by changing one of the COTs parts to a custom board we reduced the fixture costs down to about $1.5 million, which was a 40% cost reduction.”

Shift Responsibilities – use some of your own “free” labor for documentation

Often times System Integrators are brought onboard because they possess a skill set that you don’t. Being prepared to discuss shifting responsibilities from the System Integrator to internal resources can leave extra budget for the most specialized tasks. Documentation is the most common item that falls into this category – the System Integrator will usually need to provide some training on using the application, but generating documentation yourself can be a timesaver for the integrator.

What to do: Create your own documentation.
How it saves: A system integrator’s time may come at a premium cost compared to your internal resources, or maybe you’ve got manpower to spend but not dollars. It is best to utilize your integrator for the most specialized tasks.
Amount you could save:

Depending on the complexity of the document, a user’s guide for a simple test system can take ~2 days for a really simple test system, or a more complicated test system could take ~2 weeks to create a comprehensive user’s guide.

If you need a custom manufacturing test system and want to see how we’d solve your problem, go here. Check out our test system cost estimation calculator if you’re looking for a quick-and-dirty ballpark estimation. If you’ve got some questions specific to your scenario, feel free to reach out here.