THE PHOENIX ARCHITECTURE

A New Approach to Student Satellite Software

Riley PackUniversity of Colorado at Boulder

Pack 2

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

Pack 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

Development Process• Following Agile Development Methods

• Iterative Design• Test-Driven Development• Constant Customer Feedback• Object-Oriented Design

• Written in C++

Pack 13

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

Pack 14

Architecture Design

Pack 15

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 16

Phoenix Core• Heart of the Software System• Required for All Systems• Major Components

• Message Routing System (Dispatcher)• File System• Logging Mechanism

Pack 17

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 18

Dispatcher: Usage

Dispatcher::Dispatch()

Dispatcher::Listen() MessageHandler::Handle()

Dispatcher::WaitForDispatchResponse()

From Sending Server

To Sending Server

Sending Server Receiving Server Utility Task

Pack 19

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 20

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 21

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 22

ALL-STAR Flight Software DiagramLegend

Communication Server

Payload Control Server

Com

man

d Se

rver

Flight Mode Server

Power Control Server

Attitude Determination

Server

Attitude Control Server

File

Sys

tem

Authentication Server

GPS Server

Propulsion Control Server

Thermal Control Server

Error Handling Server

Hardware Abstraction Layer

Sate

llite

Tim

e Se

rver

Dispatcher (Shown for Internal Servers Only)

FSW Internal Server

Subsystem Server

Core System

Dispatcher MessageFile System CallHAL Call

Sens

or S

erve

r

Pack 23

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 24

Questions?

Pack 25

References• [1] Frederik P. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering," IEEE Computing, vol. 20, pp. 10-19, 1987.

• [2] FreeRTOS. [Online]. http://www.freertos.org• [3] Raj Srinivasan. (1995, August) RFC1832 - XDR: External Data Representation Standard.

• [4] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns. Westford, Massachusetts: Addison-Wesley, 1995.