Verification methods — analysis, test, inspection, demonstration

Overview

Verification is the process of confirming that a spacecraft component or system meets its specified requirements. The four primary verification methods—analysis, test, inspection, and demonstration—form the foundation of systems engineering quality assurance. Each method answers a different question about requirement compliance and has distinct cost, risk, and confidence trade-offs.

Think of building a bridge: you'd inspect the steel quality, analyze stress under design loads, test a scale model in a wind tunnel, and demonstrate by driving trucks across the completed structure.

The Four Verification Methods

What it verifies: Requirements where predicted behavior is sufficient—structural margins, thermal performance, radiation dose, orbital mechanics, power budgets.

Why it works: Physical laws (Newton's laws, Maxwell's equations, thermodynamics) are deterministic. If your model captures the physics accurately and your inputs are correct, the output predicts reality.

How to execute:

1. Build a validated model (FEA for structures, CFD for fluids, SPICE for circuits)
2. Define boundary conditions matching requirement scenarios
3. Run simulations with margin (safety factors)
4. Document assumptions, model fidelity, and uncertainty bounds
5. Compare predictions to requirement thresholds

When to use: Early design phases, expensive-to-test scenarios (launch loads, long-duration space environment), destructive conditions you can't test without destroying hardware.

During launch, the spacecraft experiences quasi-static loads (acceleration feels like increased gravity). If the launch vehicle pulls $n$ g's, each component experiences: $F_{\text{inertial}} = m \cdot (n \cdot g)$

This force creates stress in the structure. For a simple beam supporting mass $m$ at distance $L$ from a fixed point, the bending moment is: $M = F \cdot L = m \cdot n \cdot g \cdot L$

The bending stress in the beam's outer fiber (from beam theory, $\sigma = My/I$ where $y$ is distance from neutral axis and $I$ is second moment of area): $\sigma = \frac{M \cdot c}{I} = \frac{m \cdot n \cdot g \cdot L \cdot c}{I}$

where $c = h/2$ for a rectangular cross-section of height $h$.

For a rectangular beam of width $b$ and height $h$, the second moment is $I = bh^3/12$ (derived from $\int y^2 \, dA$), so: $\sigma = \frac{m \cdot n \cdot g \cdot L \cdot (h/2)}{bh^3/12} = \frac{6\cdot m \cdot n \cdot g \cdot L}{b \cdot h^2}$

Why this step? We derived stress from first principles. The requirement might state: "Structure shall withstand 8g launch load with margin of safety > 0." Analysis verifies by calculating $\sigma$ and comparing to material yield strength $\sigma_y$: $\text{Margin of Safety} = \frac{\sigma_y}{\sigma_{\text{applied}}} - 1$

If MoS > 0, requirement verified by analysis.

Verification approach: Thermal analysis using finite-element model.

Step 1: Build thermal math model

• Node for battery (mass $m_b$, specific heat $c_p$)
• Radiative couplings to spacecraft walls (view factors $F_{12}$)
• Conductive paths to mounting bracket (conductance $G = kA/L$)
• Internal heat generation $Q_{\text{int}}$ from battery discharge

Step 2: Energy balance equation for battery node $m_b c_p \frac{dT_b}{dt} = Q_{\text{int}} + Q_{\text{solar}} + Q_{\text{rad,in}} - Q_{\text{rad,out}} - Q_{\text{cond}}$

Why this step? First law of thermodynamics: energy in minus energy out equals change in stored energy.

Step 3: Simulate worst-case hot and cold scenarios

• Hot case: Maximum solar flux (1414 W/m² at perihelion), maximum internal dissipation, sun-pointing attitude
• Cold case: Eclipse (no solar), minimum internal dissipation, radiator facing deep space

Step 4: Run transient simulation over multiple orbits until steady-periodic state reached

Step 5: Check predicted $T_b(t)$

• Cold case: $T_{\min} = 5°C$ ✓ (above0°C limit)
• Hot case: $T_{\max} = 38°C$ ✓ (below 40°C limit)

Result: Requirement verified by analysis. No thermal-vacuum chamber test needed for this requirement (though you might test anyway for model validation).

What it verifies: Requirements where actual measured behavior is necessary—vibration survival, EMC compliance, sensor accuracy, RF performance, thermal balance.

