1. Purpose of Domain F
Domains A–E establish the theoretical and computational foundations of space mechanics and GNC. Domain F focuses on how those foundations are used in practice, where results depend on geometry, operational constraints, and imperfect models.
Key idea
Domain F is about reasoning: understanding why a result appears, not just computing it.
2. Standard Case Study Structure
Each case study in Domain F follows a common template:
- Problem Statement — the mission or operational question.
- Success Metrics — coverage, latency, pointing error, custody time.
- Assumptions & Constraints — geometry, sensors, dynamics fidelity.
- Method — what is analyzed analytically vs in STK.
- Results — what changes, and what parameter dominates.
- Validation — sensitivity checks and cross-comparisons.
- Key Takeaways — concise engineering lessons.
3. How to Read Case Study Results
Domain F emphasizes interpretation over raw numbers. When reading plots and tables, focus on trends and constraints rather than isolated values.
- Coverage does not imply persistence or low latency.
- Better revisit may increase downlink or scheduling conflicts.
- Pointing accuracy must be considered alongside actuator limits.
- SSA detection differs from long-term custody.
4. Validation Mindset
Disagreement between models or tools is expected. In Domain F, mismatch is treated as diagnostic information rather than error.
- Check time alignment and sampling.
- Confirm Earth models and elevation masks.
- Verify sensor geometry and pointing assumptions.
- Assess sensitivity to step size and model fidelity.
Key idea
A mismatch often reveals which assumption truly controls mission performance.
5. Suggested Learning Paths
- Mission Analysis: F.1 → F.2 → F.10
- GNC: F.4 → F.5 → F.6 → F.10
- SSA: F.7 → F.8 → F.9 → F.12