Systems engineering — V-model, requirements traceability

3.6.26 · Physics › Spacecraft Structures & Systems Engineering

V-Model: Design Neeche, Verify Upar

V-model ek systems engineering framework hai jo dikhata hai ki design aur verification ek doosre ko mirror karte hain.

Left Side (Design Decomposition):

Concept of Operations (ConOps) → Mission kya karta hai
System Requirements → Poora spacecraft kya karna chahiye
Subsystem Requirements → Har subsystem (power, thermal, propulsion) kya karna chahiye
Component Design → Individual parts ka detailed design

Right Side (Verification & Integration):

Component Testing → Kya har part kaam karta hai?
Subsystem Integration & Testing → Kya subsystems milke kaam karte hain?
System Integration & Testing → Kya poora spacecraft kaam karta hai?
Validation → Kya yeh mission (ConOps) poora karta hai?

"V" Shape Kyun?

V-shape abstraction levels represent karta hai. Jaise aap left side par neeche jaate ho:

High abstraction (top): "Spacecraft 10 m resolution se Earth ko image karega"
Low abstraction (bottom): "CCD sensor mein 2048×2048 pixels honge jinka pitch 5 μm hoga"

Jaise aap right side par upar jaate ho, aap increasing integration levels par confidence build kar rahe ho:

Component level: "Yeh CCD kaam karta hai"
Subsystem level: "Camera (optics + CCD + electronics) images produce karta hai"
System level: "Spacecraft 10 m resolution images achieve karta hai"

YEH KYUN KAAM KARTA HAI:

Aap usi abstraction level par verify karte ho jahan requirements specify ki thi
Integration problems jaldi pakad mein aate hain (fix karna sasta hota hai)
Aapke paas evidence hota hai ki launch se pehle har requirement poori hui

CONJUNCTION KYUN? Kyunki spacecraft systems serial chains hote hain — agar ek subsystem apni requirement fail kar de, toh mission fail ho sakta hai. Example: "Spacecraft 5 saal tak operate karega" yeh flow down hota hai "Battery 5 saal ke thermal cycles survive karegi" AUR "Solar panels 5 saal mein <20% degrade honge" AUR "Electronics 5 saal ka radiation dose survive karenge". Sab sach hone chahiye.

Requirements Traceability

Requirements traceability yeh ability hai ki aap link kar sako:

Mission objectives → System requirements → Subsystem requirements → Component specs
Har requirement → Design element → Test case → Test result

TRACEABILITY KYUN MAAYANE RAKHTI HAI:

Completeness: Kya humne woh sab kuch design/test kiya jo humne kaha tha?
Impact analysis: Agar koi requirement change ho, toh kya toot jaayega?
Compliance: Auditors/customers har requirement ka evidence dekh sakte hain

Traceability Matrix

Ek traceability matrix ek table hai:

Mission Req	System Req	Subsystem Req	Design Item	Test ID	Test Result
M1: 10m resolution	S1: Camera 10m GSD	SS1.1: Focal length 2m	Optical bench TB-101	T-SS1.1-001	PASS
M1: 10m resolution	S1: Camera 10m GSD	SS1.2: Orbit altitude 500km	Propulsion $Δ v$	T-SYS-002	PASS

ISSE KAISE BANAYEIN:

Saari requirements ek database mein extract karo (DOORS, Jama, ya Excel bhi chalega)
Har requirement level ko unique IDs assign karo
Flow-down ke dauran parent-child links banao
Har requirement ko design documents aur test procedures se link karo
Verification aage badhne par test results update karte raho

Worked example Example 1: Thermal Subsystem Traceability

Mission Requirement M3: "Spacecraft sunlight aur eclipse dono mein operate karega" System Requirement S3: "Sare components survival temperature limits ke andar rahe (-40°C se +60°C tak)"

Thermal Subsystem Requirements:

SS3.1: MLI blankets radiative heat loss ko <10 W/m² tak reduce karein
SS3.2: Heaters eclipse mein 50 W supplemental heat provide karein
SS3.3: Radiators sunlight mein 200 W dissipate karein Design:
MLI: 15 layers aluminized Kapton
Heater: Kapton film heaters, thermostatic control
Radiator: 0.5 m² Al honeycomb panel, white paint

