Model Based Systems Engineering (MBSE) Applied toRadio Aurora Explorer (RAX) CubeSat Mission

Operational ScenariosSara C. Spangelo

James CutlerUniversity of Michigan

1320 Beal StreetAnn Arbor, MI 48104

saracs@umich.edujwcutler@umich.edu

Louise AndersonElyse FosseLeo Cheng

Jet Propulsion LaboratoryCalifornia Institute of Technology

4800 Oak Grove DrivePasadena, CA 91109

louise.anderson@jpl.nasa.govelyse.fosse@jpl.nasa.govleo.y.cheng@jpl.nasa.gov

Rose YntemaManas Bajaj

InterCAX75 Fifth Street NW, Suite 312

Atlanta, GA 30308rose.yntema@intercax.commanas.bajaj@intercax.com

Chris DelpBjorn Cole

Jet Propulsion LaboratoryCalifornia Institute of Technology

4800 Oak Grove DrivePasadena, CA 91109

chris.delp@jpl.nasa.govbjorn.cole@jpl.nasa.gov

Grant SoremekumPhoenix Integration

1715 Pratt Drive, Suite 2000Blacksburg, VA 24060

grant@phoenix-int.com

David KaslowAnalytical Graphics

220 Valley Creek Blvd.Exton, PA 19341

dkaslow@agi.com

Abstract—Small spacecraft are more highly resource-constrainedby mass, power, volume, delivery timelines, and financial costrelative to their larger counterparts. Small spacecraft are oper-ationally challenging because subsystem functions are coupledand constrained by the limited available commodities (e.g.data,energy, and access times to ground resources). Furthermore, ad-ditional operational complexities arise because small spacecraftcomponents are physically integrated, which may yield thermalor radio frequency interference.

In this paper, we extend our initial Model Based Systems En-gineering (MBSE) framework developed for a small spacecraftmission by demonstrating the ability to model different behav-iors and scenarios.

We integrate several simulation tools to execute SysML-basedbehavior models, including subsystem functions and internalstates of the spacecraft. We demonstrate utility of this approachto drive the system analysis and design process. We demonstrateapplicability of the simulation environment to capture realisticspacecraft operational scenarios, which include energy collec-tion, the data acquisition, and downloading to ground stations.

The integrated modeling environment enables users to extractfeasibility, performance, and robustness metrics. This enablesvisualization of both the physical states (e.g. position, attitude)and functional states (e.g. operating points of various subsys-tems) of the spacecraft for representative mission scenarios.

The modeling approach presented in this paper offers spacecraftdesigners and operators the opportunity to assess the feasibilityof vehicle and network parameters, as well as the feasibility ofoperational schedules. This will enable future missions tobenefitfrom using these models throughout the full design, test, andfly cycle. In particular, vehicle and network parameters andschedules can be verified prior to being implemented, duringmission operations, and can also be updated in near real-timewith operational performance feedback.

978-1-4673-1813-6/13/$31.00 c©2013 IEEE.1 IEEEAC Paper #2170, Version 1, Updated 29/01/2013.

TABLE OF CONTENTS

1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 MBSE AND SYSML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 CUBESATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4 MODEL -BASED ENGINEERING ENVIRONMENT . 5

5 RAX CUBESAT M ISSION . . . . . . . . . . . . . . . . . . . . . . . . 5

6 ANALYTICAL M ODEL AND RESULTS . . . . . . . . . . . . 7

7 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . .16

REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

BIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

1. INTRODUCTION

MBSE Applied to CubeSats

This paper extends the work reported in our 2012 IEEEAerospace conference paper [1], which reported on usingModel Based Systems Engineering (MBSE) and the SystemsModeling Language (SysML) to model a standard CubeSat,and applied that model to an actual CubeSat, the RadioAurora Explorer (RAX) mission [2], [3].

A CubeSat is a type of miniaturized spacecraft with a stan-dard form factor based on standardized cubes with a size of103 cm3 and weighing less than one kilogram. CubeSatstypically consist of one to three cubes.

RAX is the first CubeSat funded by the National ScienceFoundation (NSF) [4]. It is a space weather mission designedto study plasma field-aligned irregularities in the ionosphere.It has enabled undergraduate students, graduate researchers,engineers, and scientists to be involved in the design, build-ing, and operations of two spacecraft (RAX-1 and RAX-2).

1

INCOSE MBSE Challenge Project

This project is a key part of the International Council onSystems Engineering (INCOSE) MBSE Challenge project.The Challenge project was initiated at the January 2007INCOSE International Workshop [5]. The MBSE Roadmap,Figure 1, was created to define the high-level, long termvision for the maturation and acceptance of MBSE acrossacademia and industry.

Several MBSE Challenge teams were established to promoteMBSE, advance the state of practice, and share lessonslearned related to a diverse range of:

• MBSE applications

• Model scope

• Model quality and robustness

• Modeling standards

• MBSE process, methods, tools, and training

Space Systems Challenge Team

The INCOSE Space Systems Working Group (SSWG) estab-lished the Space Systems Challenge team. The Challengeteam initially included aerospace students and professorsfrom Massachusetts Institute of Technology and Georgia In-stitute of Technology. The initial focus was on the modelingof a hypothetical FireSat space system [6]. FireSat is a lowEarth orbit (LEO) spacecraft for detecting, identifying, andmonitoring forest fires. This representative, however non-realistic, textbook example was used in order to sidestepthe challenges of working with International Traffic in ArmsRegulations (ITAR) in an international collaboration. Thisspace system is used as an example in the widely usedand accepted Space Mission Analysis and Design (SMAD)textbook [6]. Much was learned from modeling FireSat.

Our follow-on CubeSat project was initiated in April 2011 tomodel an actual space system, a standard CubeSat, with theRAX spacecraft being the point design.

The team now includes University of Michigan Aerospacegraduate students and a departmental professor; the INCOSESSWG, including engineers from NASAs Jet Propulsion Lab-oratory (JPL) and from modeling and simulation tool vendorsInterCAX, Phoenix Integration and Analytical Graphics, In-corporated.

The collaborative environment includes a CubeSat - MBSEGoogle group, a MBSE Google documents collection, aNo Magic Teamwork server for SysML modeling, and bi-weekly/weekly Web conferencing.

Advancement and Demonstration of MBSE State of Practice

Our Challenge team and project was created to assess, ad-vance, and demonstrate the application of MBSE to a realisticmission in the space systems domain.

