Assembly Verification vs. Simulating Real World

What is the proper way to test a part in a manufacturing setting? Do you try to simulate what that part is going to see in a real world scenario, or do you craft a test that is simple and effective at catching assembly defects? As simple as this question is, it has been a point of contention for many years in automotive powertrain testing, and there are many nuances in both approaches.

Consider engine testing as an example. For years, manufacturers were adamant that the only way to verify that an engine was going to work once installed in a vehicle was to actually start it and run it – this is called “hot test”. However, as production volumes increased and cycle times decreased, combined with cost pressures on a typically expensive infrastructure, engineers began questioning that basic premise. Instead of simulating what happens in the vehicle, could you test in such a way that is designed specifically to highlight potential engine defects that happen in the assembly process – like missing bearing caps, bent valves, missing o-rings, etc? This was the beginning of engine cold test: where an engine is spun by an electric motor without actually starting it.

Lower infrastructure costs (no fuel, no exhaust) combined with shorter cycle times proved advantageous, and now cold test is the standard for light-duty engine testing in high volumes, relegating hot test to an audit-only purpose. It was relatively easy to control fuel rails, solenoids, and injectors with defined rules that were applicable only to the test system at hand, so controlling a part under test without its production control module was the preferred method to run these tests.

But what happens as the part you are testing becomes more and more complex, and is more connected to the components of the vehicle it is designed to operate with? “Faking” the controls becomes more and more arduous and fragile, and riddled with assumptions about how that interaction is supposed to work. You often replace the production control module with a custom system that is supposed to mimic how the production version works, but in a more controlled and flexible manner best suited for the end-of-line test. How much time is invested in that controller?

Signal.X has been working in this environment for many years, and it is interesting to see how both of these approaches have been used in different production testers. The choice of the approach tends to be unique to the manufacturer and their reasons for investing in one direction or the other, and we have been involved in both methods many times with success. However, the degree to which the control modules are interdependent is increasing, and it will be interesting to see how simulating the real world may become a necessity to validate the product as it comes off the assembly line. Whatever the direction, we are here to help!