Exercises — Systems engineering — V-model, requirements traceability
3.6.26 · D4· Physics › Spacecraft Structures & Systems Engineering › Systems engineering — V-model, requirements traceability
Shuru karne se pehle, ek word jis par is poore page mein hum rely karte hain: ek requirement ek aisi single sentence hoti hai jo kehti hai koi cheez kya karna chahiye ya kya exceed nahi karni chahiye — testable, jahan possible ho wahan number ke saath. "The battery shall deliver 200 Wh" ek requirement hai; "the battery should be good" nahi hai.
Level 1 — Recognition
Exercise 1.1 (L1)
V-model mein, right arm ka woh level batao jo left arm ke subsystem level par likhi requirement ko verify karta hai.
Recall Solution 1.1
V-model kya kehta hai: har horizontal line ek left-arm design level ko right-arm ke us level se jodti hai jo seedha usi height par opposite hota hai. Woh opposite level woh abstraction level hai jahan tum apna kiya hua promise check karte ho. Figure s01 dekho — "subsystem" height par dashed grey line Subsystem Requirements ko left par Subsystem Integration & Test se right par connect karti hai. Answer: Subsystem Integration & Test.
Exercise 1.2 (L1)
Har item ko "design (left arm)" ya "verification (right arm)" mein match karo: (a) Concept of Operations, (b) Component Testing, (c) Subsystem Requirements, (d) Validation.
Recall Solution 1.2
Left arm decompose karta hai — bade idea se lekar detail parts tak jaata hai. Right arm confidence build karta hai testing karke.
- (a) ConOps → design (left, top)
- (b) Component Testing → verification (right, bottom)
- (c) Subsystem Requirements → design (left)
- (d) Validation → verification (right, top) — mission-level "kya humne sahi cheez banayi?" check (Verification vs Validation).
Exercise 1.3 (L1)
Blank bharo: traceability matrix mein, ek Test Result = PASS is baat ka ______ provide karta hai ki linked requirement meet ho gayi hai.
Recall Solution 1.3
Answer: evidence. Traceability ka poora kaam hai ek chain of proof attach karna — requirement → design item → test → result — taaki "humne ise meet kiya" koi opinion na ho balki ek documented fact ho.
Level 2 — Application
Exercise 2.1 (L2)
Ek system requirement kehti hai spacecraft 5 years operate karega. Yeh teen subsystem requirements mein flow down hoti hai:
- : battery 5 years ke thermal cycles survive kare,
- : solar panels 5 years mein degrade hon,
- : electronics 5-year radiation dose survive karein.
Parent note ke logical conjunction use karke flow-down likho, aur batao system requirement ke liye kya true hona chahiye.
Recall Solution 2.1
Hum kya karte hain: parent ke [!formula] se flow-down rule apply karte hain. Symbol ka matlab hai "unka AND," toh . Conjunction kyun OR nahi: spacecraft ek serial chain hai — agar battery mar jaaye, ya panels zyada fade ho jaayein, ya electronics fry ho jaayein, 5-year mission khatam. Toh teeno hold karni chahiye. Sirf hi guarantee karta hai.
Exercise 2.2 (L2)
Solar array sizing (parent ke Example 2 ke numbers). Cells 30% efficient hain, area , solar constant . Beginning-of-life power compute karo.
Recall Solution 2.2
Formula ka matlab: panel par aane wali sunlight power hai (area)(power per area) . Panel sirf fraction (efficiency) ko electricity mein convert karta hai, toh se multiply karo. (Parent round karta hai; dono 3 significant places tak same figure hai.)
Exercise 2.3 (L2)
Degradation. Ek triple-junction array per year degrade hota hai. se start karke, years baad end-of-life power nikalo.
Recall Solution 2.3
Power (exponential) law kyun aur subtraction kyun nahi: har saal array jo ab produce kar raha hai usi ka kho deta hai, original ka nahi. Har step mein current value ka fraction kho dena exactly se repeated multiplication hai — isliye use karte hain, nahi. Ab , toh Requirement thi at EOL, toh yeh margin ke saath pass hai ().
Level 3 — Analysis
Exercise 3.1 (L3)
Eclipse battery sizing. Eclipse chalta hai average load ke saath. (a) Kitne watt-hours chahiye? (b) Battery at hai; uski installed energy kya hai? (c) Agar usable energy depth-of-discharge tak limited hai, toh kya eclipse requirement (need jo (a) mein mila) meet hoti hai?
Recall Solution 3.1
(a) Energy needed. Energy power time. 30 min ko hours mein convert karo: . (b) Installed energy. Battery ke liye, energy (Wh) charge (Ah) voltage (V): (c) Usable energy. Depth-of-discharge ka matlab hai hum recharge karne se pehle sirf draw karte hain (battery life protect karne ke liye): Kyunki , requirement meet ho gayi, margin ke saath.
Exercise 3.2 (L3)
Distribution loss. Power system ko loads tak deliver karna hai DC-DC converters ke through jo efficiency par measured hain. (a) Converters ko kitna input power draw karna hoga? (b) Loss watts mein kya hai, aur kya " loss" requirement meet hoti hai?
Recall Solution 3.2
(a) Input power. Output efficiency input, toh input output efficiency: (b) Loss. . Input ke fraction ke roop mein: (equivalently, ). Kyunki , requirement meet ho gayi. Ise explicitly budget kyun karte hain: wiring/converters mein har watt lost ek watt hai jo solar array ko bhi generate karna hoga. Agar bhool jao, array undersized hoga aur poori power chain EOL par fail ho jaayegi.
Exercise 3.3 (L3)
Impact analysis. Thermal example mein (parent Example 1), mission requirement M3 survival se badal kar ho jaati hai. Traceability use karke exactly batao kaun se requirements, designs aur tests revisit karne honge, aur explain karo kyun traceability ise instant banata hai.
Recall Solution 3.3
Parent se chain: . Colder survival limit ka matlab hai less heat loss allowed aur more heater authority eclipse mein. M3 se neeche chain walk karo:
- S3 change karna hoga ( limit).
- SS3.1 (MLI heat loss) — likely tighten hogi (colder means less loss afford kar sakte hain).
- SS3.2 (heater 50 W) — likely increase hogi (zyada supplemental heat chahiye).
- SS3.3 (radiator) — check karo kahin over-cool toh nahi ho raha; possibly re-sized.
- Designs: MLI layer count, heater power rating, radiator area.
- Tests: teeno thermal tests naye limits ke against re-run honge. Instant kyun: kyunki flow-down ke dauran har link record kiya gaya tha, ek node change karne par tum arrows follow karke har affected item tak pahunch sakte ho — documents mein hunting nahi karni. Yeh ek traceability matrix ki core value hai (Configuration Management un links ko control mein rakhta hai jab cheezein badlti hain).
Level 4 — Synthesis
Exercise 4.1 (L4)
Is thread ke liye one-row traceability matrix banao: Mission M1 "image Earth at 10 m resolution" → System S1 "camera achieves 10 m ground sample distance" → Subsystem SS1.1 "focal length 2 m". Sensible IDs choose karo, ek design item name karo, ek test ID, aur woh result condition batao jo poore thread ko M1 tak verify kare.
Recall Solution 4.1
Matrix row kya hoti hai: ek horizontal record jo ek requirement thread ko uske evidence se tie karta hai. Columns hain Mission → System → Subsystem → Design → Test → Result.
| Mission Req | System Req | Subsystem Req | Design Item | Test ID | Result |
|---|---|---|---|---|---|
| M1: 10 m resolution | S1: camera 10 m GSD | SS1.1: focal length 2 m | Optical bench TB-101 | T-SS1.1-001 | PASS |
Verification logic (bottom-up, V ka right arm): T-SS1.1-001 = PASS SS1.1 verify karta hai; jab S1 ko feed karne wale saare subsystem reqs pass ho jaate hain, S1 verify ho jaata hai; S1 verified (plus orbit-altitude thread) M1 validate karta hai. IDs kyun matter karte hain: unique IDs (S1, SS1.1, T-SS1.1-001) hi woh cheez hai jo ek database (DOORS/Jama) ko parent-child links automatically draw karne deti hai — dekho Interface Control Documents jahan camera aur structure ke beech boundary freeze ki jaati hai taaki yeh thread valid rahe.
Exercise 4.2 (L4)
Full power-chain synthesis. EOL degradation (Ex 2.3), distribution loss (Ex 3.2) aur loads ko required upar se system margin ke saath combine karke: (a) EOL par required array output compute karo, aur (b) check karo kya Ex 2.3 ka EOL array pass karta hai.
Recall Solution 4.1
Hum kya karte hain — load se outward budget banao:
- Load: .
- Distribution loss add karo (Ex 3.2): converters ka input .
- system margin add karo: required . (a) EOL par required array output . (b) Array EOL par deliver karta hai. Kyunki , yeh pass karta hai, margin ke saath. Upar margin kyun: models imperfect hote hain aur space unforgiving hai; margin un unknowns ko absorb karta hai jo tum trace nahi kar sakte the. Yeh Risk Management in Spacecraft Design se connect hota hai — margin woh tarika hai jisse tum uncertainty risk buy down karte ho.
Level 5 — Mastery
Exercise 5.1 (L5)
Ek mission 5-year operation require karta hai. Ise flow down karo aur solar-panel branch ko analysis se verify karo: requirement kehti hai "panels 5 years mein degrade hon." /year compounding use karke, (a) actual 5-year degradation compute karo, (b) PASS/FAIL decide karo, aur (c) explain karo yeh single number V-model ke verification mein kaise fit hota hai, verification method name karo aur batao yeh physical test se zyada appropriate kyun hai.
Recall Solution 5.1
(a) Degradation fraction. 5 years baad remaining fraction hai . Toh degradation hai (b) Decision. ⇒ PASS. satisfy ho gayi. (c) V-model mein. Ex 2.1 se, . Yeh analysis discharge karti hai; (battery cycles) aur (radiation dose) bhi verify hone par, conjunction close ho jaata hai aur (5-year operation) verify ho jaati hai. Method: Analysis (established degradation model use karke calculation), physical test nahi. Analysis appropriate kyun hai: tum koi real 5-year test us launch se pehle nahi chala sakte jo is decade mein honi hai. Jahan physics ek well-validated model hai (compounding radiation degradation), analysis ek credible verification method hai — exactly woh "Test vs Analysis" choice jo parent note ka "Verification methods" section list karta hai. Physical flash-tests model ki starting efficiency validate karte hain; long-term extrapolation phir trusted analysis hoti hai.
Exercise 5.2 (L5)
Tightened requirement ke under design closure. Maano M3 survival tak tighten ho jaati hai aur result mein SS3.2 heater power se raise hona padta hai. Ex 3.1 mein eclipse average electrical load isliye se ho jaata hai. (a) Eclipse energy need recompute karo. (b) Kya existing usable battery ab bhi pass karti hai? (c) Ek sentence mein traceability consequence batao aur kaun sa document control process yeh change govern karta hai.
Recall Solution 5.2
(a) New eclipse energy. (b) Check. Usable ⇒ ab bhi PASS, margin ab ( se kam). (c) Traceability consequence. M3 mein change (recorded links ke zariye) SS3.2 aur power branch SS4.2 mein propagate hua — ek cross-subsystem impact — toh saari touched requirements, designs aur tests ko Configuration Management ke under re-baseline aur re-verify karna hoga (formal change control), aur thermal aur power ke beech interface Interface Control Documents ke zariye re-check hoga. Yeh mastery kyun hai: tumne ek single mission change ko do subsystems mein trace kiya, affected budgets re-run kiye, margin re-confirm kiya, aur governing process name kiya — woh poora loop jise protect karne ke liye V-model exist karta hai.
Recall Self-test summary (cloze)
V-model har requirement ko us ::: same abstraction level par verify karta hai jahan woh specify ki gayi thi. Flow-down logical ::: conjunction (AND) use karta hai — saari sub-requirements hold karni chahiye. Solar degradation ::: ke roop mein compound hoti hai, linearly nahi. Battery ki energy Wh mein charge Ah times ::: voltage in V ke barabar hoti hai. Traceability matrix requirement ko design se test se ::: result (evidence) tak link karta hai. Right arm ke do sawaal hain: verification = "sahi banayi?" aur validation = ::: "sahi cheez banayi?"