3.6.29 · D5 · HinglishSpacecraft Structures & Systems Engineering

Question bankFMEA — failure mode, effect, severity, detection, RPN

1,818 words8 min read↑ Read in English

3.6.29 · D5 · Physics › Spacecraft Structures & Systems Engineering › FMEA — failure mode, effect, severity, detection, RPN

Shuru karne se pehle, teen earned scores yaad kar lo taaki koi bhi symbol bina explanation ke use na ho:

  • S — Severity: effect kitna bura hai, (kuch nahi) se (mission/crew ka loss) tak.
  • O — Occurrence: failure kitni baar hoti hai, (kabhi nahi ke barabar) se (lagbhag hamesha) tak.
  • D — Detection: harm hone se pehle pakadna kitna mushkil hai, (turant pakad liya) se (disaster tak invisible) tak.
  • Aur , range se tak.

D mein direction trap dhyan do: ek accha detection system ek chhota number score karta hai. Neeche ki aadhi errors isi ko bhoolne se aati hain.


True or False — justify karo

lekin aur wali failure automatically top priority-1 fix deserve karti hai.
False. Iska hai, jo trivial hai — yeh almost kabhi hoti nahi aur hum ise turant pakad lenge. Priority RPN se set hoti hai, sirf severity se nahi; ek catastrophic-lekin-rare-aur-visible risk aksar acceptable hoti hai.
Same RPN wali do failures equally urgent hoti hain.
False. aur dono dete hain, lekin pehli mission ko khatam kar sakti hai jabki doosri harmless hai — RPN ties ko break karne ke liye pehle S dekhna padta hai.
Detection score kam karna matlab detection worse ho gayi.
False. D scale inverted hai: chhota D matlab detection better/earlier hai. Ek accha sensor add karna D ko neeche push karta hai, jo RPN kam karta hai.
Agar redundancy add karo, toh ek single unit ka Occurrence score girta hai.
False. Redundancy us unit ko fail hone se nahi rokti — uska O unchanged rehta hai. Redundancy Severity kam karta hai, kyunki system us failure se survive kar leta hai.
RPN ek genuine probability hai, isliye 500 ka RPN matlab "disaster ka 50% chance" hai.
False. RPN teen 1–10 scales ka ek ordinal ranking product hai, probability nahi. Yeh risks ko ek doosre ke against rank karta hai; in numbers ki koi physical units nahi hain.
S, O, D ko add karne ki jagah multiply karna ek arbitrary choice hai.
False. Multiplication yeh ensure karta hai ki koi bhi factor apne safe end ke paas ho (chhota S, O, ya D) toh poora RPN shrink ho jaye — yeh model karta hai ki ek risk ko dangerous hone ke liye severe aur frequent aur hidden hona padega. Addition mein ek bada term tab bhi dominate kar sakta hai jab doosra safe ho.
FMEA ek one-time analysis hai jo design freeze hone se pehle ki jaati hai.
False. FMEA ek living document hai: har design change (fuse add karna, naya software) affected rows ko re-score karta hai, isliye har mitigation ke baad RPN recompute karna padta hai.
FMEA ek top-down method hai jo mission failure se shuru hokar backward kaam karta hai.
False. FMEA bottom-up hai: har component ke failure modes se shuru karo aur effects ko upar mission tak trace karo. (Top-down "mission kaise fail ho sakta hai?" method fault-tree analysis hai — ek alag tool.)
Koi bhi known failure modes nahi hone wale component ko koi FMEA row nahi chahiye.
False aur dangerous. "No known modes" ka matlab usually yeh hai ki tumne kafi dhyan se dekha nahi; jo mode tum omit karte ho wahi tumhe bite karta hai (dekho Mars Climate Orbiter).

Error pakdo

"Battery cell short ne score kiya, isliye humne ek redundant cell add kiya — isse severity ho jaati hai."
Do errors hain: severity ko kabhi zero tak multiply nahi kiya jaata, aur redundancy S ko ek milder value tak reduce karta hai (maano 6) kyunki system ab survive karta hai, yeh score erase nahi karta.
"Hamari failure undetectable hai, isliye safe rehne ke liye humne diya."
Ulta hai. Undetectable worst case hai aur score karta hai. choose karna risk ko artificially iske RPN ko shrink karke chhupaata hai — yahi woh galti hai jo FMEA prevent karne ke liye exist karta hai.
"Mitigation ke baad O 5 se 5 raha, toh kuch nahi badla — redundancy bekaar tha."
Yeh reasoning galat tarike se demand karti hai ki O gire. Redundancy legitimately O unchanged chodta hai jabki S aur D ko katta hai; RPN phir bhi girta hai. Product judge karo, sirf ek factor nahi.
"RPN 336 se 100 aaya, jo 150 se kam hai, isliye yeh row ab closed hai aur koi monitoring nahi chahiye."
50–150 band mein RPN ka matlab "design review / monitor" hai, "closed" nahi. Sirf near-trivial rows truly drop ki jaati hain; ek recovered software leak ko phir bhi memory telemetry milti hai.
"Humne ek science instrument glitch ke liye set kiya kyunki science data ka loss catastrophic lagta hai."
Severity ek standardized scale se anchored hoti hai, feelings se nahi. crew ya flagship mission ka loss hai; recoverable science downtime zyada se zyada major (7–8) hoti hai. S inflate karna prioritisation corrupt karta hai.
"Occurrence sirf engineering judgement hai, isliye 1–10 mein koi bhi number defensible hai."
O ko ek rate over mission lifetime se tied hona chahiye (failure-rate data, heritage, testing). Pure gut-feel O values poori reliability estimate ko meaningless bana dete hain.