We are developing a SysML modeling framework and ModelBased Engineering Environment for developing CubeSatmodels. The models formally describe the RAX missionusing a domain specific extension of SysML made especiallyfor CubeSat modeling. This environment incorporates severalcommercial off-the-shelf (COTS) tools:

• MagicDraw

• Cameo Simulation Tool Kit

• ParaMagic

• Systems Tool Kit

• PHX Model Center

• MATLAB

We have built analysis models that analyzes the RAX systemmodel to analyze:

• Communication subsystem signal to noise ratio

• Solar energy collection and subsystem power consumption

• Activity flow including behaviors and interactions

2. MBSE AND SYSMLMBSE is the formalized application of modeling to supportsystem requirements, design, analysis, optimization, verifica-tion and validation, beginning in the conceptual design phase,continuing throughout development and into later life cyclephases including operations [7], [8].

One of the goals of MBSE is to transform the applicationof systems engineering by integrating information commu-nication and analysis of systems engineering products. Thisgoal is simply not possible in the current document-centricenterprise and thus we intend to replace it with a model-basedapproach.

Our application of MBSE uses SysML as the modelinglanguage for formally describing and specifying the system.SysML is a graphical modeling language for modeling sys-tems. It is used to specify, analyze, design, optimize, andverify systems and their hardware and software components.SysML was developed by INCOSE and the Object Manage-ment Group (OMG) [9].

Figure 2 illustrates the SysML diagram types. A system isdescribed in terms of:

• Structural models illustrating the constituent elements of asystem and their connections (using block diagrams).

• Behavioral activity and state models describing opera-tional behaviors.

• Parametrics definitions for operational constraints andacausal behaviors specified by values and/or equations.

• Requirements text based requirements in the model thatcan be traced to design, analysis, and verification elements.

SysML is used to formally specify all aspects of a systemeither directly or by interfacing with other models. It enablessystems engineers to create and evolve models in an inte-grated, collaborative, and scalable environment. It enablesbuilding models that can be used in early design stages thatcan support specification and design updates. Using modelsto define, develop, and ultimately operate a system is knownas “Develop With What You Fly With” (DWWYFW) [8].

2

2025 2010 2020

Distributed & secure model repositories

crossing multiple domains

Defined MBSE theory, ontology, and formalisms

Architecture model integrated with

Simulation, Analysis and Visualization

Matured MBSE methods and metrics

Integrated System/HW/SW models

Emerging MBSE Standards

Refer to activities in the

following areas:

Planning & Support

Research

Standards Development

Processes, Practices, & Methods

Tools & Technology Enhancements

Outreach, Training & Education

Extending Maturity and Capability Institutionalized

MBSE across

Academia/Industry

Ad Hoc MBSE

Document Centric

Matu

rity

Well

Defined

MBSE

MBSE Capability Reduced cycle times System of systems

interoperability

Design optimization across broad trade space

Cross domain effects based analysis

Figure 1. MBSE Roadmap

Figure 3 illustrates that the MBSE environment is an integra-tion of modeling tools and design tools along with viewingand report generation tools. This integration facilitatestheanalysis of alternative design models, and supports robustdesign optimization.

The ability to integrate, collaborate, and scale is centeredaround having a model repository. The repository is aninformation resource that is accessible through basic web-based technologies in addition to desktop applications. Avariety of model editors can be integrated with such a repos-itory, enabling engineers of all disciplines to collaborate.This integration is facilitated by the use of standard SysMLapproaches. Using Internet technologies to implement thisapproach provides a nearly unlimited ability to scale.

3. CUBESATS

CubeSats are a type of low-cost, standardized nanospacecraftthat consists of one or more units (Us). A 1U is a cube 10 cm3

on a side and approximately 1 kg [10]. These small spacecraftare typically launched as secondary payloads. They have en-abled the university community to design, build, and launchspacecraft using primarily COTS components. More recently,the worldwide community has adopted the CubeSat standardas a means of performing novel scientific, surveillance, andtechnology demonstration missions at significantly reducedcost and with short development timelines.

Current Approach to CubeSat Design

The current approach to design vehicles and perform oper-ational planning for CubeSat missions is largely intuition-based, and often relies on simplified trade-studies that do not

explore the complete design space [6]. Furthermore, ad-hocand often unverified approaches are used to combine multiplesimulation environments that often critical neglect elementsof the mission dynamics. Designing the spacecraft at an earlydevelopment stage and neglecting key operational parameters(because they are often unknown or not modeled)can beproblematic because decisions made in early design stagescan have a significant impact on mission operations. Forexample, if a battery is sized prior to performing operationalsimulations, it may be of insufficient capacity to sustain thespacecraft throughout extended eclipse durations and thusthe spacecraft may not be able to satisfy mission operationsrequirements.

MBSE Approach to CubeSat Design

Our 2012 IEEE Aerospace conference paper delineated theCubeSat modeling objectives [1].

The current modeling effort is well under way, and we haveaccomplished many of the early work objectives. Our overallplan is to develop a CubeSat model development kit for theCubeSat community that will include (some of which havealready been accomplished):

• A CubeSat meta-model describing CubeSat specific con-cepts and a modeling framework. The framework providesSysML structural and behavior models for the:

– Mission:∗ Mission elements which are systems that achieve the

mission objective

∗ Mission environment, e.g. space particles and fields aswell as Earths atmosphere layers and magnetic fields

3

Activity

Diagram

Sequence

Diagram

State

Machine

Diagram

Use

Case

Diagram

Block

Definition

Diagram

Internal

Block

Diagram

Requirement

Diagram

Behavior

Diagram

SysML Diagram

Package

Diagram

Structure

Diagram

Parametric

Diagram

Figure 2. SysML Diagram Types,c©Sanford Friedenthal, Elsevier Inc., 2012. All Rights Reserved

Simulation and

Analysis Modeling

Tools

Automated View

and Report

Generation Tools

Hardware and

Software Design

Tools

Model

Repository

Figure 3. Model-Based Engineering Environment

– Flight system

– Ground system

• An example CubeSat model that existing and future teamscan use as a template for describing and modeling theirown spacecraft, optimizing spacecraft design, and evaluatingmission operations.

• The model will include:

– The entire spacecraft mission including flight system,ground system, and targets of interest

– Key spacecraft structural components, including systems,subsystems, and components and their interfaces

– Key spacecraft system and subsystem behaviors

– Key spacecraft constraints and measures of effectiveness

The model will provide the techniques to interface Cube-

