Question bank — Fault tolerance — fail-safe vs fail-operational

False — "safe" contextual hai. Aircraft mein cruise ke dauran, shutdown (fail-safe move) dangerous option hai; wahan function ka loss degraded function se bura hai, isliye fail-operational safer design hai.

False — jab redundancy finally exhaust ho jaaye uss case ke liye isko ek safe state chahiye. Hybrid designs (jaise insulin pump) transient faults ke through operational rehte hain, phir jab fault persist kare toh fail-safe shutdown par fall back karte hain.

False — TMR $\text{MTTF}=\frac{5}{6\lambda }$ deta hai, jo ek single unit ke $\frac{1}{\lambda }$ se kam hai. TMR early-life reliability mein jeetta hai, long-run average lifetime mein nahi.

False — $\beta$ total failure rate $\lambda$ ko bilkul nahi badalta; ye sirf kis tarah ki failure hoti hai woh change karta hai, dangerous failures ko detected safe ones mein convert karta hai.

False — identical channels har common-mode failure share karte hain (same software bug, same power rail). Ek design bug ke khilaf, teen identical units ek unit ki tarah hi vulnerable hain.

False — detection continuation nahi hai. Ek watchdog typically reset ya safe state force karta hai; woh fail-safe reaction hai jab tak ek redundant unit function ko alive nahi rakhta.

False — availability $A$ measure karta hai up aur operational hone ko, correct hone ko nahi. Ek system highly available ho sakta hai while subtly wrong outputs produce karta rahe; isliye hum dangerous-failure rate alag track karte hain.

False — passive-safe safety kuch na karke reach karta hai (power down, disconnect, spring REST par kheench jaati hai); active-safe ko kuch karte rehna padta hai (brakes clamped hold karna). Active-safe ko ek working actuator chahiye, isliye usse guarantee karna mushkil hai.

Software par command karne ki dependency hi flaw hai. Truly fail-safe matlab brake power/signal loss par bina software ke act kiye engage ho — ek spring-loaded, energize-to-release brake. Agar CPU jo "command" dene wala hai woh khud dead hai, toh kuch engage nahi hoga.

Gain 99% se kahin zyada bada hai. Dangerous rate $(1-\beta )\lambda$ hai, isliye $\beta =0.99$ dangerous rate ko 100 se divide karta hai, Mean Time To Dangerous Failure mein roughly 100× (do orders of magnitude) improvement deta hai, 99% nahi.

TMR sirf ek failure tolerate karta hai. Majority voter ke saath, do failed units ek acche unit ko outvote kar dete hain, isliye system doosri fault par fail ho jaata hai. Teen units single-fault tolerance dete hain, double nahi.

Voting independent faults ke khilaf protect karta hai identical software mein. Shared voting/software logic mein bug ek common-mode failure hai jo teeno mein present hai; majority voting ek defect ko outvote nahi kar sakta jise woh sab share karte hain. Isliye dissimilar (diverse) backup exist karta hai.

Parent note ke according galat — Direct Law abhi bhi software-driven fly-by-wire hai (stick directly surfaces se map karta hai, envelope protection minus). Sirf mechanical backup rudder + trimmable stabilizer hai steady karne ke liye, full manual flight ke liye nahi.

Ye ek hybrid hai. Ye sirf transient faults ke liye cross-checking processors ke zariye operational rehta hai; persistent faults ke liye ye deliberately fail-safe ban jaata hai delivery rok ke aur alarm karke, kyunki wrong dose fatal ho sakta hai.

Ulta hai. Safe default RED hai; agar initialization ya koi fault variable ko untouched chhod de, toh use harmless state par land karna chahiye. GREEN ko default karne ka matlab hai ek uninitialized ya stuck system "go" dikhata hai — dangerous outcome.

Kyunki ek detected failure safe state trigger kar sakta hai, toh woh dangerous rehna band ho jaata hai. $\beta$ badhana probability mass ko $(1-\beta )\lambda$ dangerous stream se $\beta \lambda$ safe stream mein shift karta hai, dangerous rate ko shrink karta hai aur MTTDf ko multiply karta hai.

