Significantly Out of Tolerance Reporting

[ck454ss]

If the UUT is inop due to a hardware failure, OOT or Soot data cannot be taken.Does a report still need to be sent?

In my case yes I want the an OOT report generated unless the equipment does not turn on or if I didnt give specific instructions saying the unit was damaged (Meaning I know the instand the damage was done and no product was shipped on it)  Reason being is that alot of equipment I have, say DMM's, are in automated test panels,  As an example if I have a damaged/blown Ohm input on a DMM and I get a constant open its possible I could pass bad units as my software is looking for 1M Ohm minimum.  Same for any other Min/Max readings I have.

[CalLabSolutions]

I am going to chime in here..  I many get myself in trouble, so please keep in mind I do not work in a calibration lab; we are a software company..

I personally think a lab should issue a SOOT report if the unit is ANYWARE beyond 100% of its published spec.  If some bozo out there thinks engineers will pay more attention to an SOOT than an OOT, then all of my OOT reports would have the word Significantly in the title.

I mean come on.  If the unit does not meet spec when it hits the calibration lab, no matter how significantly it was out, the user must determine the effects on the product.

Anyway, that is my 2 cents.

Mike Schwartz
Cal Lab Solutions   

[RFCAL]

In a Spec An, if the Yig Oscillator is dead,there cannot be any SOOT or OOT data taken.A simple statement that Pre-Data cannot be taken due to a hardware failure should suffice.If the Yig has holes in it at certain Frequencies,The yig still needs to be replaced.This is a hardware failure--are you saying that an Soot data report needs to be sent?This could cause failures in all parameters tested.

[Hawaii596]

I think intuitively, by definition, an OOT is significant if it (as defined by local policy or requirement - these are all my own words) has any reasonable statistical probability of impacting test/mesurement results.  So I believe, also by definition, that this is determined by who ever has the authority and/or responsibility for evaluation.  For an inhouse lab, there would typically be an internal policy.  For a contracted provider (OEM, Third Party/Commercial labs, etec.) it would be determined by the customer.  So for that second grouping of labs, they would not make a decision for customer's equipment; they would just report it, and the customer would make the decision based on their own policies whether it is significant or not.

I haver personally (while working for inhouse and commercial labs) never liked the term "Significant Out-Of-Toleranc," as it seems in my opinion to be a vague concept, easily mis-applied or glossed over when "convenient."  I prefer to think of all OOT's as significant - they all need to be evaluated for impact.

As for malfunctions, I would lean toward reporting any and all measurable OOT's and let someone else decide what is or is not significant.  If you can turn the instrument on and make a measurement, however grossly OOT, you make the measurement, and submit it.  The only circumstance where I would not report an OOT is if I literally could not due to the malfunction being such that I can not even go into that mode of operation.  If its a spectrum analyzer with a dead YTO, and if 0.00 dBm input (lets say with a 0.00 dB ref level at 10 dB/div for example), measured down in the noise, I would somehow apply a value to the down in the noise.  If I could not even get a trace, then I would not make a measurement.  If, for example, some less educated user tried a related measurement, and thought his test result was a fail, not knowing that the spectrum analyzer had failed, he/she needs to be notified.  If there was any way they could have made a measurement with the instrument with its malfunction, and not for certain, know when it broke, there must (in my opinion) be an OOT report generated.

[ck454ss]

Exactly what I was trying to say Hawaii.   

[RFCAL]

That is a LOT of OOT reporting for no reason, in my opinion.Even in Government labs,it was acceptable to list pre-data not available--This is practiced by the BIG THREE ( Agilent , Tek , Fluke ). We would not list the entire performance test as OOT for every step as this would be a waste of time.The statement " Pre-Data not Available " should suffice.I should also note that we are a rental company.
Also on another note, I have seen cases where the data report says PASS,but the Graph shows the measurement outside of the Uncertainty limits.What would you do then?

[Bryan]

"data report says PASS,but the Graph shows the measurement outside of the Uncertainty limits."
does that mean it's within the tolerance but within the uncertainty from the tolerance limit on the in-tolerance side?

[Hawaii596]

I'm not an ISO17025 expert, but I think I understand within the ISO17025 context that it is supposed to be considered OOT if the outer limit of the uncertainty falls outside the tolerance line.

Back to the other part of the topic... I am not anal about this.  I have fairly "don't waste my time" views with data reporting.  But I mix that with what I try to make a good customer focus (both when I was inhouse, when I worked in FDA regulated, and presently in commercial).  So to me, I guess it is really about providing my customers with what ever data they need. 

I'm honestly getting mentally confused between this thread, and another one I'm participating on in Linkedin right now.  There are some extremely anal views about what data should be reported...  There was one view (not mine) that without full data, it isn't a real calibration.  Please don't anyone attack me on that one as I don't agree with that.

I grew up in the MIL-STD-45662 days, and even remember when MIL-STD-45662A came out.  It is to me, about assuring the user that their instrument meets specs periodically to a given confidence.  And any where it does not, adjust it in and let them know where the issues were. 

There is apparently a trend these days, though towards full data which I don't necessarily personally embrace.  But as I provide services to customers, it kind of doesn't matter what my view is (to some extent).  Oh well.  Its Friday afternoon.  I'm going to go see "The Adjustment Bureau" tonight and not think about such things all weekend.  Have a good one, everyone.

[RFCAL]

The data report says pass, the test shows Indeterminate on the screen, and the Graph shows the measurement OUTSIDE the Uncertainty Limits.That should be a fail for Z540 and 17025.