RAMSynapse
Log inSign up

Reliability Prediction · Chapter 4

Worked Example

The method applied end-to-end on a concrete system, with numbers.

Consider a navigation data processor for a coastal patrol craft — an electronics box in a sealed below-deck bay, naval sheltered (NS) environment, three boards: a processor board, a power supply board, and an I/O board. The programme's allocation gives the box an MTBF budget of 40,000 hours. Every rate below is an illustrative teaching value chosen to walk the arithmetic; in a real study each λg and π comes out of the handbook tables for the exact part and conditions.

The parts count pass

Board by board (rates in failures per 10⁶ h):

BoardPart classNλgπQN·λg·πQ
A · ProcessorMicroprocessor, 32-bit CMOS10.5601.00.560
A · ProcessorSRAM, 4 Mbit20.4101.00.820
A · ProcessorFlash, 64 Mbit10.4801.00.480
A · ProcessorCrystal oscillator11.2502.12.625
A · ProcessorCeramic capacitors460.00413.00.566
A · ProcessorFilm resistors380.00143.00.160
B · PowerDC-DC converter hybrid13.2001.03.200
B · PowerPower MOSFETs40.1802.41.728
B · PowerSchottky diodes60.1202.41.728
B · PowerTantalum capacitors120.06303.02.268
B · PowerPower inductors40.03003.00.360
C · I/ORS-422 transceivers60.2401.01.440
C · I/OOptocouplers80.3101.02.480
C · I/OCircular connectors, 55-pin20.5201.01.040
C · I/OBoard-edge connectors30.3101.00.930
C · I/OLED indicators50.03501.00.175

Summing per board and up to the system:

Levelλ (f/10⁶ h)Share
Board A — Processor5.21125.3%
Board B — Power9.28445.2%
Board C — I/O6.06529.5%
System20.560MTBF ≈ 48,600 h
The worked example rolled up. Three boards sum to a system rate of 20.56 failures per 10⁶ hours — an MTBF of roughly 48,600 hours against a 40,000-hour allocation. The power board owns 45% of the total, which is where the design conversation starts.
The worked example rolled up. Three boards sum to a system rate of 20.56 failures per 10⁶ hours — an MTBF of roughly 48,600 hours against a 40,000-hour allocation. The power board owns 45% of the total, which is where the design conversation starts.

The headline: λ = 20.56 f/10⁶ h, MTBF ≈ 48,600 h — the box meets its 40,000-hour allocation with about 21% margin. But the roll-up's real product is the Pareto underneath it. The power board carries 45% of the system's failure rate; within it, the switching devices and the DC-DC hybrid dominate, and the twelve tantalum capacitors contribute more than the entire processor complex. The single worst part in the box is the crystal oscillator, whose commercial-grade quality factor more than doubled its contribution. Three actionable findings from one afternoon of arithmetic — before any hardware exists.

Refining one part with the part-stress model

Now the thermal analysis arrives and reports the microprocessor's worst-case junction temperature: TJ = 88 °C. The microcircuit part-stress model is λp = (C1·πT + C2·πE)·πQ·πL. Walking it through with illustrative coefficients — C1 = 0.28 (die complexity), C2 = 0.055 (package), πE = 4.0 (NS, microcircuits), πQ = 1.0 (Class B), πL = 1.0 (mature production):

First the temperature factor, using the microcircuit form with its 0.1 coefficient and a 0.35 eV activation energy (digital MOS class):

  • 1/TJ − 1/298 = 1/361 − 1/298 = −5.856×10⁻⁴
  • −(Ea/k) × that = −(0.35 / 8.617×10⁻⁵) × (−5.856×10⁻⁴) = 2.379
  • πT = 0.1 × e^2.379 = 1.08

Then the model:

λp = (0.28 × 1.08 + 0.055 × 4.0) × 1.0 × 1.0 = 0.302 + 0.220 = 0.52 f/10⁶ h

Two things worth noticing. The part-stress result (0.52) sits close to the parts-count default (0.56) — this box's thermal design is about as good as the handbook's average assumption. And the package term (0.22) is a fixed cost the environment sets: even a perfectly cooled die keeps it.

The model earns its keep in sensitivity. Suppose a packaging change blocks the airflow and TJ climbs to 110 °C: the same arithmetic gives πT = 2.06 and λp = 0.80 — a 53% increase in the part's failure rate from 22 degrees of temperature. That is the Arrhenius lever in action, and it is exactly the kind of quantified argument that wins a thermal-design debate.

The calendar view: adding duty cycle and dormancy

The 48,600-hour MTBF above runs on the operating-hour clock. Now put the box on a real boat. The craft is underway — processor energised — about 30% of the calendar; the rest is harbour time with the system shut down in its bay. Take an illustrative dormant rate of 0.90 f/10⁶ h for the de-energised box (a few percent of the active rate, in line with dormancy conversion practice for electronics in benign stowage):

  • λ_calendar = 0.30 × 20.56 + 0.70 × 0.90 = 6.168 + 0.630 = 6.80 f/10⁶ calendar hours
  • MTBF_calendar = 10⁶ / 6.80 ≈ 147,000 calendar hours

Same box, same design, two true MTBFs — 48,600 hours against the operating clock, roughly 147,000 against the calendar — and a factor of three between them that is pure bookkeeping, not reliability. When the operator's field data eventually arrives measured in calendar time, this is the conversion that decides whether the fleet is "meeting prediction" or "missing it by 3×".

The same machinery answers mission questions directly. A 14-day patrol is 336 calendar hours at the same mix; the mission survival probability is

R = e^(−6.80×10⁻⁶ × 336) = e^(−0.00229) ≈ 0.9977

— a 0.23% chance the patrol sees a processor failure. Multiply by twelve patrols a year and the annual expectation (~2.7%) is the number the support conversation should actually be about.


Want to see this on a live system model? Request a walkthrough.