5.5.26 · D2 · HinglishEmbedded Systems & Real-Time Software

Visual walkthroughFault tolerance — fail-safe vs fail-operational

2,225 words10 min read↑ Read in English

5.5.26 · D2 · Coding › Embedded Systems & Real-Time Software › Fault tolerance — fail-safe vs fail-operational

Is page par ek hi promise hai parent note se — "redundancy ek system ko tab bhi chalata rehta hai jab koi part toot jaaye" — aur hum is maths ko bilkul scratch se rebuild karenge. End tak tumne woh curve khud draw kar li hogi jo ek aircraft engineer ko batati hai: mere triple-redundant flight computer ke 10 ghante baad bhi zinda rehne ki kitni probability hai?

Hum har symbol pehle build karte hain, phir use karte hain. Agar tumne pehle kabhi , probability, ya exponent nahi dekha, toh line one se shuru karo aur summary tak pahuncho.

Jo prerequisites kaam aayenge: Redundancy patterns (N+1, TMR, DMR), aur yeh parent topic ki child note hai.


Step 1 — "Reliability" ka matlab kya hai? Ek component ko ek aisi coin ki tarah draw karo jo time ke saath flip hoti rehti hai

KYA. Hum ek single component se shuru karte hain — ek flight-control computer. Hum ek number invent karte hain jise reliability kehte hain, likha jaata hai , jo sirf ek sawaal ka jawaab deta hai:

"Agar main ise time par on karta hoon, toh time par bhi kaam karne ki kitni chance hai?"

YEH number kyun, koi aur kyun nahi. Engineers yeh promise nahi kar sakte ki "yeh kabhi nahi tootega." Sab kuch aakhirkar toot jaata hai. Toh yes/no promise ki jagah, hum ek probability use karte hain — (impossible) aur (certain) ke beech ka ek number. matlab pakka zinda; matlab pakka dead. Hum dekhte hain ki time ke saath yeh number 1 se 0 ki taraf kaise slide karta hai.

PICTURE. Horizontal track dekho: time left se right flow karta hai. Cyan bar woh chance hai ki component abhi bhi zinda hai. par yeh poora bar fill karta hai (brand new, ). Jaise time beetha, bar shrink hoti hai — amber slice woh chance hai ki woh pehle hi mar chuka hai.

Figure — Fault tolerance — fail-safe vs fail-operational

Step 2 — "Hazard rate" : bar kitni tezi se shrink hoti hai

KYA. Hume batana hoga ki alive-bar kitni tezi se shrink ho rahi hai. Hum ek symbol introduce karte hain, == (Greek letter "lambda"), hazard rate== — failures per hour.

Padhne ka tarika: har ek ghante mein, (das hazaar mein se ek) chance hai ki yeh component us ghante mein mar jaaye.

Ek constant kyun. Electronics ke normal life mein (infant-mortality ke baad, wear-out se pehle), "is ghante" marne ki chance age par depend nahi karti — ek 3-ghante-purana chip ek 1-ghante-purane chip se zyada thaka nahi hota. Yahi memoryless property hai jo ko ek fixed number rehne deti hai. Dekho Watchdog timers and health monitoring ki hum field mein failures actually kaise measure karte hain.

PICTURE. Har ghante hum jo bhi alive-bar bachi hai usse same fraction kaat lete hain. Ek fixed amount nahi — ek fixed fraction. Steps dekho: har drop current bar ka ek slice hai, isliye drops physically chhoti hoti jaati hain jaise bar shrink hoti hai.

Figure — Fault tolerance — fail-safe vs fail-operational

Step 3 — kyun aata hai (aur yahan kya kar raha hai)

KYA. Same fraction ko baar baar, aur baar baar barikhi se kaatne par exactly ek hi curve banti hai:

