Alaska Research Cubesat Operating System Gregg Christopher MSCS

Alaska Research Cubesat Operating System Gregg Christopher MSCS Graduate Project Presentation 3 11/22/2011 Alaska Space Grant Program

Introduction: • Alaska Research Cubesat (ARC) – Started in Fall 2009 with a Space Systems Engineering course. – Currently in Development; expect to fly in 2013. – First student-built spacecraft for UAF. • MS CS Project – Driven by ARC requirements. – A subset of full Command Data Handling (CDH) functionality. • Collaborative project between CS/SWE and Engineering departments. *(Image Source: ARC 1 CDR Presentation, 08/29/2011)

Cube. Sat in a Nutshell • Some Challenges: – Mechanical Design – Thermal Modeling – Power Budget – Attitude Determination and Control – Ground Communication – Computer Architecture – Error Handling *(Image Source: ARC 1 CDR Presentation, 08/29/2011)

CDH System Overview All subsystems share a set of electrical and software specifications. One subsystem is designated as Master Controller. All subsystems are connected to a Supervisor circuit responsible for reset-based fault recovery. Command Data are transmitted over a shared dedicated bus. Subsystems may be tested independently according to system specification. ARCBus Devices Included in CDH Specification Supervisor/ Reset Circuit Other Subsystems Dev/Debug Harness Electrical Power Subsystem (EPS) Power only I 2 C Command Bus SPI Data Bus Interrupt Lines Supervisor Inspection / Reset Bus Power Distribution Bus I 2 C, Power Master Controller Debug Port COMM Subsystem Compatible I 2 C Device SPI, Power Compatible SPI Device Command Uplink / Data Downlink 4

Imagine Failure • Expected Failure Modes are Single Event Upset (SEU) bit flips, and Latchup Events. • Within the failure model, assume errors are chosen adversarially to induce the worst-case scenario. • Use this mindset to steer toward simpler choices. (Source: http: //nasawatch. com)

Major Areas of This Project • System and Software Engineering • Architecture Requirements • Design Review Process • Physical Assembly • More Design Review Process • Re-Scoping for MS Project • Project Hardware Creation • Finally, Programming!

Revisiting the Scope Guidance from Advisor: • Demonstrate: – Command exchange – Error simulation – Testing Capability • Defer: + Multi-master I 2 C exchange + Representative Commands - Needs robustness - Needs “real” command structure + Works, Repeatable, Simple - Accurate space environment? + Automated Test Harness + PC-Controlled Failure and Recovery! – Complete command table. – Complicated command interactions. – Other features essential for cubesat, but not for minimally functional CDH concept. – Anything requiring more hardware development. Failure: I still had to make new circuits and other hardware workarounds

Implementation Progress • Functional in most areas. • Many areas not yet complaint with CDR. • Following Strategy From Talk 2: – Basic unified firmware. – Tools for automation. – Representative command set – Test case generation.

Test Harness Archictecture PC Software Interactive Toolset Optional Integration Test Scenario Generator Manual or Scripted Command Exchange Standalone Controller Reset Control Automated Test Rig Comm Interface FT 245 Library Dev Board Emulator Class Serial Library Test Hardware Subsystem Peripheral Switched Power Supply ARC Bus Dev Board Subsystem Peripheral Dev Board

Test Command Table: • • Set LED Pattern Report LED Pattern Remote Set LED Pattern (Across Boards) Set Work Area Buffer Segment Read Work Area Buffer Segment Perform Calculation on Buffer Send Buffer Segment to Other Board Flip Bits (Intentionally corrupt memory)

Test Sequence Generation: • Commands are generally paired with verification commands. • Random or pre-programmed sequences of operations. • Vary the selection, speed and distribution of operations per test requirements. • Induce Simulated Single Upset Events. • Automatically Reset on Error and Repeat. Test Harness Interface (dev boards unplugged)

Error Simulation: • Simulated Single Event Upset (SSEU) – Flip bits in addressable memory. – Register corruption will be harder. • Non-addressable volatile memory? • Error simulation does not replace other testing and review.

Error Mode Categorization: • Recoverable Error: Any change to memory that can be reverted to a previously known state. (Currently only redundant memory. ) – Immediate Action: correct and continue – Roughly 1 -2% of SSEU result in this condition. (Trivial and uninteresting result. ) • Non-Recoverable Error

Error Mode Categorization: • Non-Recoverable Error: Everything else that happens. – Recover via reset. – Currently very high. – High rate means that what I’m probably detecting are weaknesses in the firmware. • This shouldn’t be surprising! (First large project on platform) • Probably the lack of error detection/recovery in I 2 C Multi. Master implementation • Might also be bad interrupt programming. – Still a valuable result! These are errors that didn’t occur during manual, interactive testing.

Project Status Summary: • Developed: – Hardware and firmware that implement rudimentary CDH functionality. – PC software for automated and interactive testing. – Toolchain development to reduce the barrier to entry. – Drop-in testing environment for dev boards. • Tested: – Runs of firmware with sample command set for preliminary testing results.

Next Steps (This Project) • • • Deliver draft Eliminate sources of systematic error Improve error simulation Characterize Space Environment Validate with radiation-induced SEU and latchup events.

Next Steps (Cubesat) • Immediate need for CDH code for other system development. – An outcome of this MS Project is: I’ve done a lot of things wrong; help the group avoid these. – Robust μC firmware is exceedingly difficult. • Bring Supervisor Circuit in line with CDR Design • Establish Test Harness in the Lab

Thanks for Attending! Gregg Christopher: – gchristopher@gmail. com