THE PHOENIX ARCHITECTURE A New Approach to Student Satellite Software Riley Pack University of Colorado at Boulder

Introduction What Makes Student Satellite Software Difficult? Custom hardware for each mission Limited time and resources Software must support bus and payload operation Pack 2

Introduction Common Approach to Student Satellite Software Write all software from the ground up New architecture design for each mission Spend a significantly longer amount of time on bus software than payload software Complex interfaces and dependencies between software components Pack 3

What is Phoenix? Software Architecture for Student Satellite Projects Object-oriented software system Built with modularity and reuse in mind Shifts focus from bus software to payload software Pack 4

The Phoenix Approach Write Software Only Once If functionality already exists, why reinvent the wheel? Focus only on new functionality This is the interesting part of the software and the project! Allow software to be reused from one project to the next Pack 5

The Phoenix Approach Decouple Software from the Hardware Provide a Hardware Abstraction Layer (HAL) to interface with the satellite hardware Allows software to be shared between many projects Will hopefully lead to a large repository of software modules Pack 6

The Phoenix Approach Decouple Dependencies Between Software Modules Remove hard dependencies between any two systems in the software Allows modules to be added or removed from the system Allow all modules to communicate through a standardized interface Pack 7

Attacking the Essences Four Major Essential Difficulties of Software Development Phoenix Aims to Attack Three Essences Complexity, Conformity, Changeability Invisibility not addressed directly by Phoenix Essences are the Root of Development Snags and Difficulties Pack 8

Attacking the Essences: Complexity Phoenix Decouples Dependencies Between Systems Uses standardized commands to communicate between modules Developers only need to focus on one small subsystem Removing one module does not directly break another Pack 9

Attacking the Essences: Conformity Standardized Commands Remove the Need to Conform to Numerous Interfaces All modules interact in the exact same way Subsystem do not need to design the interface method Instead, provide commands to perform an action Pack 10

Attacking the Essences: Changeability Architecture Built with Change in Mind Modules can be added/removed at any time No hard dependencies between modules Interface extensible through addition of commands Pack 11

Development Process Following Agile Development Methods Iterative Design Test-Driven Development Constant Customer Feedback Object-Oriented Design Written in C++ Pack 12

Development Process Allows for Rapid Response to Functionality Changes Requirements expected to change Software “grown” instead of built Always have a working system Pack 13

Architecture Design Pack 14

Architecture Components Phoenix Core Provides basic services to servers Hardware Abstraction Layer Allows software to run on multiple hardware configurations Phoenix Servers Implement specific functionality Communicate with each other through the core Pack 15

Phoenix Core Heart of the Software System Required for All Systems Major Components Message Routing System (Dispatcher) File System Logging Mechanism Pack 16

Dispatcher Allows Servers to Send Messages to Each Other Commands, Data Requests, Errors, etc. Standardized Interface for All Servers Send Message: Dispatcher::Dispatch() Receive/Handle Message: Dispatcher::Listen() Pack 17

Dispatcher: Usage Pack 18

Hardware Abstraction Layer Decouples Software from Hardware No direct dependencies on hardware by Phoenix Core or other modules Standardized Hardware Interactions Allows for Testing of All High-Level Software on a PC Pack 19

Phoenix Servers Encapsulate a Specific Functionality for the System Examples: Communication Server, Payload Control Server, Flight Mode Server Must Communicate with Other Servers Through Dispatcher Ensures no hard dependencies between servers Allows Each Mission to Add Functionality to System as Needed Pack 20

First Application of Phoenix ALL-STAR Project at CU-Boulder 3U CubeSat designed to accommodate a wide variety of space-borne payloads Requires a large amount of software customization from mission to mission Pack 21

ALL-STAR Flight Software Diagram Pack 22

Project Status In the Process of Implementing the Core and the HAL Dispatcher written and tested HAL and file system in progress Test Servers to Demonstrate Functionality in Development Initial Server Development to Begin this Summer Pack 23

Questions? Pack 24

References [1]Frederik P. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering," IEEE Computing, vol. 20, pp , [2]FreeRTOS. [Online]. [3]Raj Srinivasan. (1995, August) RFC XDR: External Data Representation Standard. [4]Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns. Westford, Massachusetts: Addison-Wesley, Pack 25