Tests:

T-SS3.1-001: Thermal vacuum test, MLI performance measure karo → PASS
T-SS3.2-001: TVAC mein heater functional test → PASS (51 W delivered)
T-SS3.3-001: Radiator thermal balance test → PASS (205 W dissipated)

Traceability: M3 → S3 → {SS3.1, SS3.2, SS3.3} → {MLI, Heater, Radiator} → {T-SS3.1-001, T-SS3.2-001, T-SS3.3-001} → ALL PASS → S3 verified → M3 verified

Yeh step kyun? Traceability chain evidence ke saath prove karta hai ki M3 satisfy hua. Agar M3 change ho jaaye (jaise, "-50°C survive karo"), toh hum turant jaante hain ki kaunsi subsystem reqs, designs, aur tests revisit karni padengi.

Worked example Example 2: Power Budget Traceability

System Requirement S4: "Power subsystem sunlight mein end-of-life (EOL, 15 saal) par loads ko 500 W continuous provide karega"

Flow-down:

SS4.1: Solar arrays EOL par ≥600 W generate karein (500 W loads ko + margin + distribution losses)
SS4.2: Battery eclipse ke liye 200 Wh usable store kare
SS4.3: Power distribution <5% loss ke saath loads tak power deliver kare

Design — Solar Array Sizing (first principles se derived):

Cells: triple-junction GaAs, 30% efficiency, area $A = 3 m^{2}$ , solar constant $S = 1361 W/m^{2}$
Beginning-of-life (BOL) power: $P_{BOL} = A \cdot S \cdot η = 3 \times 1361 \times 0.30 \approx 1226 W$
LEO radiation degradation: assume $d = 2.5%$ per year (typical LEO), over $t = 15$ years
EOL power: $P_{EOL} = P_{BOL} (1 - d)^{t} = 1226 \times (0.975)^{15} \approx 1226 \times 0.685 \approx 840 W$
Kyunki $840 W > 600 W$ EOL par required hai, array margin ke saath pass karta hai. (Pehle ka "600 W" figure requirement tha, EOL output nahi — yahan hum dikhate hain ki design aaram se isse exceed karta hai.)
Battery: Li-ion, 50 Ah @ 18 V = 900 Wh installed; depth-of-discharge ko ~22% tak limit karne se 200 Wh usable milta hai ✓
PMAD: DC-DC converters, measured efficiency 96% → loss 4% < 5% ✓

Verification:

T-SS4.1-001: AM0 simulator ke under solar array coupons ka flash test → 31% efficiency PASS; radiation-degradation analysis EOL par >600 W confirm karta hai
T-SS4.2-001: Battery charge/discharge cycle test → 205 Wh delivered PASS
T-SS4.3-001: PMAD end-to-end efficiency test → 96.2% PASS

Har step kyun?

SS4.1: Margin zaroori hai kyunki solar cells LEO radiation ke under degrade hote hain (triple-junction cells ke liye ~2–3%/year). Hum BOL ke liye size karte hain taaki EOL par bhi array load requirement exceed kare.
SS4.2: Eclipse duration ~30 min, average load 300 W → 150 Wh needed, 200 Wh usable 33% margin deta hai.
SS4.3: Distribution losses power mein se khaate hain, isliye hum unhe explicitly budget karte hain.

Common Verification Levels

V-model right arm mein typically yeh levels hoti hain:

Component/Unit Testing: Individual part (jaise, ek electronics board)
Subsystem Integration & Test: Functional subsystem (jaise, poora thermal control system)
System Integration & Test: Full spacecraft (sare subsystems milke)
Validation/Acceptance: Mission-level checks (kya yeh ConOps meet karta hai?)

Har level par Verification methods:

Test: Physical measurement (hardware ke liye sabse credible)
Analysis: Calculations/simulations (jaise, finite element thermal model)
Inspection: Visual check (jaise, wiring harness drawing ke according route kiya gaya)
Demonstration: Operational scenario (jaise, spacecraft ko mission day ke through command karna)