Sat SysML models with a diversity of COTS modeling,analysis, and visualization tools. These tools can be usedto extract the necessary information to solve a problem oranalyze a relevant part of the system and then integrate theinformation/solution back into the mission specification.Forexample, an optimization algorithm may have as inputs thespacecraft position and opportunities to collect energy anddata and output an operational schedule that can be interfacedwith the exectue SysML model.

The model will enable verification that design updates com-ply with mission requirements. The model also helps effec-tively communicate design updates to all engineers workingon the mission.

Ultimately the models will be used by mission operatorsto evaluate mission plans, generate schedules, and generateoperational strategies that considering dynamic states such asspacecraft position, attitude, on-board energy, data, andther-mal states. This is of paramount importance when respondingto spacecraft component degradation and anomalies.

4

4. MODEL -BASED ENGINEERINGENVIRONMENT

A key capability of a so-called model-based engineering en-vironment is the integration of modeling applications, repos-itories, and analysis applications. Figure 3 illustrates such arepresentative environment, which enables us to analyze andoptimize system performance. The simulation environmentbrings to life the models described in the previous section,where various aspects of the system model, such as paramet-rics, activities, and state machines, can be executed.

Conventional approaches for small spacecraft design andoperational planning often consist of simulators that are“hacked” together in an ad-hoc manner, or require manualand time-consuming tasks to pass information between simu-lators. Unlike these approaches, our simulation environmentsupports the automated flow of information between simula-tors, enabling users to easily evaluate different design con-figurations or reconfigure the analysis for different missionscenarios in a rapid and convenient way.

Next we list and describe the modeling and analysis applica-tions in our MBSE environment that are used to develop andexecute models:

• MagicDrawR© from No Magic is a graphical SysML mod-eling tool that enables the analysis and design of systemsusing standardized databases

• Cameo Simulation ToolkitR© (CST) from No Magic is anorchestrated heterogeneous simulation environment. CST in-tegrates fUML, SCXML, and the Java math engine ot providea coordinated analysis of a SysML model. It enables differentMBSE behavioral models such as SysML State Machines andActivity Diagrams to be executed within MagicDraw.

• STK R© from Analytical Graphics, Incorporated (AGI) is atool that supports high fidelity simulation and visualizationof spacecraft behavior including orbital dynamics and space-craft subsystems models for power, thermal, sensors, attitudecontrol, and telemetry.

• MATLAB R© provides powerful numerical computing forevaluating functions, executing algorithms, and plottingre-sults. MATLAB can also interface with other optimizationtools and solvers.

• ParaMagicR© from InterCAX is a SysML parametric solverand integrator for MagicDraw. It enables the executionof SysML parametric models and performing system tradestudies through all stages of system development. ParaMagiccan execute mathematical constraint relationships or wrapexternally-defined models such as MATLAB/SimulinkR© ,MathematicaR©, or Excel. ParaMagic leverages the acausalnature of SysML parametric relationships to execute modelsin different causalities, i.e. change inputs and outputs on-the-fly. It can detect and solve complex SysML block andparametric model structures, such as complex aggregates,recursion, and property and constraint redefinitions in themodel hierarchy. Equivalent tools MelodyR©, SolveaR©,and ParaSolverR© are available for RhapsodyR©, EnterpriseArchitectR©, and Artisan StudioR© , respectively.

• PHX ModelCenter R© from Phoenix Integration allowsusers to create and execute simulation workflows by inte-grating various types of simulation models, including Excelspreadsheets, STK scenarios, and MATLAB scripts. Once asimulation workflow is created, PHX ModelCenter executes

the workflow, automatically transferring data between thesimulators. Users are able to execute multi-run studies byemploying a rich set of trade study algorithms, optimizationtools, and reliability analysis. PHX ModelCenter can also beused to execute parametric models developed in MBSE toolslike MagicDraw and Rhapsody, enabling the user to evaluateperformance and verify requirements throughout the designprocess.

This diverse set of modeling and analysis applications cov-ers a broad range of capability for building and analyzingmodels with a particular emphasis on model and analysisintegration. This integration capability is key to building ascalable model-based engineering environment that can sup-port the full life-cycle of MBSE on a spacecraft developmentprogram.

Several diverse tools were used to demonstrate how diversetools could be integrated into a common framework. Notethat a different or smaller set of simulation or calculationtoolscould be utilized to accomplish similar goals.

5. RAX CUBESAT M ISSION

Mission Description

RAX is a space weather mission designed to study plasmafield-aligned irregularities in the ionosphere [2], [3]. RAXperforms experiments using a bi-static radar configurationwhich utilizes a high-powered ground-based radar station.The primary station is PFISR, located in Poker Flat, Alaska,as shown in Figure 4. The ground-based radar sends ahigh- powered signal that reflects off the irregularities andare measured by RAX. Highly accurate on-board timing andposition is provided by a GPS receiver, which are required tosatisfy the mission requirements. Rough timing is providedby on-board clocks and rough position knowledge is providedby ground-based tracking systems, which is necessary foroperations not related to science experiments.

Figure 4. Radio Aurora Explorer (RAX) CubeSat MissionBistatic Radar Configuration

RAX is passively magnetically aligned with the Earth’smagnetic field using on-board fixed magnets, as shown inFigure 5. Spacecraft attitude oscillations are dampened withhysteresis material. This type of attitude control systemenables RAX to have its experimental (which are also used

5

Figure 5. STK-generated schematic of RAX spacecraft with vectors pointing towards the experimental zone, Poker Flat, AK,the sun, and along the Earth’s magnetic field.

for communication) antennas pointed towards the Earth whenit passes over the experimental zone near the North Pole.Furthermore, the GPS antenna was installed on the spacecraftface opposite the experimental antenna, is orientated towardsthe GPS constellation during experiments, when accuratetiming and position is critical.

RAX-1 was launched in October of 2010 and RAX-2 waslaunched in November of 2011. At the time of writing(January 2013) RAX-2 is performing experiments and beingoperated on a daily basis from the command station at theUniversity of Michigan in Ann Arbor and downloading toground station partners located around the world.

RAX SysML Model

The RAX spacecraft SysML models are based on the oper-ational spacecraft framework developed in Ref. [1]. TheSysML representations in this section provide a visual rep-resentation of the RAX model. They describe the systembehavior and can be applied to evaluate the system using thesimulations and the performance metrics.

