Viewpoint News, December 2010

Simulating the Product

by James Campbell - jac@viewpointusa.com

I run out of fingers when I count the number of times we have had to simulate a product or automated machine for which we are about to connect to a test system. Maybe the product is not completely designed yet or prototype units are scarce. Maybe the product is so expensive that you are NOT going to debug the test system with a real product. Maybe you are replacing an obsolete tester already integrated with a production line and you must limit the production downtime when you replace the old tester. In these cases, the only way to move forward is simulating the product (or machine). Does this work? Is it worth the extra effort? Here are some tips to help answer those questions and to promote success.

You Too Can Simulate

We’ve all simulated the product to some extent when we verify the Test System. Even simple signal creation and digital I/O can feed the test system with the signals used to measure and control the product or machine. Since LabVIEW realtime (RT) and FPGA arrived, you have a good chance of simulating the product or machine in a completely virtual fashion.

Many product designs have subassemblies interacting with controllers. So, simulation takes two flavors: the Test System acts as a controller to test a subassembly or it acts as a subassembly to test a controller. Either way, Viewpoint has some good rules of engineering to consider, based on the many projects and years we have been creating simulations.

One of the most interesting simulations we developed (at least that’s the feedback we get), is the Gatling gun simulation, which we did many years ago. Check out this list as an example of what’s possible: Gatling Gun Simulation

This is an example of simulating the subassembly so we could test the controller.

Five Tips

Here is a tip list to consider for simulating your product or machine.

• Tip 1: Check if you can deliver the Test System sooner by at least 1 month.
• Tip 2: See if you need to inject faults that otherwise would destroy the product or machine.
• Tip 3: Understand that timing behavior is critical.
• Tip 4: Know if you can simulate the device physics. This can be fun yet tricky.
• Tip 5: Recognize that user interfaces can be simple.

Tip 1: Saving Time

Developing a simulation consumes engineering resources and time. Why not simply wait until the product or machine is available and work with the real thing? It is generally justifiable based on time alone if the Test System can be completed at least 1 month earlier with a simulator available than not. Why 1 month and not 2 or more months? It’s an engineering guess based on our experience. Your exact experience will depend on the complexity of your product or machine. The implication of this approach is that you can develop and debug a simulator and have a completed and tested Test System earlier by one month.

Product Not Available

If you are the sole developer, this implies that simulator development and Test System debug and acceptance takes one month less than Test System debug and acceptance on a real product. About the only way that (usually?) happens is when the product availability is delayed and won’t be available to connecting to the Test System for some time.

If you are able to develop the simulator in parallel, then it is easier to capture the 1 month benefit.

Product Available

If the product is available already to connect to the Test System, then check if the product needs to be controlled or handled by some automated machinery during test (e.g., an environmental chamber, high voltage supply, index table, automated test connector, and so on). In this case, it becomes important to know if the unavailability of the machine will hinder progress. If so, you can speed delivery by simulating the machine.

Tip 2: Injecting Faults

The reason we developed a simulator for a Gatling gun was partly driven by the need to inject faults into the gun controller we were testing with the Test System. First, it is hard to generate an actual gun jam (at least reliably). Second, it does the actual gun no good when that happens. Clearly, a simulator is a better method to generate all types of faults in safe, cost-effective, and reliable manner.

This same philosophy might apply to your product. Ask yourself:

1. Can failure modes be produced for the UUT without damaging the subassembly producing those faults?
2. Do UUT inputs need to be varied around the specified tolerances in ways that would require modification to the actual product or you have to wait for enough to be built so you can gather the required set of products with the required variability?
3. Will you need to modify fault scenarios because the product is still in design?
4. Are consistent and reproducible fault scenarios needed for testing the production Test System?
5. Is excessive time required to setup the subassembly to produce various failure modes? This is a corollary to item 2.

As an example for Item 2 above, suppose the subassembly, to be simulated, is a detector which outputs digital communications to a controller, to be tested. The controller has a certain level of tolerance to noise on the communication lines. However, it is challenging to test the controller’s handling of this noise impairment with an actual product because the subassembly does not have any adjustable internal components. With a simulated product, a high-speed analog waveform generator is used to create the noisy signals input to the controller.

Tip 3: Timing is Critical

Perhaps the largest challenge to designing a simulator centers on timing. Of course, the simulator needs to behave similarly enough to the subassembly to be simulated that the UUT doesn’t behave markedly different. Analog output levels are important but trickier is the timing of events. Specifically, you need to know the tolerance of when an event needs to happen.

It is very common to have latencies and jitter in any subassembly which is being simulated. Many devices today are built around microcontrollers running some RT operating system, which produces jitter and latency. Or, FPGA and ASIC devices might be used, which produce jitter, albeit much less than an RTOS. Even if the device is purely electromechanical, there will still be jitter due to noise and component perturbations. Thus, you need to know the level of jitter of the device to be simulated so that you the simulation techniques to apply so your simulator acts comparably.

We rely on LabVIEW RT to provide the baseline timing for our simulators. We see about 1 ms jitter and latency for our LV RT simulator application. This level of jitter can be smaller based on the processor and complexity of the application, but 1 ms level is a good rule of thumb. When jitter levels need to be shorter than 1 ms, switch to a hardware-based solution, whether it be FPGA or DAQ.

Tip 4: Physics really is Fun

OK, maybe timing isn’t the most challenging part of simulation. Maybe it’s more challenging to simulate a device which needs to follow some defined physical behavior. For example, with the Gatling gun simulator, we had to create the timing of position signals produced as the gun accelerated to its top rotational speed. Remember F=ma? The need for physics obviously arises with the simulation of electromechanical devices. Perhaps less apparent is that even purely electronic devices change behavior under various conditions (e.g., temperature, pressure, electrical power supplies, and so on) and physics may be used to simulate these scenarios. Simulating a sensor is one such example.

With physics-based simulations, you need to understanding just how “real” the simulation needs to be.

Tip 5: User Interfaces

Whereas the test application typically needs a friendly, attractive, usable interface, simulators UIs can be rather crude by comparison. Thus, when estimating the effort to create a simulator, consider that the UI effort is often smaller than the typical test application.

Conclusion

Simulations are increasingly important to Viewpoint in developing Test Systems for today’s complex products. We also see the need for simulations in replacing obsolete test systems that are part of a production line. Certainly, developing simulators takes time and resources and there are important aspects to consider for success. However, the combination of LV RT, FPGA, and DAQ allow development of fairly complex simulators with reasonable amounts of effort. Use the tips above to guide your choice of whether to simulate or not.