Top Level Architecture V:1.4.0
TERP-RAPTOR builds upon NASA's Core Flight System (cFS), using it as the foundational framework for its flight software. The open-source nature of cFS offers substantial benefits, with most applications in TERP-RAPTOR being heritage components from previous NASA missions. In addition to these legacy applications and built-in support, TERP-RAPTOR includes a dedicated application for each onboard subsystem, enabling seamless command and telemetry management across the various COTS components.
Current Toolchains/Targets
- Linux on Arm Zynq7020
- RTEMS 5.1 on Leon3FT softcore
- RTEMS 6 on Polarfire SoC
- RTEMS 6 on Raspberry PI 5
Links to Open-sourced cFS components
Software Stack & Abstraction
Software To Hardware Flow
To communicate and manage the hardware the applications make calls through shared libraries that pipe data to and from the hardware managers the exist ont the fabric. Since the majority of the system utilizes AXI register interfaces, the majority of the software simply utilizes the same AXI driver. The cameras which at the moment are communicated with through CAN utilize a seperate driver and library stack. Finally for command & telemetry there is an intermediate library, CryptoLib which is explain in the Command & Data Handling Page.
System Behavior
Fault Detection & Mitigation
TERP-RAPTOR needs to be able to catch errors and produce warnings of its own when its flying. To achieve this, I primarly utilized the Stored Command and Limit Checker applications that are provided by the opensource cFS distribution on github. The way this system works is quite simple, but extremely efficient. Every TBD ticks, the Limit Checker will check messages on the bus or in queue to see if any limits have been passed or if there are any issues with the values passed on the bus. If an anomalous value is found, the Stored Command app will be triggered to run a command that would help mitigate the issue. The command is preconfigured via the tables associated with the Limit Checker app.
System Boot Order
The series of steps the processor takes after power is turned on.