Figure 6 shows the RAX Block Definition Diagram (BDD)consisting of the RAX Launch System, RAX Environment,and RAX Mission. The majority of this paper focuses onthe RAX Mission. However; the RAX Launch System andRAX Environment are also important to capture the completesystem.

The RAX Mission model consists of both logical and phys-ical models. The logical models consider the operations ofthe system while the physical models consider the physicalcomponents. The decomposition strategy is typically used byCubeSat designers to separate functionality into subsystemsthat correspond to logical concepts. For the CubeSat model,logical subsystem models describe the different conceptsrequired to define the desired behavior of the system. Thephysical models specify the hardware and software that real-ize the logical design. For an example of this physical/logicalmodel distinction, consider the Power subsystem. One of

its logical functions is to store energy, while the physicalbattery hardware implements that functionality. Developingboth logical and physical models allows the spacecraft sys-tems engineers to clearly define the difference between thefunctionality (using logical models) and the hardware thatsupports this functionality (using physical models).

The focus of this paper is on the operations of the RAXsystem, thus we focus on the logical models. As describedin Ref. [1], RAX has several functional subsystems, eachsupporting at least one critical part of the mission or othersubsystems, which are described in Ref. [11]. The InternalBlock Diagram (IBD) shown in Figure 7 illustrates key prop-erties and interactions of the subsystems for the RAX LogicalFlight System.

The Power Collection and Control subsystem is responsiblefor acquiring energy by body-fixed solar panels, distributingpower to support ongoing operations, and storing excess en-ergy for future use in an on-board battery. The On-board DataHandling and Command Dispatcher subsystem is responsiblefor dispatching commands, and managing the storage of on-board data. The Mission Data Handling subsystem is re-sponsible for processing, compressing, deleting, and filteringdata for the spacecraft payload (e.g. scientific payload).The Communication subsystem receives commands fromthe ground command station in Ann Arbor and downloadsdata to its globally distributed ground station network. TheAttitude Determination and Control, Thermal Determinationand Control, Structures and Mechanism subsystems are self-explanatory, and are passive for the RAX spacecraft (i.e. arenot active).

6. ANALYTICAL M ODEL AND RESULTS

We use the system model for a variety of analysis applica-tions, which include those listed below and are illustratedinFigure 8.

• Communication Download Analysis

6

Figure 6. RAX Mission represented in a SysML Block Definition Diagram(BDD)

Figure 7. RAX Mission key properties represented in a SysML InternalBlock Diagram (IBD) with Subsystems andInteractions

• Power Analysis

• Mission System Activity Analysis

Communication Download Analysis

Due to the importance and challenges of designing operatinga communication subsystem for a small spacecraft, we pro-vide a detailed view of the communication subsystem in thissection. The SysML model presented in this section is basedon the model in Ref. [11].

The main purpose of the communication subsystem is todownload data from the spacecraft to ground stations. Inthis example, we assume there is a single ground station. Toevaluate the communication subsystem, we are interested inanalyzing the signal-to-noise ratio,SNR, of the communica-tion link between the spacecraft communication subsystemand the ground station.

The SNR must exceed some minimum level,SNRmin, toensure a given error rate is achieved.

The SNRAnalysis block in Figure 9 represents the com-munication link that we are evaluating. The link equationused for the analysis uses design variables that belong to thecommunication subsystem (Communication block), network

of ground stations (Ground Network block), atmosphere(Atmosphere block), and the spacecraft trajectory (OrbitalElements block).

Figure 10 shows the SysML parametric model for theSNRAnalysis block. The parametric model shows the linkequation (calcSNR constraint property) which relates theSNRanalysis variable to the system design variables specificto the communication subsystem, ground stations, atmo-sphere, and spacecraft trajectory. The parametric model alsoshows the space loss equation (calcLS constraint property)that relates the space loss (Ls) to propagation path distance(Lp). These equations are represented in log form accordingto industry practice.

SysML parametrics are acausal in nature. The mathematicalconstraints in the parametric model are represented in adeclarative manner, which implies that there are no fixedinputs and outputs specified at the parametric model level.The same parametric model can be solved with differentcombinations of inputs and outputs such asy = kx and wherewe solve fory givenx andk. Orx = y/k where we solve forx giveny andk. We can solve the equations with differentcombination of dependent and independent variables.

ParaMagic leverages the SysML standard to execute para-metric models in the context of block instances, where each

7

System Model

SysML

Domain-specific modeling language for systems engineering

SysML Models, e.g.

- Block Definition Diagram - Internal Block Diagram

- Activity Diagram - Sequence Diagram

-

State Machine Diagram - Parametric Diagram

Mission System

Activity Analysis

- Behavior and Interactions

Cameo Simulation Tool Kit

- Animation of SysML state machines

and activity models

Power Analysis

- Power gathering

-

Subsystem power usage

PHX ModelCenter

- Animation of SysML parametric diagrams.

- Interface with STK and MATLAB

Orbit Dynamics

- Orbit and attitude.

- Data collection and ground station

access opportunities.

- Solar power collection.

Systems Tool Kit (STK) - Mission modeling,

analysis, and visualization

Communication Download Analysis

- Signal to noise ratio

- Downlink data rage

- Available power

ParaMagic

MATLAB Excel

- Execution of constraint behaviors

in SysML parametric diagram

Figure 8. RAX Models and Simulations as related to various analysis/simulation tools

instance represents a specific design alternative, configura-tion, or scenario. ParaMagic can be used to execute a givenparametric model for different causalities, such that input andoutput variables can be switched on-the-fly.

The intent of this analysis is to use the given parametric modelin three different analysis scenarios:

• Analysis Scenario 1: Given the data download rate (rdl)and the available power (pdl), compute the maximum feasibleSNRfor the communication link.

• Analysis Scenario 2: Given the data download rate (rdl)and the desired SNR, compute the minimum feasible powerrequired (pdl).

• Analysis Scenario 3: Given the available power (pdl) andthe desired SNR, compute the maximum feasible data down-load rate (rdl) that can be achieved.

Figure 11 shows the SysML instance structure (block defini-tion diagram) for an analysis of a specific design configura-tion with specific values of the properties. Figure 12 showsthe ParaMagic browser for Analysis Scenario 1. As shown inthe figure, all of the value properties have assigned valuesexcept forSNRand Ls. SNR is assigned target causalityas the value of interest for Analysis Scenario 1 andLs isleft with undefined causality which means it will be solvedonly if necessary to the solve for the specific target value.Figure 12 shows the solved value of SNR (in the box). In thisexample,SNRmin = 13 dB, which is acceptable and thereforethe power allotted in the design is sufficient for the specifieddata download rate and acceptable error rate. The Update toSysML button at the right of the browser allows the user toupdate the solved values in response to the specific model anddiagram.

