Using Hardware Simulation to Reduce Production ATE Design Risks and Simplify Verification Testing
When demand requires you to ramp up manufacturing, production test must follow suit. But, for most companies, floor space and budget constraints often mean increasing production test throughput is not as simple as adding more automated test equipment (ATE). This was the exact scenario one large aerospace and defense contractor was recently experiencing with its production line and ATEs for its mission-critical avionics electronic components.
This company not only needed to boost test throughput by increasing both volume and test speed, but it also needed to perform more sophisticated testing since its newer electronic components were feature- rich and more complex. Some of the challenging requirements for their new production ATE included testing 150 test points per card and testing multiple cards in parallel. Together, these two requirements meant the test system had to be capable of automatically managing and switching more than 1,000 signals.
When designing a sophisticated test system such as this one, the risks of failure are magnified due in part to the fact that a large number of components from multiple vendors all need to integrate seamlessly. This exposes many potential points of failure due to issues with integration or compatibility. To reduce the risk of these failures which can waste time and money late in the product development cycle, this company made the following two critical decisions at the beginning of the design process:
- Choosing to simulate test hardware options before making a purchasing decision to ensure compatibility
- Selecting products known for compatibility and ease of integration
By performing simulation upfront, this company was able to mitigate the following common ATE design risks early:
- Ordering hardware that was not the best fit for its test system
- Experiencing hardware/software compatibility problems and other issues associated with multi-vendor solutions
- Wasting software development time while waiting for hardware to arrive
- Facing troubleshooting complexities
Let’s look at the details of how this company’s upfront decision to perform hardware simulation alleviated these common production ATE design risks and provided additional benefits later in the development cycle.
Mitigating Design Risks with Hardware Simulation
When developing complex test systems that require numerous software and hardware components from multiple vendors, it’s not practical to procure every hardware component simultaneously. This would be very expensive and come with a lot of risk. In this case, for the prior generation of this ATE, this company was already using the NI software platform, including NI TestStand, NI Switch Executive, LabVIEW, and NI Measurement and Automation Explorer (NI-MAX).
The engineering team was confident it wanted to continue to use the NI ecosystem and a platform-independent PXI solution that plugs into the NI software world well. Since PXI is an open platform, they were not locked into using specific hardware and wanted to evaluate options for managing and performing the complicated switching this system would require. In addition to the technical specifications for the switching previously mentioned, it was important that any non-NI hardware or software components selected worked well with the whole NI platform.
To avoid pigeonholing themselves into using hardware that would not be the best fit for the system and ensure compatibility
between the hardware components and the NI software platform, the company’s engineers decided it was best to simulate
the hardware using Pickering's simulation tools before
making a purchase. The simulation process would allow the team to understand hardware functionality and test hardware
capabilities without the hardware being physically present. This included using simulation to evaluate the following
Pickering products to see if they would be a good fit for performing the complex switching required in this system:
Since many Pickering switches can be programmed using industry-standard interchangeable virtual instrument (IVI) drivers, it was easy to simulate the Pickering hardware within the NI software environment. Using the IVI drivers available for the switches mentioned above, the engineers tested for compatibility, simulated and evaluated functionality such as running hardware-based execution loops, and developed code for the switches – all without any hardware physically present.
Once the engineering team determined the Pickering switches could provide the required functionality and compatibility using the simulated system, the software engineers were able to get a jump on writing code for the test system before the hardware was in hand. With these simulated modules, the engineers had early access to the same front panels that would allow them to interact with the hardware once received.
For this ATE, the lead engineer could also get the code working to the point where he could nearly start collecting data as soon as the hardware was received and installed. Therefore, once the hardware arrived, he just had to transfer the software from the development computer to the target system, integrate the software with the physical hardware, and debug any remaining minor issues.
Simplifying Testing and Integration of Multi-Vendor Systems
In addition to removing risk from the procurement process, by simulating the hardware upfront, a lot of time was saved once the hardware was received and system testing started. Since the code was already written when the hardware arrived, many potential sources of error were exercised in advance, including control mechanisms in the software and decision-making trees. Rudimentary errors, such as coding mistakes that would have automatically caused problems when the hardware was integrated, were also fixed well in advance.
Performing the initial simulation also meant that once the hardware was integrated, the test engineers had a built-in method for checking for anomalous behaviors during the testing process. Throughout testing, the code written during the simulation was considered a “known good” sample to compare and test to. In general, simulators eliminate a lot of sources of issues so that test engineers can confine their search space to the real problem when an error does arise. As a result, whenever something was not running as expected on the physical hardware already proven in the simulator, the test team had a better starting point for finding the error source because they could automatically eliminate issues with the test or driver code.
More specifically, for this test system, the engineer had created and verified all the route groups for the switching with the simulated system way before the hardware was in hand and also added a programmatic verification to show that the routes and the signals were activated correctly. This meant no one had to physically go into the system to flip switches and take continuity measurements to ensure signals were working correctly during testing, there was already enough confidence established that the routes were working based on the simulation.
Additionally, since the actual routes were known to be working during testing if a switching issue did arise, the test team could jump right to examining other potential faults. This could include confirming the command stream was coming out right or that it was conveying information correctly to the switches, or determining if there was an issue with an actual switch. In a system such as this one, there are many pieces coming from different places, and the ability to quickly know that someone should check that a message in a control mechanism works properly is beneficial.
Since it is easier to identify issues when they do arise, this alleviates the anxiety of working with multi-vendor sourced software and hardware. Often, with these systems, it’s hard for the engineers to know who to reach out to when there is a problem, and they may get directed back and forth between the different vendors as they troubleshoot.
Finally, since Pickering switches use IVI drivers and are designed to integrate seamlessly with the NI software environment, the simulation showed this company early how easy it would be to smoothly insert the switching hardware into the NI-based world where the software lives. The engineer working on this system attributed the ease of integration to the excellent documentation available on the Pickering website , which allowed him to both simulate the hardware and integrate it, as well as the support from Pickering if a question did come up.
Move Forward with Confidence: Simulate Pickering Products Early in Your ATE Design Cycle
For this company, it was imperative to have a low-risk and low-cost method for proving it would not be cumbersome to integrate Pickering switches with the company’s existing NI software stack and that Pickering switches could handle its extensive switching requirements. Simulating the Pickering hardware early in the design process provided this company with the confidence required to move forward with using Pickering switches. They knew early it would not be challenging to integrate the switches into the NI-based development environment the engineering team was already using. Plus, by performing the hardware simulation early in the design process, there were many other benefits that continued to reduce risk throughout the design and testing process.
