for how long can a PIC work? - Page 1
Forum section: electronics / projects

author: diegoterc3
author_rank: Regular Contributor
timestamp: December 18, 2013, 06:08:40 am
content: Hello. I have been working on a proyect which it is just automating a discharge for a Pb battery. I am using a DS1307 and a PIC16F84. It works. Every week on monday at 5am it turns on the lights and the battery discharges. The owner of the company says he wants the warranty to be up to to years and I really haven't tested a circuit for that long. My question is: how can I calculate the time that the PIC will work? I need it to work for at least 3 years straight . How can I back up this information to put it in my final paperwork? Thank you in advance

author: prenato
author_rank: Regular Contributor
timestamp: December 18, 2013, 06:25:49 am
content: You might be able to get MTBF data from Microchip (Mean Time Between Failures). Most semiconductor companies provide reliability data for the chips but beware this is a sensitive topic because of liability so the info is not always forthcoming... Some companies call it a "quality" or "reliability" report.

author: Jon86
author_rank: Frequent Contributor
timestamp: December 18, 2013, 06:51:20 am
content: MTTF (YRS): 168453 for the DS1307, so you're probably alright thereI can't find anything on the PIC, though.

author: KJDS
author_rank: Super Contributor
timestamp: December 18, 2013, 07:04:00 am
content: The theoretical failure rates of semiconductors is usually negligible unless they are being stressed close to their operating limits, particularly junction temperature.Usually solder joints, cables, poor quality components from dodgy sources, poor design, dirt, coffee, switches, vibration and leaky caps are what actually kills equipment

author: pickle9000
author_rank: Super Contributor
timestamp: December 18, 2013, 07:12:06 am
content: If you have any electrolytics involved I'd start there.

author: IanB
author_rank: Super Contributor
timestamp: December 18, 2013, 07:25:31 am
content: I think the battery will fail long before the electronics...

author: Psi
author_rank: Super Contributor
timestamp: December 18, 2013, 08:17:46 am
content: If you want to increase lifespan the following things will help- Replacing all electrolytic caps with high quality good brand 105 Deg C caps, or remove electrolytics entirely- Add a TVS diode to the power input to absorb any spikes. You can also add 5V TVS diodes to any external 5V I/O for extra protection from external spikes.- Make sure the device is inside a weather proof container, or at least protected from the environment- Use leaded solder, lead free has the risk of tin whiskers- Coat the PCB with protective circuitboard lacquer or get it conformal coated- Locate the battery away from the PCB so if it corrodes it wont damage the PCB

author: jorisbeurden
author_rank: Newbie
timestamp: December 18, 2013, 08:27:15 am
content: Quote from: Psi on December 18, 2013, 08:17:46 amI thought that conformal coating prevented tin whiskers, made the PCB sort of weather proof and protected it (partially) from corrosion. I think you can even get spray cans of the stuff. I don't have any experience with it but I looked into using it for a project a while back.

author: Rerouter
author_rank: Super Contributor
timestamp: December 18, 2013, 10:23:16 am
content: not sure if the chemical used in the coating has changed, but I've had to repair some old electronics that had a large number of whiskers form where a hot component caused it to bubble slightly,

author: Psi
author_rank: Super Contributor
timestamp: December 18, 2013, 11:42:00 am
content: A thick conformal coating can stop tin whiskers forming, but for a general coating it only slows them down.They can definitely punch through the coating if the thickness is marginal

author: dannyf
author_rank: Super Contributor
timestamp: December 18, 2013, 12:04:45 pm
content: QuoteIn general, a mcu can last for an instant to practically infinity, depending on the hardware / software design.I don't think there is a way for you to "calculate".

author: muvideo
author_rank: Frequent Contributor
timestamp: December 18, 2013, 12:16:46 pm
content: Hello,I agree with what has been written before.You should also take in account data retention in flash memory(and EEPROM if you ise it).It strongly depends on operating temperature, if I remembercorrectly microchip published some notes on this topic.3 years should be no problem, unless you run the chip at100°C, but then you would have other problems

author: nctnico
author_rank: Super Contributor
timestamp: December 18, 2013, 12:56:50 pm
content: Another important factor is ESD. You should take every precaution to prevent ESD during the production and assembly process because it is a major cause of early failures.

author: prenato
author_rank: Regular Contributor
timestamp: December 18, 2013, 02:05:31 pm
content: I agree wit the good advice above. Seems the OP needs to document/ calculate the expected reliability . For that, he might need some data for each of the components and perform some calculations. There are ways to do that of course:http://www.reliabilityeducation.com/intro_mil217.htmlAs noted by several people, the PIC is not likely the worst offender in his board, but he might need to justify that with data which is where MTBF / FIT info is useful.