Figure 13 shows the ParaMagic browser for Analysis Scenar-ios 2 and 3 (note the corresponding SysML instance structureis not shown). It shows thatSNRhas been assigned given

8

SNR Analysis[Package] Analysisbdd [ ]

System Design ElementsAnalysis

constraints

calcLs : Compute L_scalcSNR : Compute SNR

values

c : m/s = 300000000f : Hz = 437E6k : J/K = 1.3806503E-23SNR : dB

˙block¨

SNR Analysis

values

L_p : kmL_s : dBW

˙block¨

Orbital Elements (TLE)

values

T_s : K

˙block¨

RAX Ground Network

values

p_dl : Wr_dl : bit/s

˙block¨

Communication

values

G_r : dBi

˙block¨

GS1

values

G_t : dBi

˙block¨

Antenna

values

L_a : dB

˙block¨

Atmosphere

values

L_l : dB

˙block¨

UHF Radio

comm

net

orb

atm

antennaradio

gs1

Figure 9. SysML Block Definition Diagram (BDD) illustrating theSNRAnalysis model

causality and value 13, equal toSNRmin. For Analysis Sce-nario 2 (LHS), the power required for downloadpdl is com-puted given the minimum acceptableSNRand data downloadrate. For Analysis Scenario 3 (RHS), the data download rater dl is computed given the minimum acceptableSNRandavailable power.

Power Analysis

To capture realistic power scenarios, we have developed asimulation that consists of simulations and analysis compo-nents from STK, SysML, and MATLAB. PHX ModelCenteracts as the glue that ties them together. We model dynamicorbits, opportunities to collect energy and download data,realistic schedules. We use the model to investigate the timehistory of the spacecraft states, including the on-board energyand data, and the amount of downloaded data.

We created a workflow for an example RAX mission sce-nario, which includes data and energy collection, on-boardoperations, and data download over a specified ground sta-tion. The simulation is executed during a specified scenariotime. The state dynamics are a function of performed opera-tions, including nominal, payload, and download operations,and available energy collection from the sun. We implementthe RAX-specific scenario by combing the MagicDraw para-metric model in Figure 14 with an orbital scenario from STKand custom analysis MATLAB scripts using PHX ModelCen-ter, as shown in Figure 15.

The simulation is a workflow that is created graphically bydragging and dropping reusable components and combining

them using if-else branches, loops, and other flowchart-likeconstructs (using PHX ModelCenter). The graphical linkeditor is used to specify what data is passed between appli-cations when we execute the model. Through a graphicaluser interface, accessible from within the MBSE tool orPHX ModelCenter, we execute the PHX ModelCenter modeldefined by a SysML parametric diagram.

This simulation environment enables us to evaluate designconfigurations, perform trade studies, and check requirementscompliance. Analysis can also be automatically re-run withupdated the parameter values.

We execute the power scenario in Figure 14 using the sim-ulation workflow created in PHX ModelCenter, which auto-matically executes the workflow as many times as necessary,utilizing parallel computing resources as needed. When in-structed, each component is executed automatically, transfer-ring information between components. Using the simulationenvironment described above, we can perform parametricstudies and use the multi-dimensional data visualization toolsin PHX ModelCenter to interpret and analyze the results.

Mission System Activity Analysis

CAMEO Simulation Toolkit (CST) was used to analyze theRAX behavior and interactions. Simulation in this con-text means to execute the model so that the RAX Systeminteractions and behaviors can be studied. A model is asimplified representation of the actual system (in this caseRAX), thus creating a model that allows for useful simulationand analysis is an iterative process.

9

SNR Analysis SNR Analysis[Block] par [ ]

G_t : dBi

antenna : Antenna

L_l : dB

radio : UHF Radio

r_dl : bit/sp_dl : W

comm : Communication

˙constraint¨

calcSNR : Compute SNR

{SNR=10*log(10,p_dl)+G_t+G_r+L_l+L_s+L_a-10*log(10,k)-10*log(10,T_s)-10*log(10,r_dl)}

G_r : dBi

G_t : dBi

k : J/K

L_a : dB

L_l : dB

L_s : dBW

p_dl : W r_dl : bit/s

SNR : dB

T_s : K

˙constraint¨

calcLs : Compute L_s

{L_s=20*log(10,(c/(4*pi*1E3*L_p*f)))}

L_s : dBW L_p : km

f : Hz

c : m/s

G_r : dBi

gs1 : GS1T_s : K

net : RAX Ground Network

L_s : dBWL_p : km

orb : Orbital Elements (TLE)

L_a : dB

atm : Atmosphere

SNR : dBk : J/K

c : m/s

f : Hz

SNR=10*log(10,p_dl)+G_t+G_r+L_l+L_s+L_a-10*log(10,k)-10*log(10,T_s)-10*log(10,r_dl)

is the log form of

SNR=(p_dl*G_t*G_r*L_l*L_s*L_a)/(k*T_s*r_dl)

e7

e5

e6

e10

e1

e9

e2

e13

e4 e3

e14

e12

e8

e11

Figure 10. SysML parametric diagram showing theSNRAnalysis link budget model

CST enables the user to execute and animate state machinesand activity models. The sequence of steps to execute CSTis to run a simulation, view the behavior by the model, andupdate the design appropriately if the behavior needs to bemodified. CST functionality also supports verification andvalidation of the system.

The Mission Operations System (MOS) consists of the hard-ware, software, procedures, and personnel that control theFlight System and supports analysis of the Flight Systembehavior. The MOS operation team generates sets of com-mands that are executed on-board the Flight System. ForRAX the On-Board Computer (OBC) is the main handlerfor processing commands and sending them to the relevantsubsystems for execution. This process was simulated in theRAX Model as described below.

Figure 16 shows the interface between the RAX Flight Sys-tem and the RAX Ground System. The sets of commandsare uploaded to the Flight System and provide the schedule,which includes when and how to perform an experiment anddownload data. For the RAX spacecraft, the experiment timesare a function of when the spacecraft and target of interest

have line-of-sight visibility and when the energetic activity inthe ionosphere is predicted to exceed some minimum value.