Why it works: Testing eliminates model uncertainties. If hardware survives 8g vibration on a shake table, you have direct evidence it will survive launch. No assumptions about material properties, weld quality, or assembly tolerances needed.

How to execute:

1. Define test conditions (environment, duration, measurements)
2. Prepare test article and instrumentation
3. Execute test per approved procedure
4. Record data continuously
5. Analyze results against requirement thresholds
6. Document any anomalies or deviations

When to use: Critical performance requirements, environments difficult to model accurately (vibration, acoustic, pyro shock), qualification of new designs, acceptance testing of flight hardware.

For vibration, the qualification level is typically: $\text{Qualification Level} = \text{Flight Limit} \times 1.25 \, \text{(factor)}$

Why? This comes from statistical tolerance analysis. If manufacturing introduces $\pm 10\%$ variation in natural frequency, and flight environment has $\pm 10\%$ variation, the combined uncertainty is (assuming independence): $\sigma_{\text{total}} = \sqrt{\sigma_{\text{mfg}}^2 + \sigma_{\text{env}}^2} = \sqrt{0.1^2 + 0.1^2} \approx 0.14$

To capture99% of cases (3-sigma coverage), you need: $\text{Test Level} = \text{Mean} + 3\sigma = 1.0 + 3(0.14) \approx 1.4$

Industry uses 1.25× as practical compromise between risk and cost.

Acceptance testing (for flight units) uses lower levels: $\text{Acceptance Level} = \text{Flight Limit} \times 1.0 \, \text{(factor)}$

Why this step? You've already qualified the design at1.25× with the qualification unit. The acceptance test confirms this specific flight unit has no manufacturing defects, without overstressing it.

Verification approach: Random vibration test on electrodynamic shaker.

Step 1: Define qualification test spectrum

• Base requirement: 8g RMS
• Qualification level: $8 \times 1.25 = 10g$ RMS
• Duration: 2 minutes per axis (industry standard)

Step 2: Install spacecraft on shaker table

• Bolt to interface plate matching launch vehicle adapter
• Install accelerometers at critical locations (base, appendages, electronics boxes)

Step 3: Execute test sequence

• Sweep sine (5-2000 Hz at 2 octaves/min) to measure natural frequencies
• Random vibration (apply 10g RMS spectrum for 2 min in X-axis)
• Repeat sweep sine to check for frequency shifts (indicates damage)
• Repeat for Y and Z axes

Step 4: Acceptance criteria

• No structural failures or hardware detachment
• Natural frequencies shift< 5% (indicates no significant stiffness degradation)
• All sensors functional during and after test

Result: Spacecraft survived 10g RMS (1.25× flight level) with no damage. Post-test inspection shows no cracks, no fastener loosening, frequency shift2.1%. Requirement verified by test.

What it verifies: Requirements where "looking and measuring" is sufficient—geometry, weight, correct part installation, surface finish, cleanliness, labeling.

Why it works: For static physical properties, measurement is more direct than analysis or test. You can't "test" a mass requirement—you put it on a scale.

How to execute:

1. Identify inspection points in manufacturing/assembly process
2. Use calibrated measurement equipment (calipers, scales, micrometers, microscopes)
3. Compare measurements to drawings and specifications
4. Document with photos, measurement logs, inspector signatures
5. For material inspection, use certificates of conformance or lab analysis

When to use: As-built configuration, mass properties, correct part installation, acceptance of deliverables, contamination control.

Verification approach: Inspection via weighing.

Step 1: Wait until spacecraft is fully assembled (inspection is last step)

Step 2: Place spacecraft on calibrated scale (precision ±0.1 kg)

Step 3: Record mass reading: 447.3 kg

Step 4: Compare to requirement: 447.3 < 450 ✓

Step 5: Document with:

• Scale calibration certificate (valid within 6months)
• Photo of spacecraft on scale with display visible
• Mass properties report (also records center of gravity, measured separately with inclinometers)

Result: Requirement verified by inspection. Analysis predicted445 kg during design; actual mass 447.3 kg (good agreement, 0.5% error).

What it verifies: Operational requirements—deployment sequences, autonomy functions, fault recovery, human interfaces, mission scenarios.