author: calexanian
author_rank: Super Contributor
timestamp: December 18, 2013, 03:04:26 pm
content: We have product in field using PIC F type chips, and C type before that for 20 years now. No problems to speak of. Just be sure you have good brownout management and power on reset is done well. If your human interface is hard wired or physical switches, etc, I might suggest a full initialization on brown out recovery or power up to keep things clean. Apart from that use good manufacturing practices. Clean your boards, conformal coating, (I would not recommend potting if you intend on warranty repairing them) Seal up the enclosure really well, oh, and dont forget some hold up caps around the micro. Brownout/battery dying conditions play havoc with things.Sounds like a fun simple project. Its all in the engineering and production. Hell, we could have done it in the time it took to write this thread O0

author: grumpydoc
author_rank: Super Contributor
timestamp: December 18, 2013, 04:40:02 pm
content: If I understand the OPs request correctly he has designed a widget and his boss wants some sort of statement as to the reliability for warranty purposes.QuoteThe figure they might be able to give you is the MTTF - Mean TimeToFailure - MTBF is specified for sysems which are repaired when they fail and, on the whole, single chips aren't repaired.As noted for the DS1307 individual chip MTTFs tend to be rather long since they are inherently pretty reliable.Even if you know the MTTF of all your components you can't easily combine them into an MTBF for your product. At one level you can a little - after all it's just the arithmetic mean of the times to failure so if you knew the sample size you could easily combine two figures. One catch is that you don't know the sample size but you could just assume it is equal and combine two items with MTTFs of 5 years and 10 years and say that a system which uses both has a MTTF of 7.5 years.Unfortunately as KJDS points out, you have a whole host of other factors to do with your design and construction which you dont know and can't easily find out or haven't measured. The MIL217 document lists some of the typical adjustment factors for failure rates which you might have to think about applying.Even then the weakness of MTBF is that it doesn't tell you how the failures are distributed in time. In fact it sort of assumes they are linear but real failure often aren't like that. Something like a resistor probably does have a fairly constant failure rate with time. Other items might decline gradually until they need replacement (eg a rechargeable battery) generally with some variation in lifetime. Still others might be totally OK and then fail catastrophically with increasing chance of failure as time goes by (think lightbulb).This means that failures occur according to the classic "bath tub" curve - there is a high number of early failures due to manufacturing problems, followed by a decline to relatively low levels, then gradually climbing with time as components start to fail with age.MTBF tells you most if it is comparatively short compared with the replacement cycle time of the item - if I have 1000 of your widgets and a replacement cycle of 10 years then an MTBF of 5 years means I can reasonably expect to see (and budget for) 2000 repairs. If the MTBF is 20 years I'm not quite going to be sure whether that means I'll see 500 failures or none. If the MTBF is very long e.g. some hard disk drives have quoted MTBF's of more than 1 million hours, it's much more useful to know what the percentage failure per year of service is - but the drive manufacturers won't tell you that, even if they know it.Back to your question - your boss basically wants to know "if I make 10,000 of these things and give a two year warranty how many do I have to figure on replacing" - it's a bit like the maintenance cost question but with a pretty short life cycle (the warranty period).It's going to be difficult without actually making a few (hundred) and taking some real measurements of how yoursystembehaves. You might be able to get somewhere looking at the individual component MTTF's although doing so will overestimate your system's MTBF. It will, at least, be better than guessing (possibly not by much though).One thing you can't do is say "there will definitely be no failures in 2 years", or three for that matter because there willalwaysbe an early failure rate.Have fun!

author: madires
author_rank: Super Contributor
timestamp: December 18, 2013, 05:27:42 pm
content: Using MTBF for describing the reliability is a flaw by itself because MTBF = MTTF + MTTR (Mean Time To Failure + Mean Time To Repair). A MTBF of 10 years could be a MTTF of 1 day and a MTTR of 10 years minus 1 day ;-) Simply marketing glibberish!

author: Dajgoro
author_rank: Frequent Contributor
timestamp: December 18, 2013, 06:04:08 pm
content: I built a hobby project led clock back in 2011, with point to point soldering, were the main chip is the PIC16F877. The thing has been working since then 24/7 without any issues, and since the leds(14x 7 segment displays) are not multiplexed, the 7805 inside has to regulate a lot of power, so the entire clock is sorta hot, but it still works.Edit: The clock doesn't contain a RTC chip, but a 4060 32.768kHz oscillator.