Common mistake Mistake 1: Low-Level Verification Skip Karna

Galat soch: "Humne poora system test kar liya, toh component tests redundant hain." Yeh sahi kyun lagta hai: System testing zyaada realistic hai; yeh sab kuch milke kaam karta dikhata hai.

Steel-man: Yeh approach time aur effort bachati hai. Agar system test pass ho jaaye, toh sare components zaroor kaam karte honge.

Fix: System testing latent faults chupa sakta hai. Example: Ek component jo 20°C par kaam karta hai lekin -30°C par fail ho jaata hai, woh lab mein system test mein pass ho sakta hai (room temp) lekin orbit mein fail ho sakta hai (thermal extremes). Component-level environmental testing (TVAC, vibration) component ko integration se pehle stress karta hai. System level par ek kharab component milna matlab mahenga rework — aapko spacecraft disassemble karna padega. Bottom-up verification sasta aur zyaada thorough hai.

Common mistake Mistake 2: Weak Traceability ("Hum Baad Mein Track Karenge")

Galat soch: "Pehle design karte hain, traceability baad mein add kar lenge jab done ho jaayein."

Yeh sahi kyun lagta hai: Traceability ek aisi paperwork lagti hai jo engineering slow kar deti hai.

Steel-man: Engineers banana chahte hain, matrices fill nahi karna. Upfront traceability effort overhead jaisi lagti hai.

Fix: Traceability retrofit karna mahenga aur error-prone hota hai. Aap links bhool jaoge, requirements miss karoge, aur audits fail karoge. Spacecraft programs mein, traceability design ke saath concurrently build ki jaati hai. Jab bhi aap ek requirement likho, usse link karo. Jab bhi aap ek component design karo, usse trace back karo. Modern tools (DOORS, Jama) isse fast banate hain. Chhoti upfront cost do taaki integration par badi cost se bacho.

Real consequence: NASA ka Mars Climate Orbiter (1999) partly inadequate traceability ki wajah se fail hua: thruster requirement English units mein thi, navigation software metric assume karta tha, aur kisi traceability audit ne yeh mismatch nahi pakda. $125M gaya.

Recall 12 Saal Ke Bachche Ko Samjhao: V-Model

Socho tum apne doston ke saath ek treehouse bana rahe ho. Tum randomly boards thokna shuru nahi karte, right?

V ka left side (planning): Tum baithte ho aur kehte ho, "Hume ek treehouse chahiye jisme roof ho, ladder ho, aur window ho." Phir figure out karte ho: "Okay, hume roof ke liye wood chahiye, ladder ke liye rope chahiye, aur window ke liye glass chahiye." Tum isko tab tak toddte rehte ho jab tak yeh na pata ho ki exactly kya kharidna aur banana hai.

V ka bottom (building): Tum actually wood kaadte ho, rope bandhte ho, aur glass install karte ho.

V ka right side (checking): Ab tum sab kuch reverse order mein check karte ho. Pehle, "Kya rope ladder mera weight uthati hai?" (component test). Phir, "Kya poora ladder treehouse se securely attach hai?" (integration test). Aakhir mein, "Kya main upar chadh sakta hun aur andar roof ke neeche baith sakta hun?" (system test). Agar tum sirf end mein check karte aur rope toot jaati, toh tumhe isko fix karne ke liye poora treehouse todna padta. Lekin agar tum pehle rope check karte, toh tum isse install karne se pehle sirf strong rope kharid lete.

Traceability: Tum ek notebook rakhte ho: "Roof idea → wood planks → Home Depot se kharide → baarish mein test kiya → kaam karta hai!" Toh agar baad mein tumhara dost pooche, "Humne metal ki jagah wood kyun use ki?" tum apni poori chain of reasoning aur tests dikha sako.

Connections

Systems Engineering Fundamentals — broader SE principles (functional analysis, trade studies)
Verification vs Validation — V-model right arm in concepts ko detail mein batata hai
Configuration Management — traceability ke liye requirements, designs, tests ka version control zaroori hai
Risk Management in Spacecraft Design — traceability requirement flow-down mein risks identify karne mein madad karta hai
Fault Tree Analysis — failures ko requirements se link karne ke liye traceability use karta hai
Spacecraft Integration and Testing — V-model right arm ka practical execution
Requirements Derivation — system se subsystem tak flow-down ka process
Interface Control Documents — subsystems ke beech interface requirements trace karo

