Verification methods — analysis, test, inspection, demonstration: Question bank

3.6.28 · D5 · Physics › Spacecraft Structures & Systems Engineering › Verification methods — analysis, test, inspection, demonstra

Yeh bank un conceptual galtiyon ko pakadta hai jo log analysis, test, inspection, aur demonstration ke beech choose karte waqt karte hain. Har answer mein sirf verdict nahi, balki reasoning bhi milti hai. Reveal ko cover karo, pehle apna answer zor se bolo, phir check karo.

True or false — justify

TRUE/FALSE: Ek mass requirement ("mass shall be under 12 kg") ko test se verify karna best hai.

False — tum sirf ise ek scale pe rakhte ho, jo bina kisi environment ya operation ke ek static property observe karta hai; yeh inspection hai, test nahi. Test behaviour ke liye hota hai conditions ke under.

TRUE/FALSE: Agar koi requirement analysis se verify hoti hai, toh us requirement ke liye koi hardware kabhi banane ki zarurat nahi.

Principle mein us specific requirement ke liye True hai, lekin analysis model ko aksar kahin na kahin kuch test data ke against validation ki zarurat hoti hai, warna uski predictions untrusted rehti hain.

TRUE/FALSE: Qualification level (1.25× flight) pe testing prove karta hai ki design sahi hai.

True — qualification ek unit ko flight se zyada stress karta hai yeh prove karne ke liye ki design mein margin hai; acceptance testing 1.0× pe phir har individual flight unit ko workmanship ke liye screen karta hai bina use over-stress kiye.

TRUE/FALSE: Demonstration sirf test ka ek kam-rigorous version hai.

False — yeh alag-alag sawaalon ka jawab dete hain. Test ek physical quantity ko threshold ke against measure karta hai; demonstration confirm karta hai ki ek operational capability actually hoti hai (jaise "antenna command pe deploy hota hai") aksar bina precise measurement ke.

TRUE/FALSE: Analysis hamesha test se sasti hoti hai, isliye jab bhi possible ho analysis karni chahiye.

Blanket rule ke roop mein False — analysis tab hi sasti hoti hai jab ek validated model exist kare; ek novel structure ke liye high-fidelity model banana aur validate karna ek shake-table run se zyada costly ho sakta hai.

TRUE/FALSE: Exactly 0 ka margin of safety matlab hai requirement verify ho gayi.

Barely —

MoS = 0

matlab applied stress yield ke barabar hai zero remaining margin ke saath; zyaadatar programs

MoS > 0

strictly require karte hain, kyunki model aur material uncertainty ek "just-passing" part ko failure ki taraf dhakeel sakti hai. Dekho Margin Philosophy.

TRUE/FALSE: Agar ek spacecraft 8g test survive karta hai, toh yeh 10g flight environment ke liye verify ho jaata hai.

False — tumhare paas sirf us level tak evidence hai jahan tak test kiya gaya. Verification claims demonstrated level se zyada nahi ho sakti; tumhe 10g pe test karna hoga (ya usse 1.25× oopar qualify karna hoga).

TRUE/FALSE: Inspection ek dynamic launch-load requirement verify kar sakti hai.

False — loads sirf launch ke dauran exist karte hain, isliye observe karne ke liye kuch bhi static nahi hai; us requirement ko test (measure karo) ya analysis (predict karo) chahiye.

Spot the error

Statement: "Hamari thermal battery requirement analysis se pass ho gayi, isliye humne paise bachane ke liye thermal-vacuum test delete kar diya."

Error yeh hai ki analysis aur test ko interchangeable treat kiya gaya; tum phir bhi test model validation ke liye run kar sakte ho, kyunki ek unvalidated thermal model verified answer nahi deta, unverified answer deta hai.

Statement: "FEA ne positive margin dikhaya, isliye structure verify hai — material data ki koi zarurat nahi."

FEA output utni hi achi hai jitne iske inputs hain; ek stress result jo unverified material yield strength ke against compare kiya gaya ho, kuch bhi verify nahi karta. Inputs (material properties, boundary conditions) khud trustworthy hone chahiye.

Statement: "Humne flight hardware ko safe rehne ke liye acceptance test 1.25× flight level pe run kiya."

Wrong level — 1.25× qualification level hai jo ek dedicated qual unit ke liye intended hai; flight hardware ko 1.25× pe run karna un parts ko unnecessarily over-stress karta hai jinhein tum fly karna chahte ho aur fatigue life consume karta hai. Acceptance 1.0× hai.

Statement: "Vibration ke baad natural frequency 3% shift ho gayi, lekin yeh < 5% criterion fail karta hai isliye humne unit scrap kar diya."

3% shift 5% limit se neeche hai, isliye yeh pass karta hai; criterion un shifts ko flag karta hai jo bahut bade hain (stiffness loss / cracking ka evidence), aur 3% allowed band ke andar hai.

Statement: "Humne deployment requirement ko hinge torque margin analyse karke verify kiya."

Torque margin ka analysis zaroori hai lekin akela yeh operational requirement verify nahi karta ki appendage actually deploy hoti hai; uske liye deployment event ka ek demonstration chahiye.

Statement: "Requirement verification method se traceable nahi hai, lekin hardware kaam kar raha hai, toh hum done hain."

Har requirement ko traceability matrix ke through ek method se map karna hota hai; ek unlinked requirement definition se unverified hai, chahe hardware ka behaviour kaisa bhi lage.

Statement: "Humne ek purani build se qualify kiya, phir bracket change kiya, aur qualification valid rakhi."

