Hi guys,

I've got a bit of an unusual situation here that I can't find a straight answer on. Of course, I can't go into great detail without violating a company privacy policy or something, but let me try to give you the skinny. Maybe the answer will be easy.

BTW, this is hardware that we sell to the government as well as many others, so quality is important and thats why I'm getting a lot of opinions on this one. We typically ship about a few hundred of these a year. A few units were qual tested many years ago. We are an AS9100 certified company.

This product of mine has certain parameters that it was qual tested for. There are a few parameters that we test each product for but most parameters were qualified.

We don't do any sample testing of the qualified parameters. But a non-goverment customer did a sample test on one of our products and it failed badly for one of the qualified parameters. They tested another and it passed. We think the failure may have been a complete fluke because our reliability numbers on the failed component are really high (.99+).

We've seen this component fail many times before but only on returned units. Up til now we always believed the process of disassembly was what caused the failure. Now we can't say for sure.

I believe this failure warrants a full investigation into the failure of the component so we can once and for all settle the question of how it fails or if it fails at all. It seems to me that these 2 units that were tested at the customer's facility constitute a sample test, a sample test that we must not ignore.

My management wants to believe that the qualification report that was done years ago is still valid despite the failure of this unit. They do not want to fund an investigation into the cause. They believe that the evidence is not strong enough to justify the expense.

THE QUESTION:
Does AS9100 have any rules regarding the treatment of data they MAY contradict the qual report? Does AS9100 regard has happened as a sample test and if so what actions does it obligate us to take? I think management would like to just sweep this whole thing under the carpet, but it seems to me that concrete data is required one way or another. What do you think?

Thanks,

RayMan

Hello, RayMan!

We are sure glad you came to the Cove!:bigwave:

Now, I am not knowledgeable in regards to AS9100, but a couple of things caught my attention. Too, we respect your wish to stay vague for your protection!:) We certainly don't want anyone to get into trouble.

Now this first statement:

We think the failure may have been a complete fluke because our reliability numbers on the failed component are really high (.99+).



Seems to be in direct violation with:

We've seen this component fail many times before but only on returned units. Up til now we always believed the process of disassembly was what caused the failure. Now we can't say for sure.



Which is it? I realize you clarify the returns are on returned units, but how reliable are these? Also, are the returned units within a standard time, or does the time in service vary?

Also, what do you know about the non-government customer? How valid are their testing methods/procedures?

I believe this failure warrants a full investigation into the failure of the component so we can once and for all settle the question of how it fails or if it fails at all. It seems to me that these 2 units that were tested at the customer's facility constitute a sample test, a sample test that we must not ignore.

My management wants to believe that the qualification report that was done years ago is still valid despite the failure of this unit. They do not want to fund an investigation into the cause. They believe that the evidence is not strong enough to justify the expense.

RayMan

As far as the two samples, they could range from highly valuable to useless. It all depends on their quality of testing, your confidence in them, etc. Can you not test them yourself?

As you are well aware, management can make whatever decisions they choose regarding the product. In the end, you will need to be able to sleep at night with whatever action/inaction occurs.

I am still a little unclear about the testing, and if the one reject warrants further testing. I would be far less concerned with testing performed way back than how the product is performing now. If the only testing results you have are from those two samples, you need more testing on your products.

Brad,

Sorry, I didn't explain things as well as I could have.

When the customer tested the product, it was done very well. We inquired a lot about how it was done and what kind of setup they used. Everything was top notch, so we believe that the tests are extremely valid.

As far as the failures we saw before on returned units...
The components were only observed to have failed once we had disassembled the product and could see them. The reasons for product return were not due to the failure of the component. Sorry if it looked like those two statements contradicted each other. However, it is possible that the components could fail in the field and the customer would not notice it unless they had it hooked up to diagnostic equipment.

Basically, when the one customer tested and failed the unit, it was the first time we had data showing this component "for-sure" failed in its operational environment.

I guess I'd like to know, under AS9100, does this knowledge of component failure compel us to investigate a root cause? Or can we still rest on our reliability numbers and our qual report that says the design SHOULD be sound? Or perhaps good engineering practice in general would compel us to find the root cause? My main concern is the fact that we sell to the government. When they require a CofC for a product, we had better be sure all the bases are covered.

Thanks,

RayMan

I guess I'd like to know, under AS9100, does this knowledge of component failure compel us to investigate a root cause?

7.5.1.5, b

7.5.1.5, b

Thanks, Badger. As I stated, I am not familar with AS9100. Does the above clause state the OP must/should/can/ etc. conduct failure analysis? Or, what is your opinion/interpretation?

I offered that clause as a possible reference not knowing much about their operation or product. It may or may not apply. I would be more concerned about the regulatory issues that might apply but that is also dependant on the product and any potential safety issues.