author: AG6QR
author_rank: Frequent Contributor
timestamp: December 18, 2013, 06:17:05 pm
content: I've had some PIC 16F84 and 16F628 chips working on my home automation system for the past 11 years, 24/7 except for brief power failures. There was one device of my own design that had one I/O pin fail a few times after a few years' use each time. I put better ESD protection on that pin and it's ok now. Those have been the only failures I've experienced.I'd agree with the others that the PIC chips themselves are unlikely to be the point of failure, assuming reasonable design practices to protect from ESD.Generally speaking, if an electronic device survives the first three or four months in continuous use, it's probably going to survive the first five years. Most companies provide one year or three year warranties, and for most electronic products, I'd guess the difference in cost to the issuing company is very small, because there aren't many failures after one year but before three.Incidentally, that's one reason why those extended warranties which retailers often pressure you to buy are such a profit maker for the sellers. The manufacturer's warranty already covers the "infant mortality" portion of the bathtub curve, and the extended warranty doesn't extend off far enough to cover the end-of-life issues. The extended warranty covers only the lowest portion of the bathtub curve, where there are very few failures.

author: SeanB
author_rank: Super Contributor
timestamp: December 18, 2013, 06:57:16 pm
content: Tens of thousands of alarm panels use PIC controllers in them, and they last for decades in use doing what is regarded as a life and safety function. One or more in the control cabinet, one per passive and one per keypad.

author: penfold
author_rank: Frequent Contributor
timestamp: December 18, 2013, 07:52:36 pm
content: The big thing that jumps out here is the fact that the system is centred about a PIC, running software. This introduces the slightly un-estimate-able world of software reliability. If you initially assume that your software is entirely correct and spot on what you intended, then there is the world of sporadic jumps and bit-flips to watch out for. The majority of those problems can be solved with a watchdog timerFor reliability-critical systems I've always managed to keep on 'hardware only' systems so can't elaborate too much on the software issues.

author: Pezo
author_rank: Newbie
timestamp: December 18, 2013, 08:55:20 pm
content: Quote from: grumpydoc on December 18, 2013, 04:40:02 pmI have to strongly disagree with this.This sort of logic would mean: if I had a device with an MTTF of 1 day and a whole bunch of devices with say 1 year, the MTTF of the whole system would be close to 1 year.That's just wrong, if you have more devices that can fail, it can only get worse. Mind you, I have no idea how to calculate reliability, I just know it doesn't work like that.First post btw, I hope I'm not making enemies already

author: grumpydoc
author_rank: Super Contributor
timestamp: December 18, 2013, 09:57:06 pm
content: QuoteI did start that paragraph by noting that you can't easily combine individual MTTF's so was just thinking of the situation where the MTTFs are similar anyway - your example does show that if they are wildly different it doesn't work anymore.

author: dannyf
author_rank: Super Contributor
timestamp: December 18, 2013, 10:52:18 pm
content: The probability of failure (failure rate) for a group of parts is the joint probability of individual failures.For the exponential failure distributions, it is fairly easy to combine the individual mtbf to calculate the group's mtbf.The math is not difficult at all and you can do it.

author: KJDS
author_rank: Super Contributor
timestamp: December 18, 2013, 11:09:08 pm
content: The MTTF is given as FITs, that is the number of failures in 10^9 hours.You can just add them all up and use that to get the MTBF, however it is normal to modify the FIT of each component due to an assortment of factors given in Mil HDBK 217F.The MTBF given bears no relationship with reality.

author: G0HZU
author_rank: Super Contributor
timestamp: December 18, 2013, 11:11:37 pm
content: Quote from: Jon86 on December 18, 2013, 06:51:20 amThe datasheet for the DS1307 says it is only valid to the year 2100 for leap years. So it would get the date wrong but presumably it would still get the 'day' correct? But I guess it might be a bit late to complain to the original designer by then...Seriously though, the first question I would ask is how accurate the timing needs to be for each Monday at 5am. If you don't use an accurate clock in the design then it could easily be wrong by several minutes within a year. So that could count as a system fail even if all the parts are still healthy and working to their spec on their individual datasheet.

author: dannyf
author_rank: Super Contributor
timestamp: December 18, 2013, 11:11:54 pm
content: QuoteLet's say that you have a system of two parts: Part 1 has a mtbf of 1 day and Part 2 has a mtbf of 1 day too.Q: What's the mtbf of the system?

author: prenato
author_rank: Regular Contributor
timestamp: December 19, 2013, 12:13:13 am
content: Quote from: dannyf on December 18, 2013, 10:52:18 pmSomething like this?http://www.theriac.org/DeskReference/viewDocument.php?id=219

author: grumpydoc
author_rank: Super Contributor
timestamp: December 19, 2013, 08:09:43 am
content: QuoteD'oh, yes - I was hung up with the idea of combining the means (which doesn't work for all sorts of reasons).I shouldn't try to think about this stuff when distracted by the day jobThat's assuming you know the probability of individual failures and you still need to factor in all the modifiers and extra sources of unreliability for your own project though.