Hum har symbol earn karte hain.

  • = rate time = time tak accumulated decay ki total amount. Agar /h aur h, toh .
  • Minus sign kehta hai decay bar ko shrink karta hai.
  • (Euler's number, ) woh natural base hai jo tab bhi aata hai jab koi cheez apne current size ke ek fixed proportion se change hoti hai. Yahi Step 2 ki picture hai exactly.

kyun, say, kyun nahi? Kyunki decay continuous hai — coin har ghante ek baar flip nahi hoti, yeh "flip" har pal ho rahi hai. Agar tum "fraction lose karo" ko ever-smaller time slices mein apply karo aur slices ko zero tak jaane do, toh limit hai. Yeh repeated fractional loss ka smooth version hai.

PICTURE. Step 2 ki staircase, smoothly ek curve mein convert hui. Height se shuru hoti hai, shuru mein sabse tezi se girти hai, aur zero ko hug karti hai (lekin kabhi touch nahi karti). Amber dot hamare example ko mark karta hai: par, height hai.

Figure — Fault tolerance — fail-safe vs fail-operational
Single-unit failure chance
ki value /h, h ke liye

Step 4 — Teen computers: sab tarike draw karo jinse woh ji ya mar sakte hain

KYA. Triple Modular Redundancy (TMR) teen identical units aur ek voter use karta hai — ek chhota circuit jo teeno answers leta hai aur jo majority kehti hai woh output karta hai. System "alive" tab tak hai jab tak kam se kam 2 of 3 units kaam kar rahi hain (voter ko do agreeing votes chahiye).

ek unit ke time par dead hone ki chance hai, aur iske alive hone ki chance (note ).

2-of-3 kyun. Ek akeli healthy unit par akela trust nahi kiya ja sakta — agar yeh ek tooti unit se disagree kare, toh voter nahi bata sakta kaun sahi hai. Do agreeing units ek liar ko out-vote kar dete hain. Toh humein alive chahiye.

PICTURE. 3 units ke har possible outcome ka ek tree — har branch alive (cyan) ya dead (amber) hai. Kul aath leaves. Framed leaves (all-3-alive, aur teeno 2-alive cases) woh hain jahan system survive karta hai.

Figure — Fault tolerance — fail-safe vs fail-operational

Step 5 — Binomial se survivor branches count karo

KYA. Hum framed branches ko jod lete hain. Yeh choose karna ki kaun si units survivors hain — kitne tarike hain — ("3 choose ") se likha jaata hai — kitne distinct leaves mein exactly alive hain.

System survive karta hai agar 3 alive ya exactly 2 alive:

aur substitute karo:

Probabilities multiply kyun karte hain. Teen units independently fail hote hain (alag chips, alag power lines — dekho Common-mode failures and diversity jab yeh assumption toot jaaye). Independent events ki joint probability product hoti hai: .

PICTURE. Do stacked reliability curves: single unit (thin cyan) aur TMR (thick cyan). Notice karo TMR pehle single curve ke upar rehti hai, phir zyada right mein neeche chali jaati hai.

Figure — Fault tolerance — fail-safe vs fail-operational

Step 6 — Early-life win: real numbers plug in karo

KYA. Aircraft ko flight ki parwah hoti hai, jo component ki life mein early hoti hai ( chhota). lo (yani ):

TMR ke liye term by term:

  • → teeno ke survive karne ki chance.
  • → exactly ek ke marne ki chance.
  • Sum .

Failure chance (single) se (TMR) tak gir jaati hai — jahan zaroori hai wahan lagbhag 4× safer.

Yeh yahan kyun kaam karta hai lekin baad mein nahi. Pehle, ek doosri failure rare hoti hai (dono ko marna hoga), isliye pehli failure ko tolerate karna almost free pass hai.

PICTURE. Step 5 ke plot ka left mein zoom. top line tak do amber gaps: single-unit gap bada hai (), TMR gap chhota hai ().

Figure — Fault tolerance — fail-safe vs fail-operational

Step 7 — Surprising long-run twist (degenerate case)

KYA. Mean Time To Failure (average lifetime) paane ke liye ko sab time par integrate karo:

Lekin ek single unit ka MTTF hai. Toh:

Teen units ki average life ek se CHHOTI hoti hai!

Yeh contradiction kyun nahi hai. Saare time par average karo toh TMR haarta hai — kyunki bahut baad mein, 2-of-3 survive karna 1-of-1 se mushkil hota hai (pehle se hi zyada cheezein toot chuki hain, aur koi repair nahi). Lekin hum infinity tak fly nahi karte. Finite mission window par jo matter karta hai, TMR kaafi safer hai (Step 6). Yeh Step 5 ki do curves ka crossing point hai.

PICTURE. Do curves cross ho rahi hain. Crossing ke left (short missions): TMR upar = safer. Uske right (long unattended life): single upar. Amber vertical line crossover mark karta hai.

Figure — Fault tolerance — fail-safe vs fail-operational

Ek-picture summary

Is final drawing mein saaton steps compress hain: ek shrinking bar () se, 2-of-3 branch count tak, do crossing curves aur early-life safety gain tak.

Figure — Fault tolerance — fail-safe vs fail-operational
Recall Feynman retelling — apne plain words mein bolo

Ek single computer ke abhi bhi zinda rehne ki chance 1 se shuru hoti hai aur ek smooth curve se neeche slide karti hai, jahan hai kitne failures per hour hote hain aur hai kitna "decay" pile up hua hai. Curve -shaped hai kyunki cheez har pal jo bacha hai uska same fraction lose karti hai — bilkul ek savings account ki tarah jo fixed percent bleed kare.

Ab teen identical computers ek voter ke peeche rakho jo majority par trust karta hai. System tab tak jeeta hai jab tak do of teen zinda hain. Main teen coins ke lande ka poora aath-way tree list karta hoon, chaar ko rakhta hoon jahan kam se kam do alive hain, aur unki probabilities add karta hoon — multiply karke kyunki units independently fail hote hain. Is se milta hai .

Life mein pehle yeh triple system kaafi safer hai: par failure chance se tak gir jaati hai. Lekin saare time par integrate karo aur TMR ki average lifetime sirf hai — single unit ke se chhoti! Koi paradox nahi: redundancy long-run average life ko short-run safety ke liye trade karti hai. 10-hour flight par — jahan mission per safety hi sab kuch hai — exactly yahi trade hum chahte hain.


Related deep prerequisites & extensions: Byzantine fault tolerance (jab ek faulty unit die hone ki jagah jhooth bolta hai), Real-time scheduling with fault recovery, Hardware safety mechanisms, aur Formal verification of safety properties.