Hardening of firmware

Hi Cpt. Vince and Per,

Many thanks to your explanations. Your explanations are very logical.

Due to my limited English ability and professional knowledge, I only mentioned the temperature factor, but in fact, something else should be considered, I did some Google search and found that, what I thought is more like the Aging Test. (It shows that, "American Society for Testing and Materials" owns a lot of data about Aging Test). It is hard to say if the Global Climate Change does bring some impacts on Materials Aging. But it does bring some impacts to Human Health.

Hi Cpt. Vince and Per,

Many thanks to your explanations. Your explanations are very logical.

Due to my limited English ability and professional knowledge, I only mentioned the temperature factor, but in fact, something else should be considered, I did some Google search and found that, what I thought is more like the Aging Test. (It shows that, "American Society for Testing and Materials" owns a lot of data about Aging Test). It is hard to say if the Global Climate Change does bring some impacts on Materials Aging. But it does bring some impacts to Human Health.

I am not sure what you mean exactly, but of course there is an issue of data retention of non-volatile memory such as EEPROMs. the effect of aging of data stored on them is normally very well documented in the respective data sheets.

Regarding: Materials Aging

Another thought ...

I have not seen any mention of firmware ageing.

Do loops get slower as they get older?

No, the loops don't get slower. But it is a well known fact that the quality of the compiled binaries or untouched source code degrades with time.

Code that has worked for years will suddenly start to misbehave. Code that has passed validation tests will suddenly stop doing it, so the age factor is important.

That is why so many developers are so very scared of inheriting old and trusted code. The manager says: You don't have to worry - we haven't needed to release an update in five years. The next week you get two customers with problems. Within a couple of months, a significant percentage has a problem. And despite not having touched the code, the new developer gets the blame since the problems started after he took over the responsibility. Now is the time for the poor *** to find out that the original compiler was not stored in the source code repository, or has a license registration method making it impossible to reinstall, and that the last code changes five years ago somehow wasn't commited...

An aging plastic IC package might cracks, and leads to some open/short problem, I guess.

There are a huge number of problems you can get with hardware.

- Oxidation with socketed components or with connectors - in some cases melt-downs because the contact resistance gets too high.
- Wet capacitors drying out (normally from high temp).
- Tantalum capacitors exploding because they have been run out-of-spec.
- Metal fatigue in bonding threads inside the chips.
- Electromigration in chips, power transistors or switch regulators because they have run at high currents and high temperature for a long time.
- Solder joint whiskers.
- Metal fatigue in solder joints.
- Factories that hasn't baked components, getting moisture crack the chip.
- ESD damages (a damage in the factory can take months or years until the failure).
- Damaged conformant coating, resulting in leak currents or possibly PCB traces being corroded until they break.
...

The problem is to try to decide what hardware failures that should be possible to detect and what work-arounds there should be in the firmware. Is it enough to warn about a problem or is the failure critical, requiring the unit to "brick" itself? Should there be redundant hardware? What is the probability of producing incorrect results? What will happen if incorrect results are produced? What will happen if no results at all are produced? What is required by the certification?