Ye opposite directions mein pull karte hain: fail-safe kisi bhi doubt par rokna chahta hai, fail-operational chalte rehna chahta hai. Tum simultaneously rok aur continue nahi kar sakte, isliye real systems function ke hisaab se strategy choose karte hain ya ek hybrid stage karte hain (kuch der operate karo, phir safe par fall karo).

Ek unit ke marne ke baad function continue karne ke liye, tumhe doosra unit ready chahiye usse carry karne ke liye — wahi redundancy hai. Safely rukne ke liye, ek single passive mechanism (spring, de-energizing relay) kaafi hai; function ko alive rakhna zaroori nahi.

Identical copies common-mode failures share karte hain — ek design bug ya ek shared power fault unhe sab le jaata hai. Diverse implementations ek hi wajah se fail hone ki possibility nahi rakhte, isliye woh failure class cover karte hain jo pure replication nahi kar sakta.

Shuruaat mein, unit failures rare aur independent hoti hain, isliye voter ke paas almost hamesha healthy majority hoti hai — bada reliability boost. Jaise time badhta hai, doosri failure ki probability bhi badhti hai aur eventually redundant system ek long-lived unit par bet karne se bura ho jaata hai (isliye lower MTTF).

MTTF reliability curve ke neeche area hai, ${\int }_0^{\infty }{R}_{\text{sys}}(t)dt$, jahan $R_{\text{sys}}=3e^{-2\lambda t}-2e^{-3\lambda t}$ (probability ki kam se kam do units abhi bhi kaam kar rahi hain). Term by term integrate karne par $\frac{3}{2\lambda }-\frac{2}{3\lambda }=\frac{9-4}{6\lambda }=\frac{5}{6\lambda }$ milta hai — two-failure "wait" single unit ke $\frac{1}{\lambda }$ se kam contribute karta hai, isliye TMR ki average life shorter hai.

Availability answer karta hai "kya ye chal raha hai?"; dangerous-failure rate answer karta hai "jab ye act karta hai, kya ye harmfully act kar sakta hai?" Ek system ek par high aur doosre par badly score kar sakta hai, isliye ek single number us failure mode ko hide kar deta hai jo actually logon ko maar deta hai.

Specification demand karta hai safe state within deadline reach karo probability $\ge 1-ϵ$ ke saath; boundary instant $t_f+\Delta t_{max}$ ko "in time" include kiya jaana chahiye. Koi bhi design jo sirf usually pahunchti hai, ya $\Delta t_{max}$ se slip karti hai, safety claim violate karta hai.

Redundancy exhaust ho jaati hai, isliye woh voting se safely continue nahi kar sakta. Ek well-designed system ise detect karta hai aur ek defined safe state (ya best-effort degraded mode) par fall back karta hai; ek ill-designed system silently unchecked, possibly dangerous, output produce karta rehta hai.

Model mein ${\lambda }_d=(1-\beta )\lambda =0$, isliye MTTDf $=1/{\lambda }_d\to \infty$ — dangerously optimistic. Reality mein $\beta =1$ unachievable hai; kuch failure modes detection se bach jaate hain ya detector khud fail ho jaata hai, isliye true dangerous rate chhoti hai lekin exactly zero kabhi nahi.

DMR disagreement detect kar sakta hai lekin decide nahi kar sakta ki kaun sa channel faulty hai — tie todne ke liye koi majority nahi hai. Safe response usually fault declare karna aur safe state par jaana hai, isliye DMR alone fail-safe hai, fail-operational nahi.

Uske paas switch karne ke liye koi healthy backup nahi hai abhi, isliye vulnerable window ke dauran use ya toh outputs inert hold karne hain ya safe state default karna hai jab tak saare channels confirmed live na ho jaayein — startup ko temporarily non-operational phase treat karna.

Optimistic — binomial/TMR formulas independent failures assume karte hain. Koi bhi shared cause real simultaneous failures ko maths ki prediction se zyada likely banata hai, isliye true reliability kagaz par number se buri hoti hai.

Nahi — perfect safety kabhi bhi uncertain hone par act na karne ki zaroorat padegi (shutdown favour karte hue), jabki $A=1$ ke liye kabhi down na hona zaroori hai. Real design ek ko doosre ke against trade karta hai; "sahi" balance depend karta hai ki lost function ya wrong function zyada bada nuksaan hai.