??? 01/15/10 18:40 Read: times |
#172499 - Always a balance between cost and gains/losses Responding to: ???'s previous message |
Richard said:
Actually, I believe that would qualify as a single-event-upset rather than a "pointer error," but it should nonetheless be considered. May have been cased by a single-event upset. But such an event can result in the code either jump to the wrong location, possibly skip a pointer initialization, or fail a memory read/write, resulting in a pointer getting a garbage value. All pointer errors are not caused by bugs, and with enough volume of units in the wild, a few of them will suffer really bad environments or extreme events. No customer bothers if it suffers a direct lightning strike resulting in a melted box. It's the close calls that doesn't leave any visible traces that makes the customer unhappy. They just see a unit that suddenly misbehaves. Richard said:
That's why the product being sold must be subjected to random short-term (100-hour) stress-testing while the originals ought to be 1000-hour tested under all stresses. You need statistical data on MTBF as well as comfort-zone data. That will only produce some form of confidence interval, and that confidence interval will always be less than 100%. The goal is to find the balance where you maximize the profit from the unit by keeping down the production costs, while still keeping down service costs and badwill losses. If you regularly produce 1k batches, you can't let all units in the batch run for 100 hours. The majority of units will likely run a 30 second or maybe 5 minute factory test. Letting one or even five units run 100 hour tests may not even be practical, because of the needs of climate chamber time. And how many parameters will you manage to test during a puny 100 hours? And how rough tests can be accepted and still allow the units to be sold as new? Richard said:
Yes, and the hardware should be designed to do that as well. Yes, of course. But to what degree will depend on type of product. Cost sensitivity and expected usage will greatly affect how robust it is meaningful to make the hardware. An important thing is that robust hardware adds cost to every produced unit. Robust software adds a one-off cost. So cost and volume will greatly affect the design decisions. Richard said:
Engineering should always incorporate such "features" as will make their product bullet-proof. But in real life, nothing is really bullet proof. There is always armor-piercing bullets for hard targets. Nothing survives a direct hit by lightning. The question is how "almost hit" the unit may be and survive without broken hardware. And how well it can recover from the resulting fields. It doesn't matter if the hardware survived, if the boot loader got erased when the firmware made a one-off random walk through memory. For the customer, the unit still has to be sent to the factory. |
Topic | Author | Date |
EEPROM Protection | 01/01/70 00:00 | |
No much use | 01/01/70 00:00 | |
Think about this ... | 01/01/70 00:00 | |
Robust better than correct | 01/01/70 00:00 | |
You'll get no argument from me | 01/01/70 00:00 | |
Always a balance between cost and gains/losses | 01/01/70 00:00 | |
No argument here ... | 01/01/70 00:00 | |
Shielding will not solve? | 01/01/70 00:00 | |
Magnetic fields are tricky to shield from![]() | 01/01/70 00:00 | |
Reset performance of micro is important!!! | 01/01/70 00:00 |