Replacement of obsolete components

[[email protected]]

Hi,

I'm looking for some guidelines regarding replacement/substitution of
obsolete components in our products.

Currently the procedure is as follows:
Passive components are evaluated by datasheet, and replaced without
testing in case of matching data.

Semiconductors are evaluated by datasheet, and tested in 5 pcs. of the
product.

The test is a standard functional production test, which basically
consists of a verification of the functionality; signal levels, band
widths, memory addressing etc. No temperature cycling, EMC test or
burn in is performed.

My worry is, that you in case of e.g. a die schrinked SRAM or uP, you
might reduce your margin to an unacceptable level, making the product
more sensible to EMC, temperature or what ever...

How is this qualification done in the industry? E.g automotive?

Thanks

Jesper

 

[David L. Jones]

Hi,

I'm looking for some guidelines regarding replacement/substitution of
obsolete components in our products.

Currently the procedure is as follows:
Passive components are evaluated by datasheet, and replaced without
testing in case of matching data.

Semiconductors are evaluated by datasheet, and tested in 5 pcs. of the
product.

The test is a standard functional production test, which basically
consists of a verification of the functionality; signal levels, band
widths, memory addressing etc. No temperature cycling, EMC test or
burn in is performed.

My worry is, that you in case of e.g. a die schrinked SRAM or uP, you
might reduce your margin to an unacceptable level, making the product
more sensible to EMC, temperature or what ever...

How is this qualification done in the industry? E.g automotive?

It's entirely up to each individual company, case-by-case, and in many cases
up to the whim of individual departments/people within companies. There is
no rule of thumb or industry standard qualifications, but different
components may require as much trouble as formal product re-verification
(e.g. EMC, safety standards, specific industry standards etc)

For most apps you can pretty much get away safely with data sheet
comparisons and standard functional tests as you have done. Some components
and circuits are obviously more likely to cause issues than others, by
orders of magnitude. It really comes down to the design engineers judgment.

Dave.