Lesson 2 of 4 · Make flight software respect the state
Make flight software respect the state
6 minute lesson · 3 checks along the way
Your goal for this lessonUse a simple operating-state model to reason about command checks, timing and testing of onboard software.
In this lesson 3 sections · 3 checks
Read & understand
Software connects measurements to actions
EgSA’s account emphasizes onboard software development. General small-spacecraft avionics handle commands, health reports, stored data and coordinated subsystem actions. Software must decide what an instruction means in the spacecraft’s present condition. The same camera request can be appropriate in one mode and inappropriate in another.
Use three invented modes: Protect, Ready and Image. Protect keeps the camera off; Ready permits an imaging request only when the defined power and pointing checks pass; Image collects a frame and then returns to Ready. These are original teaching states, not disclosed NExSat operating modes or commands.
Check 1 of 3
10 pointsUse the reading above. You can try again without losing points.
Read & understand
Check the boundary conditions
In this fictional design, imaging is allowed when the battery estimate is at least 60 percent and a pointing-ready flag is true. At 59 percent with correct pointing, the request must be rejected. At exactly 60 percent with correct pointing, it satisfies those two stated conditions. At 80 percent with the flag false, it must still be rejected.
A test set should include the threshold, both sides of it, and combinations of the conditions. The battery percentage is invented; it is not a NExSat limit. A rule can be perfectly implemented yet inappropriate for a real battery or camera, so choosing and validating the requirement remains separate from testing its implementation.
A command depends on the present state
Original teaching diagram. Original teaching states and threshold. These are not NExSat modes or commands.
Open full-size diagram in a new tab: A command depends on the present stateCheck 2 of 3
10 pointsUse the reading above. You can try again without losing points.
Read & understand
A result can be numerically right and too late
Suppose an invented control cycle must finish within 100 milliseconds. Reading inputs takes 25, calculating takes 45 and delivering outputs takes 20, totaling 90. Adding a 15-millisecond logging task inside that same serial cycle raises the total to 105 and misses the deadline. The extra feature needs a different schedule, more suitable resources or revised requirements justified by the mission.
Retain the software version, test inputs, timing measurements and observed state transitions. NASA’s open cFS framework is a separate example of reusable software: its maintainers explicitly leave mission-specific verification to each project. This does not mean NExSat uses cFS. Reusing components can save work while leaving the assembled mission’s behavior to be demonstrated.
Check 3 of 3
10 pointsUse the reading above. You can try again without losing points.
Put it together
Your lesson progress
Each check connects to a part of the story. Complete all 3 to earn your 25-point lesson bonus.
Explore further · Optional
Go to the source
Explore the evidence behind this lesson. These optional readings and videos open in a new tab.
- Read: EgSA: NExSat-1 engineering roles and first communication
- Read: NASA: onboard computing and flight softwareGeneral avionics background. The operating states, thresholds and timing examples in this course are invented, not disclosed NExSat configuration.
- Read: NASA: requirements and end-to-end verification
- Read: NASA cFS: reusable software still needs mission verificationOriginal NASA-maintained framework documentation, used as a separate software-verification example. No claim that NExSat uses this software.