The upload command consists of sending a signal from thecontrol ground station, which traverses the Flight-GroundInterface, and is (with successful transmission) receivedbythe OBC. The OBC has timing knowledge (with an on-board clock) and can dispatch the command information tothe appropriate subsystems when a command approachesexecution time.

Figure 17 shows the relevant states related to the Main FlightComputer . In this example, the Command Processing Statehas underlying behavior for dispatching commands.

Figure 18 depicts the behavior that the OBC performs inorder to analyze command files sent from the ground. In thissnippet of the process, the OBC determines what subsystemis being affected and whether or not this subsystem is enteringupload or download mode. Once the determination is made,the OBC sends the final signal data to the CommunicationsSubsystem, shown in Figure 19.

10

Instance of the SNR AnalysisSNR Instance[Package] bdd [ ]

System Design ElementsAnalysis

L_p = "3336.0"L_s = ""

˙block¨

sNR Analysis.orb : Orbital Elements (TLE)

gs1 = sNR Analysis.net.gs1T_s = "325.0"{unit = kelvin}

˙block¨

sNR Analysis.net : RAX Ground Network

G_t = "3.0"

˙block¨

sNR Analysis.comm.antenna : Antenna

atm = sNR Analysis.atmc = "300000000" {unit = metrePerSecond }comm = sNR Analysis.commf = "437E6"{unit = hertz}k = 1.3806503E-23net = sNR Analysis.netorb = sNR Analysis.orbSNR = ""

˙block¨

sNR Analysis : SNR Analysisantenna = sNR Analysis.comm.antennap_dl = "1.0"{unit = watt}radio = sNR Analysis.comm.radior_dl = "9600.0"

˙block¨

sNR Analysis.comm : Communication

L_l = "-1.0"

˙block¨

sNR Analysis.comm.radio : UHF RadioL_a = "0.0"

˙block¨

sNR Analysis.atm : Atmosphere

G_r = "13.0"

˙block¨

sNR Analysis.net.gs1 : GS1

Figure 11. SysML BDD illustrating the instance structure setup for Scenario 1

Figure 12. ParaMagic Browser showing results for Analysis Scenario 1

11

Figure 13. ParaMagic Browser showing results for Analysis Scenarios2 and 3

Figure 14. Parametric Diagram showing RAX Power Scenario in MagicDraw

12

Figure 15. RAX Power Scenario in PHX ModelCenter integrated with STK and MATLAB as projected from the SysMLmodel

In Figure 19, the states for the Communication Subsystemare shown. Nominally the system is in the beaconing mode,but once a signal is received from the Main Flight Computerthat indicates when the Flight System is uploading or down-loading data, the Communication subsystem transitions to therelevant state.

Using CST for this analysis allows for the interfaces to thedifferent systems of the RAX Mission System to be analyzedand the actual information exchange between systems to bedepicted and tested. The expected behavior as well as on-flight observed behavior can be compared to what the modelpredicts. If a model is developed in the early phases of themission, these types of simulations will allow for verificationand validation of the mission software and interfaces through-out the development lifecycle.

7. CONCLUSION

Summary

The RAX model described in this paper demonstrates theutility and advantages of using a standards-based approachfor modeling the system design and analysis using a ”DevelopWith What You Fly With” (DWWYFW) philosophy. TheSysML BDD and IBD diagram structures are the foundationsthat establish the fundamental relationships and interfacesbetween the system components. Going beyond traditionalstatic system representations, we add parametric diagramstoenable interactive analysis of the design based on establishedphysical principles (e.g. communications link margin, powerconstraints). Furthermore, time evolution of our systemallows the analysis of the dynamic nature of the various flightand ground system states. These states are defined in the StateMachine diagrams. Block representation, parameterization,and state definition all serve as the glue that ties the systemtogether, and provides the framework for integrating thedesign model with the analytical models.

The role of the systems engineer is to understand all partsof the system in order to describe how the complete systemfunctions. Unlike traditional requirements-based approachesusing declarative ”shall statements”, the formalized descrip-tive language of SysML is not only human readable, but alsoallows for machines to read and interpret the description. Thiscapability allows for the integration of seemingly disparateanalysis tools (e.g. MATLAB, STK, Excel, Mathematica)into an integrated modeling environment.

We developed the MBSE simulation environment presentedin this paper using a modular approach, which enabled easygrowth of the model and multiple modelers to simultaneouslycontribute to the model. We first identified key frameworkelements, such as the subsystems, states, and their interac-tions. The framework is thus easily extended to includeadditional modeling elements, higher fidelity simulators,ormore interactions between the components.

All modeling elements were introduced in the context ofbuilding or executing an analysis or simulation, which en-sured they were required and minimized the overall complex-ity of the model. We also integrated existing software codeinto the simulator. A variety of modelers with different levelsof expertise (ranging from beginner to expert SysML user)contributed to the model. Beginners found the learning curvereasonable, as they were building off the work of the expertsand thus learning as they contributed. Beginners foundworking with SysML easier if they had experience with theCubeSat mission itself or other tools that were incorporatedinto the framework (e.g. STK, MATLAB).

Lessons Learned: Challenges and Successes

Throughout the development of the models and simulations inthis paper, we have experienced several lessons learned thatare listed below:

• We were able to extract time-dependent parameters inPHX ModelCenter using a specific post-processing script and

13

Figure 16. Composite diagram showing parts and behaviors of RAX Flight System

Main Flight Computer Main Flight Computer[State Machine] stm [ ]

Command Processing

Diagram name Main Flight Computer

Documentation Louise.Anderson@jpl.nasa.gov

Flight Computer Send Datado /

Mission Data Download Mission Data Uplink

Download Data

Prepare for

Uplink

End

Figure 17. Main Flight Computer State Machine

14

Dispatch Commands Dispatch Commands[Activity] act [ ]

Spacecraft Downloading Data

Spacecraft Uploading Data

Flight Software Command Handler

Command

Uplink/Downlink?

SubSystem?

Command.Link()=Uplink Command.Link()=Downlink

Command.SubSystem() = Communications

Figure 18. Activity Diagram for the On-Board Computer (OBC) DispatchCommands Behavior

[State Machine] Communication Communicationstm [ ]

Beacon

High rate Download Upload

Spacecraft Downloading

Data

Spacecraft Nominal

Spacecraft Uploading

Data

Spacecraft Nominal

Figure 19. Communication Subsystem State Machine

vendor support. This was a great advantage for executing thedynamic power system scenario.