#flashcards/physics/spacecraft-systems-engineering

Systems engineering mein V-model kya hai?

Ek systems engineering framework jahan left arm design decomposition represent karta hai (ConOps → system → subsystem → component), bottom implementation hai, aur right arm verification aur integration represent karta hai (component test → subsystem test → system test → validation). Har design level corresponding integration level par verify hoti hai.

V-model ko "V" kyun kehte hain?

Yeh shape abstraction levels represent karti hai: tum high-level mission objectives (top left) se detailed component design (bottom) tak decompose karte ho, phir low-level components (bottom right) se mission validation (top right) tak integrate aur verify karte ho. Horizontal lines requirements ko unke verification steps se connect karti hain.

Requirements traceability kya hai?

Har requirement ko uske poore lifecycle mein link karne ki ability: mission objective → system requirement → subsystem requirement → design element → test case → test result. Yeh ensure karta hai ki koi requirement na kho aur sari requirements poori hone ka evidence mile.

Traceability matrix kya hai?

Ek table jo explicitly har requirement ko uski parent requirement, derived child requirements, use implement karne wale design items, usse verify karne wale test cases, aur test results se link karta hai. Yeh har requirement ke liye ek clear audit trail provide karta hai.

Char common verification methods kaunse hain?

1) Test (physical measurement), 2) Analysis (calculations/simulations), 3) Inspection (visual examination), 4) Demonstration (operational scenario execution). Hardware ke liye Test sabse credible hai.

Agar tum poora system test kar rahe ho toh component level par bhi verify kyun karein?

Component-level testing parts ko environmental extremes (temperature, vibration, radiation) mein stress karta hai jo system tests mein nahi aate. System level par ek faulty component milna mahenga spacecraft disassembly require karta hai. Bottom-up verification sasta hai aur latent faults jaldi pakad leta hai.

Component-level requirement right arm ke kis level par verify hoti hai?

V par directly opposite component testing level par. Left arm par decomposition level n par specify ki gayi har requirement right arm par usi integration level n par verify hoti hai (component→component test, subsystem→subsystem test, system→system test).

Agar design complete hone ke baad traceability add karo toh kya hota hai?

Traceability retrofit karna mahenga aur error-prone hota hai. Aap requirement–design links bhool jaoge, verification gaps miss karoge, aur audits fail karoge. Design ke saath concurrently traceability banana in problems se bachata hai aur requirements change hone par impact analysis enable karta hai.

Verification coverage kya hai aur launch se pehle yeh kitna hona chahiye?

Verification coverage

C_{v} = \frac{N _{verified}}{N _{total requirements}} \times 100%

. Launch se pehle target 100% hai — koi bhi unverified requirement untested risk represent karti hai jo mission failure cause kar sakta hai.

Subsystem requirements logically system requirements se kaise relate karti hain?

Agar system requirement

R_{sys}

subsystem requirements

R_{1}, R_{2}, \dots, R_{n}

mein flow down ho, toh

⋀_{i = 1}^{n} R_{i} ⟹ R_{sys}

(logical conjunction). System requirement satisfy hone ke liye SAARI subsystem requirements poori honi chahiye, kyunki spacecraft systems serial chains hain jahan koi bhi single failure mission fail kar sakta hai.

BOL power aur annual degradation se solar array EOL power kaise compute karte hain?

P_{EOL} = P_{BOL} (1 - d)^{t}

, jahan

d

fractional degradation per year hai aur

t

saal hain. Jaise, 1226 W BOL at 2.5%/year over 15 years deta hai

1226 \times (0.975)^{15} \approx 840

Mars Climate Orbiter traceability failure kya tha?

Ek thruster requirement English units mein specify thi jabki navigation software metric units assume karta tha. Kisi traceability audit ne subsystems ke beech yeh unit mismatch nahi pakda. Spacecraft kho gaya, jo requirements traceability ki critical importance demonstrate karta hai.