Why it works: Some requirements can't be verified by measuring a single parameter. "Spacecraft shall autonomously enter safe mode upon battery undervoltage" requires showing the entire behavioral chain: fault detection → mode transition → command execution → state verification.

How to execute:

1. Define success criteria (checklist of functions that must work)
2. Set up operational scenario (may use flight-like hardware, simulators, or actual flight)
3. Execute scenario with realistic commands/faults/timelines
4. Observe and record system responses
5. Verify all required functions executed correctly

When to use: Complex operational requirements, autonomous behaviors, deployment mechanisms (solar arrays, antennas), end-to-end communication chains, crew interfaces.

Test asks: "Does parameter X meet threshold Y under condition Z?"

• Example: "Does RF power exceed 10 W at 8.4 GHz?" → Measure with power meter and spectrum analyzer.

Demonstration asks: "Can the system perform function F in scenario S?"

• Example: "Can the spacecraft deploy its solar array and establish power-positive state after separation from launch vehicle?" → Execute deployment, watch for latch release, verify array angle, check bus voltage > threshold, confirm battery charging.

Mathematically, if a requirement has a logical structure (AND, OR, IF-THEN), it needs demonstration: $\text{Requirement met} = (A \land B \land C) \lor (D \Rightarrow E)$

If a requirement is simple inequality, it can be verified by test or analysis: $\text{Requirement met} = (x > x_{\min}) \land (x < x_{\max})$

Verification approach: Demonstration in thermal-vacuum chamber with flight-like hardware.

Step 1: Set up

• Solar array installed on spacecraft mockup
• Thermal-vacuum chamber at flight temperature (cold case: -50°C)
• High-speed cameras to record motion
• Angle sensors on hinge

Step 2: Execute demonstration

• Send deployment command via spacecraft command interface
• Observe: Restraint release, hinge rotation, latch engagement

Step 3: Measure results

• Time from command to latch: 18.3 seconds ✓ (< 30 sec requirement)
• Final angle: 89.7° ✓ (within 90° ± 2°)
• No hardware interference or anomalies ✓

Result: Requirement verified by demonstration. We didn't "test" a single parameter—we showed the entire deployment sequence works.

Choosing the Right Method

Selection criteria:

1. Can you measure it directly? → Inspection
2. Does it involve operational behavior/logic? → Demonstration
3. Is model uncertainty acceptable? → Analysis
4. Is empirical evidence required? → Test

Often multiple methods are used together. Example: "Antenna gain shall be 25 dBi ± 0.5 dB at 8.4 GHz"

• Analysis (electromagnetic simulation) during design → predicts 25. dBi
• Test (anechoic chamber measurement) for qualification → measures 25.1 dBi
• Inspection (visual check) confirms correct feed installation
• Both analysis and test verify the requirement; inspection supports it.

Why it feels right: Analysis is cheaper and faster than building hardware and running a vibration test. The model shows positive margin, so it "should" work.

The problem: Models make assumptions:

• Material properties from datasheets (actual hardware may vary)
• Perfect welds/bonds (actual hardware may have defects)
• Simplified geometry (actual hardware has holes, filets, chamfers)
• Linear behavior (actual hardware may have nonlinear contact, plasticity)

For critical structures where failure means mission loss, empirical test data is necessary. The aerospace industry learned this through failures (satellite solar array deployment failures, launch vehicle adapter cracks).

The fix: Use both analysis and test in layered approach:

1. Analysis during design to iterate quickly and optimize
2. Test for qualification to validate the model and prove the design
3. Analysis (now validated) for production units and variants

This is the standard approach for spacecraft structures: qualify one unit by test, accept others by analysis using the test-validated model.

Why it feels right: Demonstration should be realistic, so introducing a real fault makes sense.

The problem: Without pre-defined success criteria, demonstration becomes subjective. Observer bias creps in: "Well, it didn't do exactly what we expected, but it kind of recovered, so... pass?"

The fix: Before demonstration, write specific, measurable success criteria:

• ✓ "Spacecraft shall detect star tracker loss of lock within 10 seconds"
• ✓ "Spacecraft shall transition to safe mode within 30 seconds of detection"
• ✓ "In safe mode, spacecraft shall maintain sun-pointing attitude to ±5° and battery charge"