Why questions

Effects ko local → subsystem → system → mission levels ke upar trace kyun karte hain?
Kyunki ek "minor" local fault (ek cell 0 V tak) cascade ho sakti hai — bus girta hai, spacecraft safe mode mein jaata hai, attitude kho jaata hai, power death-spiral shuru hota hai. Sirf top-level effect true severity reveal karta hai.
1–10 scale "logarithmic-like" kyun hai na ki linear?
Human risk perception qualitatively upar ke end ke paas jump karti hai: 9→10 (major→catastrophic) ek real gap hai jo 2→3 se zyada bada hai. Compressed high-end steps mirror karte hain ki worst outcomes kitni buri tarah matter karte hain.
High-, high- failure with low manageable kyun ho jaati hai?
Low D ka matlab hai hum ise jaldi pakad lete hain, isliye hum act kar sakte hain (redundant unit par switch karo, craft ko safe karo) effect mature hone se pehle — ek silent killer ko ek handled event mein convert karke.
Fuse ya monitor add karne ke baad FMEA re-run kyun karte hain?
Har mitigation S, O, D mein se ek ya zyada change karta hai, isliye RPN recompute karna padta hai yeh confirm karne ke liye ki row actually action threshold se neeche aayi — aur yeh ensure karne ke liye ki fix ne koi naya failure mode introduce nahi kiya.
Aerospace reaction-wheel example mein unchanged O kyun tolerate karta hai?
Kyunki chaar wheels (3+1) aur predictive alarms ke saath, failure ab survivable aur foreseeable hai; hum yeh accept karte hain ki wheel seizure ho sakta hai kyunki iske consequence aur detectability control mein hain.
FMEA redundancy aur risk management se connect kyun ho sakta hai lekin V-model replace kyun nahi kar sakta?
FMEA feed karta hai ki kaunse risks mitigate karne hain; redundancy ek mitigation lever hai (S katta hai), risk management acceptance thresholds set karta hai, aur V-model surrounding process hai jo decide karta hai ki FMEA kab ki jaaye aur verify ki jaaye.

Edge cases

Ek truly harmless component ko kya RPN milta hai, aur kya usे row chahiye?
force karta hai , jo O aur D ki parwah kiye bina chhota rehta hai. Usे completeness ke liye phir bhi row milti hai, lekin woh "monitor / no action" mein land karta hai.
Kya RPN kabhi exactly 0 ho sakta hai?
Nahi. Har scale ka minimum 1 hai, isliye sabse chhota possible RPN hai. Ek row mathematically kabhi vanish nahi ho sakti — har risk mein kam se kam ek floor value hoti hai.
Do mitigations dono RPN ko threshold se neeche laate hain — kaunsa choose karein?
Woh choose karo jo S kam kare (tum failure se survive karte ho) kisi aise ke upar jo sirf O ya D kam kare, kyunki severity kam karna tumhein protect karta hai chahe failure ho aur detection baad mein unreliable prove ho.
Ek mitigation is row ka RPN kam karti hai lekin kaheen aur ek naya failure mode create karti hai — ab kya?
Introduced mode ke liye ek naya FMEA row add karo aur score karo. Net risk, sirf original row nahi, improve hona chahiye; warna tumne danger move ki hai, remove nahi ki.
Agar O genuinely unknown ho (brand-new, untested technology)?
Ise blank nahi chhod sakte; ek conservative (high) O assign karo limited data ko reflect karte hue, jo RPN raise karta hai aur correctly testing ko force karta hai baad mein evidence-based lower score earn karne ke liye.
Ek failure exactly jab mission impact shuru ho tab pakdi jaati hai — kaunsa D range fit hoga?
Around ("low" detection): impact shuru hone ke baad hi detect hoti hai, isliye effect ko fully prevent karne mein too late hai lekin recovery partial ho sakti hai.
Agar S, O, aur D sab mid-scale hain (maano 5 each), toh kya RPN "medium" hai?
— 50–150 review band ke andar, isliye yahan "medium" fair hai, lekin yeh kabhi assume mat karo ki mid-inputs mid-RPN denge: ek single high factor ek otherwise-average row ko action zone mein push kar sakta hai.
Recall Ek-line self-test

Ek perfect early-warning sensor add karna kaunsa score change karta hai, aur kis direction mein? ::: Yeh D ko lower karta hai (detection improve hoti hai), jo RPN lower karta hai — chahe failure usi rate par hoti rahe.