Test Strategies for PCBs

[matt314hew]

Hello everyone. I work for a small electronics company and would like to minimize field failures with better test procedures. we were looking at trying to come up with an application that could be used to record answers to questions that would fit with the PCB.

Has anyone done anything similar to this? And if so, what were the types of questions you tracked?

To give an example, we would like to know what the reading on the meter was when power was on. Or also record the number of times the LEDs flashed and that determines the different states.

Any information that others have would be beneficial.

Thanks.

 

[ronsimpson]

Welcome.
What part of the world? (location helps some times)
I don't understand if you want a test machine or you want to add these functions to your board.

 

[KeepItSimpleStupid]

You MIGHT be going about it wrong. Why not store whatever you need in say an I2C FRAM as the errors occur. then read it when the board comes back for repair?

 

[spec]

Hello everyone. I work for a small electronics company and would like to minimize field failures with better test procedures. we were looking at trying to come up with an application that could be used to record answers to questions that would fit with the PCB.

Has anyone done anything similar to this? And if so, what were the types of questions you tracked?

Hi Matt,

I think you are describing what is known as built in test equipment (BITE) and built in software tests (BIST).

I worked for three years on the BITE/BIST for a large ground RADAR system.

The first thing to know is that it is not a trivial exercise, and as a rough rule-of-thumb you can say that BITE/BIST will constitute at least 30% of hardware, software, real estate, and costs.

Very often the BITE/BIST has to be more sophisticated than the function being monitored. Take a simple example: a certain voltage in the system is accurate to +-1%. That means that the BITE monitoring that voltage needs an accuracy of +- 0.1% and preferably better.

Theses days the results of BITE/BIST can be stored locally in non volatile memory, as has been said, or communicated back to base via the net or over the air.

Often the user needs to see the results of BITE/BIST, for example if the equipment is overheating and it needs to be turned off.

One last bit of advice, BITE/BIST needs to be integrated with the design of the equipment from the inception- it can't just be glued on once the equipment has been designed.

spec

 

[matt314hew]

Welcome.
What part of the world? (location helps some times)
I don't understand if you want a test machine or you want to add these functions to your board.

United States - Pennsylvania.

The boss is looking for something that can be a sort of checklist type of thing. Right now, some of the guys are just saying things are working, and then something fails and he doesn't know who to talk to about why it wasn't caught.

Before we go about and make up a sort of checklist, we wanted to check and see if there are others out there that are doing something to check certain components before inserting into the boxes.

Thanks.

 

[matt314hew]

You MIGHT be going about it wrong. Why not store whatever you need in say an I2C FRAM as the errors occur. then read it when the board comes back for repair?

Thanks. I can pass this information on to the designer and see what his thoughts are.

 

[matt314hew]

Hi Matt,

I think you are describing what is known as built in test equipment (BITE) and built in software tests (BIST).

I worked for three years on the BITE/BIST for a large ground RADAR system.

The first thing to know is that it is not a trivial exercise, and as a rough rule-of-thumb you can say that BITE/BIST will constitute at least 30% of hardware, software, real estate, and costs.

Very often the BITE/BIST has to be more sophisticated than the function being monitored. Take a simple example: a certain voltage in the system is accurate to +-1%. That means that the BITE monitoring that voltage needs an accuracy of +- 0.1% and preferably better.

Theses days the results of BITE/BIST can be stored locally in non volatile memory, as has been said, or communicated back to base via the net or over the air.

Often the user needs to see the results of BITE/BIST, for example if the equipment is overheating and it needs to be turned off.

One last bit of advice, BITE/BIST needs to be integrated with the design of the equipment from the inception- it can't just be glued on once the equipment has been designed.

spec

I will take a look at BITE/BIST and see what we can do with it on our end.

Thanks. being a small company, we have to look at costs and trying to keep them down. But if something costs a lot up front but in the long run will save money, it is a good investment. But only time could tell on that.

 