Now demonstration is objective: execute scenario, check each criterion, pass/fail with no ambiguity.

Verification Method Trade-Offs

Define:

• $C$ = cost (engineering hours + hardware + facilities)
• $R$ = residual risk (probability of undetected nonconformance)
• $\kappa$ = confidence level (subjective, 0-1 scale)

For a typical spacecraft structural component:

Analysis:

• $C_{\text{analysis}} \sim 100$ hours (modeling + simulation + documentation)
• $R_{\text{analysis}} \sim 10^{-2}$ (1% chance model doesn't capture reality)
• $\kappa_{\text{analysis}} \sim 0.7$

Test:

• $C_{\text{test}} \sim 500$ hours + $50k (hardware + facility instrumentation)
• $R_{\text{test}} \sim 10^{-3}$ (0.1% chance test doesn't represent flight)
• $\kappa_{\text{test}} \sim 0.95$

Inspection:

• $C_{\text{inspection}} \sim 10$ hours (measurement + documentation)
• $R_{\text{inspection}} \sim 10^{-4}$ (very low for static properties)
• $\kappa_{\text{inspection}} \sim 0.99$

Demonstration:

• $C_{\text{demo}} \sim 200$ hours (scenario setup + execution + analysis)
• $R_{\text{demo}} \sim 10^{-2}$ (depends on how flight-like the scenario is)
• $\kappa_{\text{demo}} \sim 0.8$

Decision rule: Minimize $C$ subject to $R< R_{\text{acceptable}}$ for the component's criticality level. For critical components (structural primary load paths, single-point failures), $R_{\text{acceptable}} \sim 10^{-3}$ → requires test. For non-critical components, $R_{\text{acceptable}} \sim 10^{-2}$ → analysis or demonstration sufficient.

Verification Traceability

Every requirement must have a verification method assigned during requirements development. The requirements verification matrix (RVM) documents this mapping:

The RVM is a living document that evolves with the project. Every verification activity updates the RVM status.

Analysis is using math. You measure the wood, look up how strong it is, calculate how much weight it can hold, and show them the math on paper. "See? The platform can hold 500 pounds, and we only weigh 200, so it's safe!" You didn't actually test it yet, but the math says it should work.

Test is actually putting weight on it. You stack sandbags on the platform—more weight than kids would be—and show it doesn't break. Now you have real proof because you actually tried it.

Inspection is your parents climbing up and looking at it. They check: Are the nails in right? Is the wood the strong kind you said you'd use? Is everything built according to the plan? They're just looking and measuring, not testing if it holds weight.

Demonstration is you and your friends actually using it like a real treehouse. Climbing the ladder, sitting on the platform, opening the roof hatch. You're showing that all the parts work together for the actual purpose.

Different promises need different profs. If you promised "the platform won't collapse," you need a test. If you promised "the trehouse weighs less than 300 pounds so the tree can hold it," you need inspection (put it on a scale). If you promised "you can climb up even in the dark," you need a demonstration (try it at night). If you promised "the roof won't leak in the worst rainstorm," you might use analysis (calculate water flow) because you can't wait for a storm.

The smart builder uses all four methods for different promises!

Connections

• Requirements Development — verification methods must be assigned during requirement writing
• Margin Philosophy — why we test to qualification levels (1.25× flight)
• Finite Element Analysis — primary tool for structural analysis verification
• Thermal Math Modeling — primary tool for thermal analysis verification
• Vibration Testing — the most common spacecraft test for mechanical verification
• Acceptance Testing — verification of flight hardware at flight levels after qual testing
• Traceability Matrix — the requirements verification matrix documents method assignments
• Model Validation — comparing analysis predictions to test data validate models
• Configuration Management — inspection verifies as-built configuration matches design

#flashcards/physics

What are the four primary verification methods in spacecraft systems engineering? :: Analysis, Test, Inspection, and Demonstration (AITD)

What does inspection verify? :: Requirements related to physical attributes that can be directly measured: dimensions, mass, materials, workmanship, and as-built configuration

When must you use test instead of analysis? :: For critical survival requirements, when model uncertainty is too high, to validate analytical models, or when empirical evidence is explicitly required by standards

Concept Map

Hinglish (regional understanding)