• We were able to set up and executeSNR analyses forthe Communication subsystem for different scenarios usingParaMagic. This enabled us to set up the parametric modelonce and execute it for different causalities, e.g. computingSNRgiven available power and data download rate, or alterna-tively compute the required power given acceptableSNRanddata download rate.

We also encountered several challenges, listed below:

• Appropriate licenses are required for all simulation tools,which can be challenging, and required vendor support.

• Setting up the simulation environment requires severalsteps, including creating wrapper files, wrapping models,saving, and re-opening models in PHX ModelCenter and

MagicDraw. Thus, creating and testing the integration ofmodels can be time consuming and inefficient.

• It is currently difficult to de-bug MATLAB code and STKscenarios after they have been wrapped into the PHX Model-Center model, which can be time-consuming and frustrating.

Future Work

Beyond the models, simulations, and analyses demonstratedin this paper, there are several additional ways to extendthis work to more sophisticated analyses that can aid in bothvehicle and mission operation design. Extensions include:

• The execution of parametric models to compute differentperformance parameters, using state machine and activitydiagram simulations.

• Wrapping STK models as parametric constraints and exe-

15

cuting them using ParaMagic. This capability is in a proto-type stage right now.

• The simulations currently allow the model to be steppedthrough in time to aid in visualizing what is occurring withspacecraft behavior. In the future, extending this approachto include constraint-based solving would provide a morecomplete analysis. In particular, the different states canbeconstrained using constraint value properties specified bytheconstraint modeling. With both methods working together,a dynamic approach of changing input values could be usedto evaluate the equations and to visualize the behavior of thespacecraft based on input values.

• The various simulations in this paper currently execute in-dividually. Future work will bring these simulations togethersuch that broader simulations can be performed, for examplethe power and communication systems could be analyzed andoptimized simultaneously.

• The ability to verify optimal scheduling algorithms in thesimulation environment would be extremely useful, as thereis currently no unified environment where this can be doneefficiently. In particular, it would be helpful to be able to as-sess the robustness of operational schedules to perturbationsin various input parameters.

• Beyond demonstrating mission scenarios and performingtrade studies, the modeling and simulation environment inthis paper may also be useful for combined vehicle andoperations optimization. In particular, due to the ease ofidentifying inputs and outputs, it is possible to vary specificparameters (assigned as inputs) and monitor how they impactother parameters (assigned as outputs). This type of analysiscould be extremely useful for designing ground systems,sizing spacecraft components, etc. Furthermore, these typesof trades can be useful for developing the simulation systemthat will be used for later design trades and flight simula-tions, along the lines of “Develop With What You Fly With”(DWWYFW).

• Finally, comparing results from our simulation environ-ment based on our modeling framework to real data fromoperational missions such as RAX will provide a means toverify, validate, and improve the models.

ACKNOWLEDGMENTS

We thank the entire University of Michigan and SRI Inter-national RAX Teams for their contributions. We also thankAnalytical Graphics, Inc (AGI), Phoenix Integration, andInterCAX for their generous support of our work. We thankthe Natural Sciences and Engineering Research Council ofCanada (NSERC) and Zonta International for their support.

We would also like to thank Sandy Friedenthal for his invalu-able review, contributions, and guidance.

Parts of this research were carried out at the Jet PropulsionLaboratory, California Institute of Technology, under a con-tract with the National Aeronautics and Space Administra-tion.

REFERENCES

[1] S. Spangelo, D. Kaslow, C. Delp, B. Cole, L. Anderson,E. Fosse, B. Gilbert, L. Hartman, T. Kahn, and J. Cutler,“Applying model based systems engineering (mbse) to astandard cubesat,” inIEEE Aerospace Conference, BigSky, MT, March 2012.

[2] J. Springmann, B. Kempke, J. Cutler, and H. Bahcivan,“Initial Flight Results of the RAX-2 Satellite,” inPro-ceedings of the 26th Annual Small Satellite Conference,Logan, UT, August 2012.

[3] J. Cutler and H. Bahcivan, “The Radio Aurora ExplorerA Mission Overview” in AIAA Journal of Spacecraft andRockets, Accepted 2012.

[4] T. Moretto, “Cubesat Mission to Investigate IonosphericIrregularities,” in Space Weather: The Journal of Re-search and Applications, November 2008.

[5] International Council on SystemsEngineering (INCOSE), “MBSE initiative,”January 2007. [Online]. Available:https://connect.incose.org/tb/MnT/mbseworkshop/

[6] J. Wertz and W. Larson,Space Mission Analysis andDesign, 3rd ed. Microcosm Press, 1999.

[7] International Council on Systems Engineer-ing (INCOSE), INCOSE Website. [Online]. Available:http://www.incose.org/ProductsPubs/products/sevision2020.aspx

[8] D. Bindschadler, C. Delp, and M. McCullar, “Principlesto Products: Toward Realizing MOS 2.0 ,” inSpaceOpsConference, Stockholm, June 2012.

[9] Object Management Group (OMG), OMG Website.[Online]. Available: http://www.omgsysml.org/

[10] K. Woellert, P. Ehrenfreund, A. J. Ricco, andH. Hertzfeld, “Cubesats: Cost-effective science and tech-nology platforms for emerging and developing nations,”Advances in Space Research, vol. 47, no. 4, pp. 663 –684, 2011.

[11] S. Spangelo and J. Cutler, “Optimization of single-satellite operational schedules towards enhanced commu-nication capacity,” inAIAA Guidance, Navigation, andControl Conference, Minneapolis, MN, August 2012.