Design change qualification pedigree tod deta hai; configuration management yeh flag karna chahiye ki tested article ab flight se match nahi karta, isliye re-verification (delta-qual) required hai.

Why questions

Tum mass requirement ko meaningfully "test" kyun nahi kar sakte?

Kyunki mass ek static property hai jo bina kisi environment ya operation ke exist karti hai; ise conditions mein dalna kuch add nahi karta, isliye weighing (inspection) complete verification hai.

Qualification test flight limit ke oopar kyun hota hai, na ki usse match karte hue?

Manufacturing aur environment dono unit-to-unit vary karte hain; ek article ko mean se oopar test karna statistical confidence deta hai ki flight units ki poori population limits ke andar rahegi.

Launch-load aur long-duration space-environment requirements ke liye analysis preferred kyun hai?

Yeh scenarios ground pe fully reproduce karne ke liye expensive, destructive, ya impossible hain, isliye ek validated physics model hi practically poore requirement space ko cover karne ka tarika hai.

Kisi analysis model ko validate kiye jaane se pehle uske results kuch bhi verify kyun nahi karte?

Ek unvalidated model silently reality ko mispredict kar sakta hai (wrong boundary conditions, missing physics); validation measured data ke against hi ek prediction ko trustworthy evidence mein badalta hai.

Kai programs mein successful analysis ke baad bhi hum test kyun karte hain?

Model ko validate karne ke liye aur un cheezein pakadne ke liye jo analysis capture nahi kar sakti — weld quality, assembly tolerances, contact nonlinearities — jo exactly workmanship issues hain jo test expose karne ke liye designed hai.

Do ±10% sources ki combined uncertainty ~14% kyun aati hai, 20% kyun nahi?

Dono variations independent hain, isliye yeh quadrature mein add hote hain (

0. 1^{2} + 0. 1^{2} \approx 0.14

), linearly nahi; independent errors partly cancel ho jaati hain, isliye total straight sum se dheerey badhta hai.

Traceability matrix mein requirement ka link verification ka hissa kyun maana jaata hai, sirf paperwork kyun nahi?

Us link ke bina tum prove nahi kar sakte ki kaunsi evidence kis requirement ko close karti hai; verification ek coverage ka claim hai, aur untraceable evidence kisi specific requirement ke baare mein kuch prove nahi karti.

Edge cases

Edge case: Ek analysis mein applied stress exactly yield strength ke barabar aata hai. Margin of safety kya hai aur kya yeh verify hua?

MoS = σ_{y} / σ_{applied} - 1 = 0

; yeh best case mein knife-edge pass hai aur typically fail karta hai, kyunki uncertainty real part ko yield se oopar push kar sakti hai — zyaadatar programs strictly positive margin demand karte hain.

Edge case: Ek requirement ka associated environment zero hai (jaise "harness shall be color-coded per standard"). Kaun sa method lagta hai?

Inspection — yeh ek static, visually observable property hai jisme analyse ya test karne ke liye koi behaviour nahi hai aur demonstrate karne ke liye koi operation nahi hai.

Edge case: Internal heat generation

Q_{int}

zero hai aur spacecraft eclipse mein hai (koi solar nahi). Battery thermal balance kahan reduce hoti hai?

Q_{int} = Q_{solar} = 0

ke saath, node sirf radiation aur conduction se heat lose karta hai, isliye

m_{b} c_{p} d T_{b} / d t < 0

tab tak jab tak yeh cold-case floor tak nahi pahunch jaata — yeh exactly worst-case cold scenario hai jo 0°C limit ke against check karna chahiye.

Edge case: Qualification factor 1.0× set hai. Kya kho gaya?

Saara statistical margin — tum design ko usi level pe qualify kar rahe ho jo flight units dekh rahe hain, isliye unit-to-unit variation kuch flight articles ko us se oopar push kar sakti hai jo kabhi demonstrate kiya gaya tha; qualification acceptance mein collapse ho jaati hai.

Edge case: Ek acceptance test mein koi defect nahi mila lekin unit ki frequency 6% shift ho gayi. Kya yeh acceptable hai?

Nahi — 6% shift 5% criterion se zyada hai aur stiffness degradation (ek possible crack ya loosened joint) signal karta hai, isliye unit fail hoti hai "survive karne" ke bawajood, kyunki pass criterion hidden damage detect karne ke baare mein hai.

Edge case: Ek model perfect compliance predict karta hai lekin kabhi kisi bhi measured data se compare nahi kiya gaya. True verification state kya hai?

Unverified — requirement analysed hai lekin verified nahi, kyunki unvalidated prediction unknown error carry karti hai; correct status hai "open pending validation."

Edge case: Ek requirement analysis ya test dono se close ho sakti hai, aur dono affordable hain. Tum kaunsa choose karte ho?

Woh choose karo jiska dominant uncertainty sabse chhoti ho — agar physics well modelled hai toh analysis kaafi hai; agar workmanship ya hard-to-model dynamics dominate karte hain toh test karo, kyunki goal wrong "pass" ke risk ko minimize karna hai, akela cost minimize karna nahi.

Recall Fast self-check

Mass limit ke liye kaun sa method? ::: Inspection. "Antenna deploys on command" ke liye kaun sa method? ::: Demonstration. Qual level vs acceptance level factor? ::: 1.25× vs 1.0× of flight limit. 8g survive karna kya 10g requirement verify karta hai? ::: Nahi — evidence tested level tak hi rukti hai. Kya cheez ek analysis prediction ko verification evidence mein badaiti hai? ::: Ek validated model.