5.5.25 · D5 · HinglishEmbedded Systems & Real-Time Software
Question bank — Redundancy — TMR (triple modular redundancy), voting logic
5.5.25 · D5· Coding › Embedded Systems & Real-Time Software › Redundancy — TMR (triple modular redundancy), voting logic
Yeh Hinglish parent ka companion trap bank hai. Yeh seedha parent topic par build karta hai aur Fault Tolerance Fundamentals, Common-Cause Failures, Byzantine Fault Tolerance, aur Redundancy vs. Diversity par lean karta hai. Har item ek aisi misconception ko target karta hai jo topic quietly invite karta hai.
True or false — justify
TMR hamesha ek single module se system ko zyada reliable banata hai.
False. Sirf tab jab har module ki reliability ho; neeche, do flaky modules ek good one ko zyada baar outvote karte hain instead of teeno ke succeed karne ke, toh .
Exactly par, TMR reliability single-module reliability ke barabar hoti hai.
True. , toh crossover point precisely hai — Figure 2 mein grey aur blue curves wahan cross karti hain, sirf touch nahi karti.
Ek TMR system do simultaneous module failures survive kar sakta hai.
False. Do failures sirf ek working module chodti hain, jo majority nahi bana sakta; voter ke paas 2-out-of-3 agreement nahi hai aur system fail ya halt ho jata hai.
TMR tumhe batata hai ki kaun sa module fail hua.
False. Yeh sirf batata hai ki minority disagree ki; tum jaante ho ki koi wrong hai lekin kaun, bina extra diagnostics jaise Watchdog Timers ya comparison logic ke nahi jaante.
Classic TMR mein voter khud ek single point of failure hai.
True. Agar voter ek plain unreplicated circuit hai, toh uska failure teeno modules ko ek saath defeat kar deta hai — yahi wajah hai ki voters ko hardened ya khud replicated kiya jata hai.
Modules ki independent failure TMR ki guaranteed property hai.
False. Yeh ek assumption hai. Shared power supplies, clocks, ya identical software bugs Common-Cause Failures cause karte hain jo teeno ko ek saath hit karte hain, math ki assumed independence ko todkar.
Teen identical processors par same software run karna ek software bug se protect karta hai.
False. Identical software mein identical bugs hote hain; teeno wahi wrong answer produce karte hain aur voter khushi se pass kar deta hai. Iske liye design diversity chahiye, sirf replication nahi.
Ek median voter aur ek Boolean majority voter apne respective data types ke liye same idea implement karte hain.
True. Dono disagreeing minority ko discard karte hain: binary values ke liye majority, continuous values ke liye median — median woh "middle vote" hai jise outliers door nahi kheench sakte.
Spot the error
"Voter basically ek OR gate hai — agar koi bhi module 1 output kare, hum 1 output karte hain."
Wrong. OR ek single faulty 1 ko pass kar deta hai; voter output ek majority gate hona chahiye (products = AND, pehle bind karte hain; = OR) toh sirf tab 1 hota hai jab kam se kam do agree karein.
"Hamen teen sensor readings ko average karna chahiye best estimate pane ke liye."
Fault masking ke liye wrong. Averaging ek wild outlier ko result skew karne deta hai (100,100,1000 → 400); median (→100) faulty value ko completely ignore karta hai.
"TMR ek module ko handle kar leta hai jo plausible-but-wrong values output karta hai, bilkul theek se."
Sirf partly. Yeh ek fail-incorrect fault hai; voter isse mask kar leta hai jab tak sirf ek module jhootha ho, lekin agar do independently alag wrong values produce karein, majority toot jaati hai — fail-silent behavior se zyada mushkil.
"Kyunki do sensors agree kar rahe hain, teesra definitely tuta hua hai."
Certain nahi. Do agreeing modules ek common-cause fault share kar sakte hain aur saath mein galat ho sakte hain jabki akela module sahi ho — agreement correctness ka proof nahi hai.
"Analog sensor readings ko vote karne ke liye exact equality use karo maximum strictness ke liye."
Wrong. Analog noise ka matlab hai ki good sensors kabhi last bit tak match nahi karte; tumhe ek tolerance window ke andar approximate voting chahiye, warna valid readings falsely "disagree" karti hain.
"Voting tolerance bahut large set karna safe choice hai — yeh false disagreements avoid karta hai."
Wrong. Bahut badi tolerance genuinely diverged values ko agreement maan kar real faults mask kar deti hai; tolerance ko sensor noise aur fault magnitude ke beech balance karna chahiye.
"Teen modules saare disagree kar rahein, voter bas pehla wala pick kar leta hai."
Wrong. Three-way disagreement ek consensus failure hai; ek correct voter no-decision return karta hai (ya halt karta hai), kyunki koi majority nahi hai jis par trust kiya ja sake.
"TMR 3× reliability deta hai kyunki tumhare paas 3 modules hain."
Wrong. Reliability hai, nahi. par tumhe milta hai, nahi — reliability ek probability hai jo 1 par capped hai, aur gain "3×" se bahut chhota hai.
Why questions
TMR ko odd number of modules kyun chahiye?
Even count tie kar sakta hai (e.g. 2 vs 2), voter ko koi majority nahi deta; odd count guarantee karta hai ki ek side hamesha single-value comparison ke liye dusre se zyada ho.
TMR faults detect kyun nahi kar sakta, sirf mask kar sakta hai?
Voter ka output sirf majority value reveal karta hai, na ki kaun se inputs disagree kiye; minority ko record kiye bina culprit diagnose karne ke liye needed information khо jaati hai.
Fail-silent module ko fail-incorrect se zyada aasaani se tolerate kyun kiya ja sakta hai?
Fail-silent module simply drop out ho jata hai, ek clean 2-out-of-2 majority chodta hai; fail-incorrect module actively ek wrong value inject karta hai jise voter ko out-vote karna hota hai, aur coordinated wrong values isse defeat kar sakti hain — yahi Byzantine Fault Tolerance ka essence hai.
Hardware voters often bit-by-bit compare kyun karte hain instead of numeric equality use karne ke?
Bit comparison ek fixed, fast, gate-level operation hai predictable delay ke saath; floating-point equality slower hai aur representation quirks ke subject hai jo tight real-time deadlines ke liye unsuitable hain.
Reliability formula tab kyun help nahi karta jab modules correlated hon?
Derivation multiply karta hai independent failures assume karke; correlation ka matlab hai ek event kai modules ko saath knock out kar deta hai, toh true reliability formula ke predict se bahut kam hoti hai.
Middle term mein 3 ka factor kyun hai jabki "all correct" term mein nahi?
alag modules hain jo single failing one ho sakte hain, toh teen distinct scenarios woh probability share karte hain; "all correct" ek single scenario hai, toh ise aisa koi count nahi chahiye.
Plain triplication ki jagah diversity (different implementations) kabhi kabhi kyun prefer ki jaati hai?
Identical copies identical design flaws share karti hain; diverse implementations alag tarah se fail hoti hain, toh woh common-cause aur common-bug weaknesses ko attack karti hain jo plain redundancy wide open chodti hai — dekho Redundancy vs. Diversity.
TMR reliability ke liye space aur power trade kyun karta hai instead of reliability free mein pane ke?
Tum physically computation ki teen copies chalate ho, toh hardware area, energy, aur cost roughly triple ho jaati hai; reliability gain un resources ke saath kharidha jaata hai, conjured nahi.
Edge cases
Voter kya karta hai jab exactly do modules output produce karte hain aur dono agree karte hain?
Woh unki agreed value ke roop mein output karta hai — ek fail-silent teesra module phir bhi ek valid 2-of-2 majority chodta hai, jo exactly single-fault case hai jise TMR survive karne ke liye build kiya gaya hai.
Voter kya karta hai jab do modules silent hain aur sirf ek output produce karta hai?
Isse insufficient quorum maano — ek akela survivor 2-out-of-3 majority nahi bana sakta, toh voter ko ise blindly accept nahi karna chahiye; use redundancy loss signal karna chahiye aur (safety-critical use mein) halt ya safe state pe hand off karna chahiye.
Kya hota hai agar teeno modules healthy hon lekin ek transient ek single cycle ke liye glitch kare?
Voter us cycle ko instantly mask karta hai; healthy pair output carry karta hai, aur glitching module next cycle recover kar leta hai — ek transient mask karna TMR ka everyday kaam hai.
Kya toot jaata hai jab module failures correlated hoti hain instead of independent ke?
Ek single root event (shared power dip, common clock fault, identical software bug) do ya teen modules ko ek saath usi tarah flip kar sakta hai; voter phir wrong values ki ek false "majority" dekhta hai aur confidently garbage output karta hai — math ab apply nahi hota kyunki usne independence assume ki thi, toh real reliability us shared component ki taraf collapse hoti hai. Yahi wajah hai ki Common-Cause Failures ko engineer out karna hoga, sirf vote around nahi karna.
Boundary par, single-module aur TMR reliability kaise compare karte hain?
Dono 1 approach karte hain, aur gap zero ki taraf shrink hota hai — near-perfect modules voting se almost kuch nahi gain karte, kyunki mask karne ke liye bahut kam failure bachi hai.
par, kya approach karta hai aur kyun?
Yeh 0 approach karta hai ( se dominated), aur single module ke se faster aise karta hai, confirming karta hai ki TMR bahut unreliable parts ke liye strictly worse hai.
Teen analog readings ke liye correct voter response kya hai jo tolerance se pare mutually far apart hain?
No-consensus report karo aur alarm raise karo; ek "middle" value fabricate karna ek genuine multi-fault condition ko hide kar dega jiske baare mein operator ko pata hona chahiye.
Agar voter khud triplicated hai, toh ab tumhe kaun si nayi problem solve karni hai?
Tumhe teen voter outputs combine karne ka tarika chahiye — single-point-of-failure question ek level upar push ho jaata hai — aksar separate actuators drive karke ya ek final hardened comparator se resolve kiya jaata hai.
Recall Ek-line self-test
Agar koi kahe "humne TMR add kiya toh system ab teen guna safer hai," toh unhe correct karne wala ek sentence kya hai? ::: Reliability follow karti hai aur sirf tab help karti hai jab ; gain bounded hai aur unreliable modules ke liye negative bhi ho sakta hai.