BIOGRAPHY [

Louise Andersonis an early career hireSoftware Systems Engineer at JPL. She’scurrently on the Ops Revitalization teamin Multimission Ground System and Ser-vices (MGSS). Louise is also currentlyCo-Lead of the Modeling Early Adoptersgroup at JPL. She graduated in May2010 from the University of Colorado-Boulder with a degree in Aerospace En-gineering. Previously she worked at

the Laboratory for Atmospheric Space Physics in BoulderColorado working as a Command Controller on the MissionOperations Team. She has worked on the mission ops teamfor Kepler, Sorce, AIM, Quikscat, and Icesat. Louise is amember of INCOSE, currently for INCOSE she is workingon the Space Systems Working Group specifically on CubeSatModeling. .

16

Manas Bajaj, PhD is the Co-Founderand Chief Systems Officer at InterCAX(www.InterCAX.com) where he leads thedevelopment of software applications forMBSE. He has successfully led sev-eral government and industry-sponsoredprojects. Dr. Bajaj has been actively in-volved in the development, implementa-tion, and deployment of the OMG SysMLstandard and the ISO STEP AP210 stan-

dard for electronics. He is a Content Developer (au-thor) for the OMG Certified Systems Modeling Professional(OCSMP) certification program, and coaches organizationson SysML and MBSE. Dr. Bajajs research interests arein the realm of SysML and model-based systems engi-neering (MBSE), computer-aided design and engineering(CAD/CAE), advanced modeling and simulation methods,and open standards for product and systems lifecycle man-agement (PLM/SLM). He has authored several publicationsand won best paper awards. Dr. Bajaj earned his PhD(2008) and MS (2003) in Mechanical Engineering from theGeorgia Institute of Technology, and B.Tech. (2001) in OceanEngineering and Naval Architecture from the Indian Instituteof Technology (IIT), Kharagpur, India. He is an INCOSEmember and participates in the OMG and PDES Inc workinggroups.

Bjorn Cole is a systems engineer inthe Mission Systems Concepts sectionof the Jet Propulsion Laboratory. Hisresearch interests are in the fields ofdesign space exploration, visualization,multidisciplinary analysis and optimiza-tion, concept formulation, architecturaldesign methods, technology planning,and more recently, model-based systemsengineering. He is currently working

on pre-Phase A mission formulation. He earned his Ph.D.and M.S. degrees in Aerospace Engineering at the GeorgiaInstitute of Technology and his B.S. in Aeronautics and Astro-nautics at the University of Washington.

Leo Cheng is currently a member ofthe Flight Control Team for the SpitzerSpace Telescope. In addition to hisreal-time operations experience, Leo hasextensive experience in the area of sci-ence planning and operations, includingleading the development of the scienceplan for the Cassini mission’s Huygensprobe descent and landing on the sur-face of Titan. Originally from the island

of Guam, Leo holds a B.S. Degree in Physics from CalPoly Pomona University and a M.S. Degree in physics fromRensselaer Polytechnic Institute.

James Cutlerreceived a B.Sc. degreein Computer and Electrical Engineer-ing from Purdue University, and M.S.and Ph.D. degrees in Electrical Engi-neering from Stanford University. He iscurrently an assistant professor in theAerospace Engineering Department atthe University of Michigan. His researchinterests center on space systems a mul-tidisciplinary approach to enabling fu-

ture space capability with particular emphasis on novel,

nanospacecraft missions. He is developing next generationcommunication capability, design optimization techniques,and space weather measurement missions. His research labis developing and flying multiple nanospacecraft for NSF andNASA.

Christoper Delp is the Systems Ar-chitect for the Ops Revitalization taskin MGSS. He is also a Systems Engi-neer on the Europa Habitability Mis-sion Model Based Systems EngineeringTeam. He is a founder of the ModelingEarly Adopters grass roots Model BasedEngineering working group. Previouslyhe served as Flight Software Test En-gineer for MSL and Software Test En-

gineer for the Tracking, Telemetry, and Command End-to-End Data Services. He also leads the INCOSE SpaceSystems Working Group’s entry in the Model Based Sys-tems Engineering Grand Challenge. Additionally, he hasperformed research on software verification and tools forService-Oriented Architecture in support of the Deep-spaceInformation Services Architecture. Prior to coming to JPL,he worked as a software engineer performing DO-178b LevelFAA flight qualified software development and testing on JointTactical Radio System (JTRS) and the T-55 Full AuthorityDigital Engine Controller (FADEC). Chris earned a Masterof Science in Systems Engineering from the University ofArizona where he studied Model Based Systems Engineering,Simulation and Software Engineering. Previous to graduatestudies, Chris performed his duties as a systems engineer onMissile Systems Verification and Validation.

Elyse Fosseis a Software Systems En-gineer for the Ops Revitalization task inMGSS. She also develops ground systemcost models for deep space and Earthmissions. She is also a member of theMultimission Ground Data System Engi-neering group at the Jet Propulsion Lab-oratory. Her interests include softwareand systems architecture, applicationsof model-based system engineering, and

cost model implementation and analysis. Elyse is also a partof the INCOSE Space Systems Working Group’s entry into theModel Based Systems Engineering Grand Challenge. Elyseearned her M.A. in Applied Mathematics from ClaremontGraduate University and her B.S. in Mathematics from theUniversity of Massachusetts Amherst.

Dave Kaslowis Director, Product DataManagement at Analytical Graphics,Inc. He has thirty-nine years of expe-rience in both the technical and man-agement aspects of developing groundmission capabilities. He is co-author of”Defining and Developing the MissionOperations System”, ”Activity Plan-ning”, ”FireSat” and ”Spacecraft Fail-ures and Anomalies” in Cost-Effective

Space Mission Operations. He is also the author and co-author of papers for the International Council on SystemsEngineering (INCOSE) Annual International Symposiumsand for the IEEE Aerospace Conference.

17

Grant Soremekunhas a backgroundin engineering design optimization andsoftware development. He holds a B.S.in aerospace engineering and an M.S.in engineering mechanics from VirginiaTech. For the past 9 years, Grant hasworked for Phoenix Integration, a soft-ware company specializing in processintegration, multidisciplinary analysis,and design optimization. During this

time, he has fulfilled several roles, including software devel-oper, application engineer, product manager, and is currentlyserving as the manager for Phoenix Integration western USsales..

Sara Spangelocompleted her Master’sin Aerospace Engineering at the Uni-versity of Michigan, where she workedon optimizing trajectories for energy-efficient periodic solar-powered UAVs.She has been involved in the GPS andoperational scheduling of the Radio Au-rora Explorer (RAX) CubeSat Missionfrom 2009-2012. She completed a Ph.D.in Aerospace Engineering at the Uni-

versity of Michigan, focusing on developing models, sim-ulators, and optimization algorithms for scheduling smallspacecraft and diverse heterogeneous ground networks to-wards enhanced communication capacity. She interned atJPL in 2012, where her work focused on integrating diversesimulation environments to enable Model-Based Systems En-gineering of small spacecraft.

Rose Yntemais the Applications Engi-neer at InterCAX (www.InterCAX.com)where she applies MBSE techniquesto complex systems in areas suchas aerospace, energy, defense, andtelecommunications. She is actively in-volved in the development of SysMLparametric modeling and simulationsoftware. Yntema earned her M.S.(2012) in Electrical and Computer En-

gineering from the Georgia Institute of Technology, and Sc.B.(2010) in Electrical Engineering from Brown University.

18