tpt-astrobus

Rust

A #![no_std], memory-safe Rust flight software bus for small satellites — zero-copy message bus, FDIR, CCSDS/CFDP, and ADCS/EPS/Thermal/Comms drivers, no heap, no alloc.

0 stars0 forks0 watchersApache License 2.0

Languages

Rust100.0%
README

TPT-AstroBus

A complete, modular, Rust-native flight software (FSW) bus for small satellites (LEO / smallsats). It is the entire operating environment for a satellite — not a single component — providing the Application Framework, Executive Services, a zero-copy message bus, an FDIR engine, CCSDS/CFDP space protocols, and ADCS/EPS/Thermal/Comms subsystem drivers, all with guaranteed memory safety.

Built #![no_std], with a strictly static, compile-time-bounded memory strategy. No heap, no alloc, no fragmentation, no out-of-memory panics in orbit.

Why

Small-sat flight software is dominated by NASA's legacy C-based Core Flight System (cFS) and fragmented proprietary C++ codebases — systems that suffer from memory corruption, pointer errors, and painful concurrent task management. TPT-AstroBus replaces shared-memory pointers with strictly-typed, zero-copy, lock-free message queues, eliminating whole classes of race conditions and memory bugs at compile time.

Architecture

┌──────────────────────────────────────────────────────────────┐
│                      Application Framework                    │
│   ADCS │ EPS │ Thermal │ Comms │ (mission apps)              │
├──────────────────────────────────────────────────────────────┤
│                      Executive Services                       │
│   astrobus-sched (custom preemption)  │  astrobus-embassy     │
├───────────────────────────┬──────────┴───────────────────────┤
│      Message Bus          │           FDIR Engine            │
│   (astrobus-core)         │        (astrobus-fdir)           │
├───────────────────────────┴──────────────────────────────────┤
│   astrobus-ccsds │ astrobus-cfdp │ astrobus-tlm │ astrobus-hal│
├──────────────────────────────────────────────────────────────┤
│              astrobus-alloc  (static arena + pools)           │
└──────────────────────────────────────────────────────────────┘

Subsystems communicate only through the message bus — never through shared mutable state.

See ARCHITECTURE.md for the full layered design, data-flow diagrams (uplink / downlink / FDIR), and the scheduler-backend model.

Crates

CratePurposeStatus
astrobus-allocConst-generic static arena allocator, object pools, fixed-capacity collections✅ v0.1
astrobus-coreMessage envelope, zero-copy queues, message bus, executive-services trait✅ v0.1
astrobus-schedCustom Rust-native priority scheduler + Embassy adapter (feature-flagged backends)✅ v0.1
astrobus-fdirFault Detection, Isolation, Recovery engine✅ v0.1
astrobus-ccsdsCCSDS Space Packet Protocol✅ v0.1
astrobus-cfdpCCSDS File Delivery Protocol (fully compliant)✅ v0.1
astrobus-tlmTelemetry / telecommand serialization✅ v0.1
astrobus-halHardware abstraction (embedded-hal extensions, QEMU targets)✅ v0.1
astrobus-adcs / astrobus-eps / astrobus-thermal / astrobus-commsSubsystem driver traits + simulated reference impls✅ v0.1
astrobus (meta)Re-exports the sub-crates behind feature flags + example image✅ v0.1

Memory strategy

Space-grade processors are slow and lack MMUs, making dynamic allocation dangerous. TPT-AstroBus allocates everything at compile time using Rust const generics and arena allocators. Capacity is a const parameter, so the linker reserves exactly the memory you need and the compiler rejects anything that would overflow it. Exhaustion is handled by Option/Result, never by a panic.

Getting started

cargo build --workspace
cargo test  --workspace

See each crate's README.md for details. The recommended first publish is astrobus-alloc + astrobus-core (this 0.1.0), with protocols and drivers landing in later minor versions.

Release process, MSRV policy, semver policy, and the dependency-ordered publish list are documented in RELEASING.md.

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.