[KeepItSimpleStupid]

You can't catch everything, but after some time of repairs there will be a history of bad parts.
Examples:
A vacuum guage (about a 5 year interval, environment crappy)
Lots of them
Nearly always the ripple on the -15 V supply --> replace about 5 electrolytic capacitors
Relay contacts burnt
Lamps needing replacing
that's 99% of the problems
Some of the 1% - bad switches, acetone spilled on the meter, dropped.

A power supply (we had lots of these)
10 year interval - replace about 8 capacitors because of unstable output.

A Scanning Electron microscope
Usually issues with the high voltage
Too expensive to have someone come out.
I was able to fix all of those issues.
Eventually got an SEM/EDAX on a service contract.

mini-computers
I was able to troubleshoot down to the module level using swapping.
Repair was exchange/repair for a fixed cost.
The mini-computer had a set of factory diagnostics that we had access too.

Big stuff like vapor dryers, e-beam power supplies, x-ray diffraction sets
Each repair made the system better,
The dryer required wiring with thicker wire.
The e-beam supply was a careful rebuild. Failures went for 1x/year to 1 every 20 years (different area).

 

[spec]

I will take a look at BITE/BIST and see what we can do with it on our end.

Thanks. being a small company, we have to look at costs and trying to keep them down. But if something costs a lot up front but in the long run will save money, it is a good investment. But only time could tell on that.

If you make BITE/BIST part of the initial design, and make it a requirement of the design, BITE/BIST can cost very little. Sometimes just a minor alteration or addition to the fundamental function is all that is required.

spec

 

[spec]

United States - Pennsylvania.

The boss is looking for something that can be a sort of checklist type of thing. Right now, some of the guys are just saying things are working, and then something fails and he doesn't know who to talk to about why it wasn't caught.

Before we go about and make up a sort of checklist, we wanted to check and see if there are others out there that are doing something to check certain components before inserting into the boxes.

