How to get peaks back to 120G in a random profile?
Here is a common real-life scenario encountered in the automotive world, where a lot of data is taken from vehicles on the test track. Sound, temperature, vibration, engine rpm, etc., are all captured. To measure vibration, accelerometers are placed on many locations of a vehicle. Then, the vehicle is driven around a prescribed test track, with many different road surfaces, simulating the real-world environment.
After the test drive, an engineer has an abundance of time history data and needs to define a random vibration test for a particular component of a vehicle, for example, an oxygen sensor. The obvious solution is to take the accelerometer data from the accelerometer mounted by the oxygen sensor, run this data into a spectrum analyzer, read the power spectral density (PSD), and use this PSD to define the random test.
However, when looking at the resulting PSD, and comparing it to the actual data, often a discrepancy is noted. In the actual data, the engineer may see 120 G peaks, even in the frequency band-limited actual data. But, the random test PSD perhaps gives a 15 G RMS test. We are pretty sure we will only see 3 or 4 times the G RMS level (3 to 5 sigma peaks) when running the random test for the duration of 2 hours. Even with the sigma clipping turned off, this is only 45 to 75 G peaks.
The question is: How do I get the peak levels back up to 120 G peaks when running my random profile? There are several solutions implemented in the real world to “solve” this issue.
The first and most common solution I have seen is “recognize and complain.” It involves simply observing that the real-world data contains 120 G peaks, and the random test never produces any peaks greater than about 50 G with any regularity. “Why do we have to run this test? It never produces any failures anyway” is the statement made by the test engineer.
The second most common solution I have seen is “recognize and adjust.” This solution approach involves the clever test engineer who recognizes the lack of peaks in the random test, and the desire to fix the problem. The solution is to raise the G RMS level (and spectrum level) to get the peaks back into the test. Usually, the number 4 is used. If you want 120 G peaks, divide by 4, and select 30 G RMS as the test level. Even though the RMS level is twice the desired 15 G RMS level, at least you will get your 120 G peaks with some regularity. “We are testing this part to some very high levels, but we feel comfortable that if it passes this test, it will survive the real-world environment” is the statement made by this test engineer.
The third solution is to “recognize and correct”. This solution approach involves using emerging technology to re-shape the probability density function (PDF) to fit the real-world data. Rather than using the Gaussian distribution, adjust the shape so you get 15 G RMS with 120 G peaks at regular intervals. The technology available today allows you to shape the PDF to get 8 sigma peaks (120 G peak/15 G RMS) at the same repetition rate as Gaussian-produced 4 sigma peaks.
Technology today can produce the peaks at all frequencies of the spectrum and allows a much more accurate representation of real-world data for random testing. “We are testing the part at both G RMS and G peak levels really seen in actual use” is the statement made by this test engineer.
Response from Wayne Tustin:
Concerning “How to get peaks back to 120 G in random profile?”, I’m surprised that John didn’t mention the “waveform replication” test method he was “pushing” a few years ago. Other vendors have different names, but the method remains in the time domain, nicely reproduces peaks, doesn’t do any Fourier transforming, and doesn’t mention PSD or those confusing g²/Hz units.
I’m told that the 2008 “G” revision to MIL-STD-810 will include a new Test Method 525 on Waveforms Replication.
Wayne Tustin
President
Equipment Reliability Inst.
Santa Barbara, California
John Van Baren replies to Wayne Tustin:
Thanks for your comments!
I agree, if you have time domain, this is often the best way to go. I’d plug it again, but the article was to be short and sweet. And, random was the topic of my choice.
Do consider these reasons to consider random with Kurtosion®:
1. If your test procedure calls for random testing, you need to test with random. You may want to consider matching the pdf of the test to what happens in the real world.
2. Random is a probability test. Thus, more variations will be applied to the unit under test, rather than the application of the same waveform, over and over again, that you get with replication techniques.
Thanks again for your questions!
John Van Baren