FLIGHT SOFTWARE · COMMAND / TELEMETRY · FDIR · ASSURANCE · RASPBERRY PI
ASTRA-OS is a C++17 flight-software testbed for command validation, telemetry, mode management, FDIR, fault injection and requirements-based verification.
The architecture, telemetry timelines and assurance counts below come directly from the public repository. The interactive console is labeled separately because it is a browser model of the documented state machine, not the native C++ executable.
4150e97; frozen reports retain their tested-commit counts.Pinned sourceEvidence guide
Command decoding, replay/freshness guards and execution authorization are separate boundaries before state mutation. Telemetry and provenance-bound verification close the loop around the deterministic flight core.
Open source diagram
The preserved demo sequence leaves BOOT for NOMINAL, enters DEGRADED_PAYLOAD on the injected CPU-overload path, then returns to NOMINAL after fault clear and an accepted SET_MODE command.
Open source timeline
The same sequence makes the injected CPU_OVERLOAD interval and subsequent clear visible in telemetry. This is a software-policy response, not proof of every physical detector or recovery mechanism.
Open source timelineUse the public console to issue documented commands and faults and observe modeled mode, fault and telemetry responses. It is intentionally not described as WebAssembly, the native executable or a live Raspberry Pi session.
Writing a mode manager or UDP packet parser is easy to demonstrate. Showing that the software rejects the wrong command, enters a safe state on the right fault, bounds recovery attempts, preserves event history and remains traceable to requirements is the harder engineering problem.
ASTRA-OS treats that verification chain as part of the product rather than a report written after implementation.
The command path explicitly distinguishes packet integrity, freshness/replay policy, execution authorization and semantic validation. CRC detects corruption in the tested model; it is not presented as cryptographic authentication.
These counts summarize the current repository tree. Frozen completion and release reports keep the smaller Python-tool counts measured at their own commits; the repository reports and CI remain authoritative if the implementation evolves.
The completion campaign built and executed the portable core natively on Ubuntu 24.04 aarch64 with a Raspberry Pi kernel. The collection interface did not expose an authoritative board or SoC model, so the project does not guess one.
| Campaign | Observed result | Scope |
|---|---|---|
| Native test run | 20/20 CTest suites passed | Pinned target campaign |
| Nominal timing | 250,000 ticks; 0 detected misses | Faster-than-real-time process measurement |
| Controlled overrun | 99 expected misses detected in 100,000 ticks | Synthetic overload every 1,000 ticks |
| Soak | 1,000,000 ticks; 0 detected misses | Pinned process/configuration |
These are native target-execution and process measurements. They are not spacecraft hardware-in-the-loop, WCET, schedulability, hard-real-time qualification or operational reliability evidence.
Inspect the completion report and timing tables
The interactive console is a recruiter-friendly way to exercise the documented state machine and fault responses. It models the behavior; it is not the native executable, a WebAssembly build, or a live Raspberry Pi process.
Software architecture: deterministic state machines, protocol boundaries, scheduling and event semantics.
Verification: testing normal behavior is only one layer; stale/replayed commands, simultaneous faults, recovery exhaustion and mutation/fuzz cases matter too.
Systems thinking: requirements are useful when they terminate in executable checks and reverse traceability can identify tests with no declared purpose.
Communication: the project distinguishes command authorization policy from cryptographic identity and hardware execution from real-time qualification.