What you are talking about is a 'Test Specification', which is mandatory in many areas. The purpose of a test specification is to define a procedure that will test all the functions that a particular equipment is required to perform (of course you can't do this 100%).

All tests are numbered and a 'Test Result Sheet' is produced for each equipment that is dispatched to the customer. Part of this is that each equipment as a minimum, has a name, reference number (normally the drawing number), and a unique serial number, all of which are also recorded on the test result sheet.

Take a very simple example:
A piece of equipment is a precision voltage reference of 5V with the following characteristics:
(1) Voltage output: 5V
(2) Output accuracy: +- 1%
(3) Output current: 0A to 10mA
(3) Mains voltage range: 115V to 125V RMS @ 60Hz
(4) Temperature range: 10 Deg C to 50 Deg C

The test specification would list the test equipment needed to complete the test procedure:
(1) Digital voltmeter (DVM)
(1.1) Input impedance: 1M Ohm or greater.
(1.2) Accuracy: +- 0.1% or better
(2) Ammeter

.... and so on

The test procedure might say:
(1) Connect the DVM (1) to the the output terminal of the unit under test (UUT).
(2) Turn the UUT on
(3) The voltage indicated by the DVM shall be between 4.999 V and 5.001V (record result)

... and so on.

Once the test procedure is completed successfully, the test result sheet is then signed and dated by the person carrying out the tests. The test result sheet is then archived in company records.

The above is a gross simplification, but once you have a template set up for your company's test specifications and test result sheets, it gets a touch simpler.

I have spent many an hour writing test specifications for all kinds of equipment.

spec

PS: a further development to the above is automatic test equipment (ATE) and automatic test procedures (ATP), were a machine does the testing automatically.

 

[matt314hew]

What you are talking about is a 'Test Specification', which is mandatory in many areas. The purpose of a test specification is to define a procedure that will test all the functions that a particular equipment is required to perform (of course you can't do this 100%).

All tests are numbered and a 'Test Result Sheet' is produced for each equipment that is dispatched to the customer. Part of this is that each equipment as a minimum, has a name, reference number (normally the drawing number), and a unique serial number, all of which are also recorded on the test result sheet.

Take a very simple example:
An piece of equipment is a precision voltage reference of 5V with the following characteristics:
(1) Voltage output: 5V
(2) Output accuracy +- 1%
(3) Output current: 0A to 10mA
(3) Mains voltage range: 115V to 125V RMS @ 60Hz
(4) Temperature range: 10 Deg C to 50 Deg C

The test specification would list the test equipment needed to complete the test procedure:
(1) Digital voltmeter (DVM)
(1.1) Input impedance: 1M Ohm or greater.
(1.2) Accuracy: +- 0..1% or better
(2) Ammeter

.... and so on

The test procedure might say:
(1) Connect the DVM (1) to the the output terminal of the unit under test (UUT).
(2) Turn the UUT on
(3) The voltage indicated by the DVM shall be between 4.999 V and 5.001V (record result)

... and so on.

Once the test procedure is completed successfully, the test result sheet is then signed and dated by the person carrying out the tests. The test result sheet is then archived in company records.

The above is a gross simplification, but once you have a template set up for your company's test specifications and test result sheets, it gets a touch simpler.

I have spent many an hour writing test specifications for all kinds of equipment.

spec

PS: a further development to the above is automatic test equipment (ATE) and automatic test procedures (ATP), were a machine does the testing automatically.

Thank you. I wasn't sure what to call it. Test Specification makes sense.

 

[spec]

Thank you. I wasn't sure what to call it. Test Specification makes sense.

No probs Matt.

spec

PS: if you put 'Pennsylvania US' next to 'Location' on your user page, it will show in the box at the left of your posts- that will be a big help to us.

 

[matt314hew]

No probs Matt.

spec

PS: if you put 'Pennsylvania US' next to 'Location' on your user page, it will show in the box at the left of your posts- that will be a big help to us.

Updated it.. thanks for the info

 

[Mikebits]

Hello everyone. I work for a small electronics company and would like to minimize field failures with better test procedures. we were looking at trying to come up with an application that could be used to record answers to questions that would fit with the PCB.

Has anyone done anything similar to this? And if so, what were the types of questions you tracked?

To give an example, we would like to know what the reading on the meter was when power was on. Or also record the number of times the LEDs flashed and that determines the different states.

Any information that others have would be beneficial.

Thanks.

Entire books have been written on this subject, in fact I have a very good book entitled "Building A Successful Board Test Strategy" By Stephen F. Scheiber Publisher Test and Measurement World.
I recently ordered Test and Measurement Know it All. Well anyways, it seems as though many designers these days fail to grasp the design for test strategy for whatever reason, be that lack of experience, schedules etc. The go/no go test may be fine for a product like a $3.00 flashlight, but more complex circuit boards require testing to ferret out problems, be it design, manufacturing etc. Often times cost of testing drives the decision of not to test, I point you to the order of magnitude rule.

The graph above demonstrates the cost to repair at various stages of a product life cycle. Clearly it can be seen, field repairs is most costly, so early fault detection prior to product shipping has its merits. This is all fine and good but does not help you with your current problem.

Perhaps we can come up with a bandage to stop the hemorrhaging of capital.
Without knowing the particulars of your product, it is hard to say how you should proceed, but I would say this is a good time to get engineering involved (if not already, perhaps that is you). Round up all the failure items, identify fail mode, ie. shorted/open pins, components out of spec, etc. The individuals involved should have a thorough understanding of the design, so fault isolation and proper solutions may be found. Oftentimes QA testing of incoming components used on the design are just expected to work like the spec sheet says, but unfortunately this is not always the case, so random component testing is often a good idea. Counterfeit components are on the rise, so buying from reputable suppliers is also a good idea. In your case, some form of Automated Test Equipment (ATE) may help catch system failures. A good DAQ system with enough analog/digital I/O can be setup and controlled via Labview software (which is designed for such applications). I personally use Labview and find the graphical interface very nice to use.

If you have some particular failure that you have identified, perhaps you would care to elaborate so a proper test to catch the failure can be developed.
Well sorry I was not much help.

 

[Mikebits]

One more thing I forgot to mention, JTAG testing is often a good way to design for test, especially in a digital environment although there are analog features in the JTAG spec.

 

[spec]

Well put Mike,

The decision to test or not to test, at the highest level depends on the following (of course the situation is more complex than this):
(1) Mission critical, safety critical: testing mandatory
(2) Customer satisfaction (company image): testing essential
(3) Where the cost of field repairs/replacement are low and (1) and (2) do not apply): consider not testing
(4) Jelly-bean product, where (1) and (2) do not apply, and where the product has an acceptable risk of not functioning: consider not testing. Some integrated circuits fall into this category.

My feeling, though, is that all products should be tested, at least, for their primary functions. In the case of the voltage reference I mentioned in post #10, for example, you could just check that the UUT does produce 5V, but you would not necessarily test the accuracy of the voltage, etc.

By the way, there is one more acronym- the test field is full of them: special to type test equipment (STTE) or test jigs. Good STTE can often save a fortune in testing costs, especially where a number of UUTs are involved. In one case at work, way back, the production testing was reduced from sixty minutes to ten minutes by a relatively simple and low-cost STTE. Test errors were reduced to zero as well. Other benefits were that the test procedure was no longer tedious and the tester's required skill level was reduced.

One of the problems with testing is that engineering tend to write the test specification and production do the testing, and in all situations where one person dictates and another person does the doing, there are problems. One way to improve the quality of the test procedure and tests specifications is to get the engineer writing the test specification to test the first batch of UUTs.

As MikeBits says above, testing is a big subject.

But there is an awful lot of learned waffle on the subject of testing, and if you are not careful the whole thing can turn into a circus. And if you ever use a testing consultant, make sure that he has done years of actual testing on the bench himself.

spec

 

[KeepItSimpleStupid]

Don't forget the "bed of nails", Pogo Probes, probing as well.

 

[spec]

Don't forget the "bed of nails", Pogo Probes, probing as well.

Ah, yes: 'bed of nails'.

I have never seen one that works reliably. But that is just my experience.

spec

 

[Mikebits]

One of the problems with testing is that engineering tend to write the test specification and production do the testing, and in all situations where one person dictates and another person does the doing, there are problems. One way to improve the quality of the test procedure and tests specifications is to get the engineer writing the test specification to test the first batch of UUTs.

Good input there Spec I agree with what you mention above concerning the division between engineering and the test folks, but many large companies are now seeing the benefits of concurrent engineering (the We are a Team, mindset).

As for bed of nails, that is somewhat being phased out for a number of reasons, and the main one is the shear mass density of components on a board. It is no longer feasible to provide all the test points. Oh and then there are BGA parts. As the mobsters say, foget about it...

 

[spec]

Hi Mike,

Sounds like you have had similar experiences to me. That is so true about the importance of different departments pulling together to get a good product and hence improve the company's well-being. When I first joined a big company in the mid 1960s the division between different departments, was extreme.

The UUT that I mentioned was nothing more than a panel with some switches and lights. Behind the panel were an input and output connector, a few relays and resistors.

The original test procedure required the test engineer to put probes into both sets of connector contacts and make measurements while he set the switches on the front panel to various positions. It was a mind-numbing, error-prone procedure, which no one in the test department wanted to carry out.

A simple STTE was made and all the test engineer then needed to do was to connect two plugs to the UUT and set switches on the UUT and STTE. It was ironic because, in spite of resistance from the engineers to the STTE, the engineers ended up copying the STTE for development work.

spec