Component datasheets rarely quote reliability as a lifetime in years; instead they use a compact unit that lets tiny failure rates be written as whole numbers. That unit is the FIT rate, short for failures in time, and it counts how many failures a device would produce across an enormous span of operating hours. Because it is additive and standard across the electronics industry, FIT is the natural currency for building up the reliability of a board or a system from its parts. This page defines the FIT rate, shows how to convert between FIT, the failure rate lambda, and mean time between failures, and explains how component FIT figures roll up into a board or system failure rate.
FIT rate (failures in time) in one line: A FIT rate, or failures in time, is a failure rate expressed as the number of failures expected per one billion device-hours of operation, so one FIT means one failure in a billion hours. It is simply the failure rate lambda scaled to that large time base, which lets very small rates be written as convenient numbers, and it is the inverse relationship to mean time between failures. Because FIT rates for constant-rate components add together, you can sum the FIT of every part on a board to get the board's total FIT and failure rate.
The FIT rate answers a scaling problem. The failure rate of a good electronic component is so low that expressed per hour it is an awkward string of leading zeros, so the industry chose a billion device-hours as the reference span. One FIT is one failure per billion hours of operation, and a part rated at, say, a few hundred FIT is one that would be expected to produce that many failures if you ran a billion hours of it, whether that is one part for a billion hours or a billion parts for one hour. Writing reliability this way keeps datasheet numbers readable while still describing extremely reliable parts.
FIT is just the failure rate, lambda, in different clothing. Lambda is the number of failures per hour, and FIT is lambda multiplied by one billion, so converting between them is only a matter of moving the decimal by that scale factor. The link to mean time between failures follows directly, because for a constant-rate part MTBF is the reciprocal of lambda. To go from FIT to MTBF you take one billion and divide by the FIT rate, giving the mean time in hours; a lower FIT means a longer MTBF and a more reliable part. These three, FIT, lambda, and MTBF, are three views of the same underlying rate.
The conversions rest on the assumption of a constant failure rate, the flat middle of the classic bathtub curve where failures happen randomly rather than through infant mortality or wear-out. Within that regime the reciprocal relationship between rate and mean time holds cleanly and FIT figures behave predictably. It is worth remembering that MTBF derived from a FIT rate is a statistical mean over a large population, not a promise that a given part will last that long, and it applies to the random-failure period, not to the end of a part's life when wear-out takes over.
The reason FIT is so useful is that it adds. For a set of components in series, meaning any one failure takes the assembly down, and each failing at a constant rate independently of the others, the failure rates simply sum. So the FIT rate of a whole board is, to a first approximation, the sum of the FIT rates of every component on it: resistors, capacitors, connectors, integrated circuits, and the rest. Add them and you have the board's total FIT, from which you can get the board's lambda and its predicted MTBF by the same conversions used for a single part.
Building a system estimate is then a bookkeeping exercise. You list every component, look up or estimate each one's FIT rate, multiply by how many of that component appear, and total the lot. A connector type contributing a small FIT each, present twenty times, contributes twenty times its unit FIT. The grand total is the system FIT, and it immediately shows which components dominate the failure budget, because the parts with the highest FIT-times-quantity are the ones worth attention. This additivity is what makes FIT the working unit of parts-count and parts-stress reliability prediction.
Two cautions keep the roll-up honest. First, the simple sum assumes a pure series arrangement; where redundancy exists, so that a failure is tolerated by a backup, the math is no longer a plain addition and a reliability block or Markov analysis is needed instead. Second, the FIT values themselves usually come with an implied environment and stress level, so a datasheet FIT quoted at benign conditions understates the rate for a part run hot or in a harsh location. A credible system FIT applies the right environmental and stress adjustments before summing, rather than treating every quoted FIT as directly comparable.
A FIT rate from a datasheet is a prediction, and the value of field operation is that it lets you check that prediction against reality. If you know how many units of a device have been running and for how many accumulated hours, and how many failed, you can compute an observed field failure rate and express it in FIT to compare directly with the datasheet figure. Field FIT rates commonly come out higher than the optimistic datasheet numbers, because real environments, thermal cycling, and handling add stresses the ideal figure did not include, and knowing the gap on your own equipment is genuinely useful for spares and maintenance planning.
Gathering the operating hours and failure counts needed for a field FIT is exactly what a control or SCADA system is good at. Runtime accumulation, power-on hours, and event or fault logs give the denominator and numerator of the rate without manual tallying, and doing so across a fleet gives enough device-hours to make the estimate meaningful, since a single unit rarely accrues a billion hours on its own. A cloud SCADA platform such as Merobix can consolidate this history from many dispersed devices and sites, turning scattered runtime and fault records into the population data a real FIT estimate needs.
The practical payoff is closing the loop between predicted and observed reliability. A predicted system FIT tells you where the design expected trouble; the field FIT tells you where trouble actually is, and a large divergence flags either an environment harsher than assumed or a part performing worse than its datasheet. Trending failures over time can also reveal a rising rate that signals the onset of wear-out, at which point the constant-rate FIT model no longer applies and the population is heading out of its useful-life plateau. Used this way, FIT is not just a design-time number but a running measure that field monitoring keeps grounded.
Because a FIT rate is failures per billion device-hours, you convert to mean time between failures by dividing one billion by the FIT rate, which gives the MTBF in hours. A lower FIT rate therefore corresponds to a longer MTBF and a more reliable part. The conversion assumes a constant failure rate, so the resulting MTBF describes the random-failure period, not the wear-out end of the part's life.
Yes, for components arranged in series and failing independently at constant rates, the FIT rates add directly, so the total FIT of a board is the sum of the FIT of all its parts times their quantities. This additivity is what makes FIT the working unit for parts-count reliability prediction. It breaks down where there is redundancy, since a tolerated failure is no longer a simple series contribution and needs a reliability block or Markov model instead.
Datasheet FIT values are usually quoted at benign reference conditions and reflect an idealized environment, whereas field operation adds thermal cycling, vibration, humidity, and handling stresses that raise the real failure rate. As a result the FIT observed from actual operating hours and failures on your equipment often exceeds the published figure. Measuring your own field FIT, using accumulated runtime and fault data, gives a more realistic basis for spares and maintenance decisions than the datasheet alone.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.