7.5.1.5, b

Control of Service Operations: Where servicing is a specified requirement, service operation processes shall provide for:

a. a method of collecting and analyzing in-service data,

b. actions to be taken where problems are identified after delivery, including
investigation, reporting activities, and actions on service information consistent with contractual and/or regulatory requirements,

Thanks BadgerMan,

The contracts for this product definitely require failure analysis. The thing is though... the customer that did the testing is happy just getting his product replaced, so he has stated that he doesn't want to pursue this. Since we sell this exact same product to the US government and their contract requires failure analysis, then I'm thinking that we must do the FA for the sake of the US government contract. There's no reason why it couldn't happen to one of their units too.

RayMan

Since we sell this exact same product to the US government and their contract requires failure analysis, then I'm thinking that we must do the FA for the sake of the US government contract. There's no reason why it couldn't happen to one of their units too.

RayMan

If your contract has a FRACAS requirement, that may be the most "black and white" method for demonstration of the need for RCCA. If I were in your shoes, I would generate a corrective action request to document the investigation. The end result may be that the test method was at fault and/or the failure was a fluke but at least you will have covered your back side.

BadgerMan,

Thanks for the help so far. Of course this isn't easy now. I'm having trouble getting funding to pay for the FA. All the management wants to point to somebody else. I'm thinking that I need to light a fire under them to get the funding for this FA.

Would it be fair to say that our product compliance in general is compromised if we can't get this FA funded and done? I guess the key question is, is FRACAS a key component of ongoing product compliance? Does failure to fulfil FRACAS requirements constitute a gap in our product compliance?

I think if I can phrase my response to them this way that I'll be able to get the funding I need much faster.

RayMan

Management pointing fingers……………..? I am shocked and appalled! :lmao:

My understanding of the FRACAS requirement is that your company must monitor your product’s performance after delivery and proactively take corrective actions when necessary. I would say that failure to fulfill FRACAS requirements constitutes a gap in your contractual compliance, at the very least. Has anyone (a customer) requested a formal corrective action response relative to this product?

I am curious as to why funding is needed for conducting a root cause analysis. Is it possible that you could facilitate a root cause analysis by assembling a team of “experts” from within your organization?

Let me explain a few more things.
We've got a plan for conducting the root cause analysis, but its several weeks worth of work. The management all want to point at each other because nobody can pin down exactly whose contract should pay for this. The customer whose unit failed is happy just to get a replacement, so he doesn't want to pay for extra work. That's why I'm saying that if I can show that this is a product compliance violation and not just a contract compliance violation then I will be able to break the stalemate.

It seems to me that in the absence of continuous testing (sample test, group c, final acceptance test, etc...) of qualification parameters that FRACAS is the only way to guarantee spec compliance over time. Remember, it been years since we did our qual study. I'm thinking now that if we fail to conduct this FA then we can't issue CofC's in good conscience. On ANY contract. Does that help any?

We have products that fail in the field both within and outside of the warranty period. On all failed units, our repair station determines and reports a cause for the failure as well as their correction for that failure. It would be physically impossible for us to perform an in-depth RCCA for all field returns due to the number and variety of products we have in the field. However, we also conduct regular and in-depth trend analysis regarding our product’s performance in the field and then our FRACAS process requires us to take positive corrective action for recognized trends. We also factor in failure rates (trends) of components and assemblies that occur during manufacture and acceptance testing. In short, we respond to recognized trends more so than individual failures.

Do you think you have a trend rather than an isolated failure? If so, you can predict that you will have occurrences in the future that may have a more serious impact. On the other hand, if the failure was due to a misuse/misapplication of your product or testing beyond the normal testing parameters, you may be able to justify the lack of action.

Yes, I think it fair to say at this point he have a pretty significant trend. Like I said in an earlier post, the reliability on this component is supposed to be .99+. So it shouldn't take more than a couple failures to constitute a trend here.

I think I'll let the management know that any of our CofC's won't be worth the paper they're written on if we can't get some corrective action in place that fixes this obvious trend. Hopefully the FA funding will be coming out of the walls after that.

Thanks,
RayMan

Sorry to restart this issue, but I've got another question that has popped out of this.

Our investigation is showing a 3.5% failure rate of this component (should be <0.1%). The component is not tested prior to shipment so we have no way to identify failing units as they leave the factory. Yet we are still shipping every unit to the government and stamping them off as spec compliant.

We can safely say that our product is "96.5% likely to meet specified requirements" rather than "compliant to spec". In other words, we're shipping hardware that is not spec compliant.

Do you agree that this is the case?

Everyone, feel free to respond. I'd like to know what you all think.

RayMan