Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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.

List of 10 messages in thread
TopicAuthorDate
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      

Back to Subject List