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 satellites are more highly resource-constrainedby mass, power, volume, delivery timelines, and cost relativeto their larger counterparts. Small satellites are operationallychallenging because subsystem functions are coupled and con-strained by the limited available commodities (e.g. data, energy,and time). Furthermore, additional operational complexitiesarise because small satellite components are physically inte-grated, which may yield thermal or radio frequency interfer-ence.

In this paper, we extend our initial Model Based Systems Engi-neering (MBSE) framework developed for a small satellite mis-sion by demonstrating the ability to model different behaviorsand scenarios.

We integrate several simulation tools to execute SysML-basedbehavior models, including subsystem functions and internalstates of the spacecraft. We demonstrate utility of this ap-proach to drive the system design process. We demonstratethe applicability of the simulation environment to representrealistic satellite operational scenarios, which includethe energygathering and the data acquisition and downloading to groundstations.

The integrated modeling environment enables users to extractfeasibility, performance, and robustness metrics and enablesvisualization of both the physical (e.g. position, attitude) andfunctional states (e.g. operating points of various subsystems) ofthe satellite for representative mission scenarios.

The modeling approach presented in this paper offers satellitedesigners 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 06/01/2013.

TABLE OF CONTENTS

1. INTRODUCTION

MBSE Applied to CubeSats

This paper extends the work reported in our 2012 IEEEAerospace conference paper [?]. The paper reported onusing Model Based Systems Engineering (MBSE) and theSystems Modeling Language (SysML) to model a standardCubeSat, and applied that model to an actual CubeSat, theRadio Aurora Explorer (RAX) mission [?].

A CubeSat is a type of miniaturized satellite with a standardform factor based on cubes with dimensions 103 centimetersand weighing less than one kilogram. CubeSats typicallyconsist of one to three cubes.

RAX is the first CubeSat funded by the National ScienceFoundation (NSF) [?]. It has is a space weather missiondesigned to study plasma field-aligned irregularities in theionosphere. It has enabled undergraduate students, graduateresearchers, engineers, and scientists to be involved in thedesign, building, and operations of a satellite.

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 [?]. The MBSE Roadmap,Figure ??, 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:

1

• 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 included aerospace students and professors from Mas-sachusetts Institute of Technology and Georgia Institute ofTechnology. The initial focus was on the modeling of ahypothetical FireSat space system [?]. FireSat is a satellitefor detecting, identifying, and monitoring forest fires. Thissystem is used as an example in the widely used and acceptedSpace Mission Analysis and Design (SMAD) textbook [?].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 satellite 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.

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

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 the spacesystems domain.

We are developing a SysML model that incorporates severalCOTS tools:

• MagicDraw

• Cameo Simulation Tool Kit

• ParaMagic

• Systems Tool Kit

• PHX Model Center

• MATLAB

We are executing the model 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 phaseand continuing throughout development and later life cyclephases [?].

The MBSE goal is to eventually replace the document-centricsystem engineering approach starting in the acquisition phaseof a project and continuing on into operations.

Our application of MBSE uses SysML as the modelinglanguage. SysML is a graphical modeling language formodeling systems. It is used to specify, analyze, design,optimize, and verify systems and their hardware and softwarecomponents. SysML was developed by INCOSE and theObject Management Group(OMG)[?].

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

• Structural block diagrams illustrating the constituent ele-ments of a system and their connections

• Behavioral activity and state diagrams describing opera-tional behaviors

• Parametrics definitions for operational constraints speci-fied 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 model all aspects of a system either directlyor through an interface with other models. It enables sys-tems engineers to create and evolve models in an integrated,collaborative, and scalable environment. It enables buildingmodels that can be used in early design stages and that cansupport specification and design updates. Using models todefine, develop, and ultimately operate a system is known asDevelop With What You Fly With (DWWYFW).

Figure?? 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 type of low-cost, standardized nanosatellite(where a 1U is a cube 10 cm3 on a side and approximately1 kg) [?]. These small satellites are typically launched assecondary payloads. They have enabled the university com-munity to design, build, and launch satellites using primarilyoff-the-shelf components. More recently, the worldwidecommunity has adopted the CubeSat standard as a means

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

Ma

turi

ty 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

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

3

Simulation and

Analysis Modeling

Tools

Automated View

and Report

Generation Tools

Hardware and

Software Design

Tools

Model

Repository

Figure 3. MBSE Environment

of performing novel scientific, surveillance, and technologydemonstration missions at significantly reduced cost and withshort development timelines.

Current Approach to CubeSat Design

The current approach to design and operational planningfor CubeSat missions is largely intuition-based, often re-lies on simplified trade-studies that usually do not explorethe complete design space [?]. Furthermore, ad-hoc andoften unverified approaches are used to combine multiplesimulation environments that often neglect elements of themission dynamics. Designing he satellite at an early stageand neglecting key operational parameters can be problematicbecause decisions made in early design stages can have asignificant impact on mission operations. For example, if abattery is sized prior to performing operational simulations,it may be of insufficient capacity to sustain the satellitethroughout eclipse and be unable to satisfy mission opera-tions requirements.

MBSE Approach to CubeSat Design

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

The current modeling effort is well under way, and has de-veloped many of the early work products as indicated below.Our overall plan is to develop work-products for the CubeSatcommunity that will include:

• 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 themission objective

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

– Flight system

– Ground system

• An example CubeSat model that existing and future teamscan use as a template for describing and modeling their own

satellites, optimizing satellite design, and evaluating missionoperations.

• The model will include:

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

– Key satellite structure, including systems, subsystems,and components and their interfaces

– Key satellite system and subsystem behaviors

– Key satellite constraints and measures of effectiveness

The model will provide the techniques to interface CubeSatSysML models with a diversity of COTS modeling, anal-ysis, and visualization tools. These tools can extract theportion of the information necessary to solve a problem oranalyze a relevant part of the system and then integrate thesolution back into the mission specification. For example,an optimization algorithm which takes as inputs satelliteposition and opportunities to collect energy and data, andthen generates operational schedule can be interfaced withthe SysML model.

The model will provide the capability to ensure that designupdates comply with mission requirements and to communi-cate design updates to all engineers working on the mission.

Ultimately the models will be used by mission operators toevaluate mission planning, scheduling, and operations strate-gies considering position, attitude, on-board energy, data, andthermal states. This is will of paramount importance whenresponding to satellite component degradation and anomalies.

4. INTEGRATED TOOL ENVIRONMENT

Next we describe the simulation and analysis tools of theMBSE Environment shown in Figure?? that enables us toanalyze and optimize system performance. The simulationenvironment brings to life the models described in the pre-vious section, where various aspects of the system model(parametrics, activities, and state machines) can be executed.

Conventional approaches often consist of simulators that arepatched together in an ad-hoc manner, or require manual

4

and time-consuming tasks when passing information betweensimulators. Unlike these approaches, our simulation environ-ment enables the flow of information between simulators inan automated way, enabling users to easily evaluate differentdesign configurations or reconfigure the analysis for differentmission scenarios.

We use the following simulation tools to bring the SysMLmodel to life:

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

• Cameo Simulation ToolkitR©from No Magic enables differ-ent MBSE behavioral models such as SysML State Machinesand Activity Diagrams to be executed within MagicDraw.

• STK R©from Analytical Graphics is a tool that supportshigh fidelity simulation and visualization of satellite behaviorincluding orbital dynamics and satellite subsystems modelsfor power, thermal, sensors, attitude control, and telemetry.

• MATLAB R©provides powerful numerical computing forevaluating equations, evaluating functions, executing algo-rithms, and plotting results. MATLAB can also interface withother optimization toolboxes and solvers.

• ParaMagicR©is a SysML parametric solver and integratorfor MagicDraw. It provides the ability to execute SysMLparametric models and perform system trade studies from theearliest stages of system development. ParaMagic can exe-cute constraint relationships that are math equations or wrapexternally-defined models such as MATLAB/SimulinkR©,MathematicaR©, and Excel. ParaMagic leverages the acausalnature of SysML parametric relationships to execute modelsin different causalities (swap inputs and outputs on-the-fly).It can detect and solve complex SysML block and parametricmodel structures, such as complex aggregates, recursion, andproperty and constraint redefinitions in the model hierarchy.Equivalent tools MelodyR©, SolveaR©, and ParaSolverR©areavailable for RhapsodyR©, Enterprise ArchitectR©, and ArtisanStudioR©respectively.

• PHX ModelCenterR©allows users to create and executesimulation workflows by integrating various types of simu-lation models like Excel spreadsheets, STK scenarios, andMATLAB scripts. Once a simulation workflow is created,PHX ModelCenter executes the workflow, automaticallytransferring data from one model to the next. Users areable to execute multi-run studies by employing a rich setof trade study algorithms, including design of experiments,optimization, and reliability analysis. PHX ModelCentercan also be used to execute parametric models developed inMBSE tools like MagicDraw and Rhapsody, making it easierto evaluate performance and verify requirements throughoutthe design process.

The reason for using great set of diverse tools in the simula-tion environment is three-fold. First, we wanted to demon-strate how diverse tools could be integrated into a commonframework. Second, we wanted to use the most appropriatesimulators or mathematical engines environments for eachparticular simulation, and when possible, integrate existingcode. Third, we wanted to test and determine which toolsworked well for different applications (and could interfacewith other tools), thus we utilize and test a significant setof tools. However; a different, or smaller set of simulation

or calculation tools could be utilized to accomplish similargoals.

5. RAX CUBESAT

Mission Description

RAX is a space weather mission designed to study plasmafield-aligned irregularities in the ionosphere [?]. It performsexperiments using a bi-static radar configuration which uti-lizes a high-powered ground-based radar station. The primarystation is PFISR, located in Poker Flat, Alaska, as shown inFigure ??. The ground-based radar sends a high poweredsignal that reflects off the irregularities and are measuredbyRAX. On-board timing is provided by a GPS and positionknowledge is provided by ground-based tracking systems.

RAX is passively magnetically aligned with the Earth’s mag-netic field using on-board fixed magnets, as shown in Figure??. This type of attitude control system enables RAX to haveits antennas pointed towards the Earth when it passes over theexperimental zone near the North Pole. Furthermore, the GPSantenna was installed on the opposite satellite face such thatthe antenna faces the GPS constellation during experiments,when accurate timing is critical. Oscillations are dampenedwith hysteresis material.

RAX-1 was launched in October of 2010 and RAX-2 waslaunched in November of 2011. RAX-2 is still performingexperiments and being operated on a daily basis from theUniversity of Michigan ground stations in Ann Arbor andground station partners located around the world.

RAX SysML Model

The RAX satellite SysML models are based on the opera-tional satellite framework developed in Ref. [?].

The SysML representations of the RAX model in this sectionprovide a visual representation of how the system behaviorcan be evaluated using the simulations and then generatesperformance metrics based on the evaluations.

Figure?? shows the RAX Block Definition Diagram (BDD)consisting of the RAX Launch System, RAX Environment,and RAX Mission. The majority of this paper focuseson the RAX Mission. However RAX Launch System andRAX Environment are also important in capturing the overallsystem. The RAX Mission model consists of both logical andphysical models.

The logical models consider the operations of the systemwhile the physical models consider the physical components.The decomposition strategy is typically used by CubeSatdesigners to separate functionality into subsystems that cor-respond to logical concepts.

For the CubeSat model, logical subsystem models describethe different concepts required to define the desired behaviorof the system. The physical models specify the hardware andsoftware that realize the logical design.

For example, one of the Power subsystem functions is tostore energy. The physical battery hardware implements thatfunctionality. Developing both logical and physical modelsallows the CubeSat systems engineer to clearly define the dif-ference between the functionality (using logical models) andthe hardware that supports this functionality (using physical

5

Figure 4. Radio Aurora Explorer (RAX) Satellite Mission

Figure 5. Schematic of RAX spacecraft with vectors pointing towardsthe experimental zone, Poker Flat, AK, the sun, andalong the Earth’s magnetic field (which the spacecraft long axis is aligned with). The figure is generated using STK.

Figure 6. RAX Mission Block Definition Diagram (BDD)

6

Figure 7. RAX Mission Internal Block Diagram (IBD) with Subsystems and Interactions

models).

The focus of this paper is on the operations of the RAXsystem, thus we focus on the logical models. As describedin Ref. [?], RAX has several functional subsystems, eachsupporting at least one critical part of the mission or othersubsystems. These subsystems are detailed in Ref. [?]. TheInternal Block Diagram (IBD) shown in Figure?? illustrateshow the subsystems for the RAX Logical Flight Systeminterconnect along with some of the key properties for eachof the subsystems that are used in the analysis.

The Power Collection and Control subsystem is responsiblefor acquiring energy from body-fixed solar panels, distribut-ing power to support ongoing operations, and storing excessenergy for future use in an on-board battery. The On-board Data Handling and Command Dispatcher subsystemis responsible for dispatching commands, and managing thestorage of on-board data.

The Mission Data Handling subsystem is responsible forprocessing, compressing, deleting, and filtering data for thesatellite payload. The Communication subsystem receivescommands from and downloads data to the Earth groundstations.

The Attitude Determination and Control, Thermal Determi-nation and Control, Structures and Mechanism subsystemsare self-explanatory, and are passive for the RAX satellite(i.e.are not active).

6. ANALYTICAL M ODEL AND RESULTS

Figure?? illustrates the application of the RAX system modelto analyze:

• Communication subsystem signal to noise ratio

• Power

• Flight System Behavior

Communication Subsystem Signal to Noise Ratio (SNR) Anal-ysis

Due to the importance and challenges of communication inthe design and operation of small satellites, we provide adetailed view of the communication subsystem in this section.The SysML model presented in this section is based on themodel in Ref. [?].

The main purpose of the communication subsystem is todownload data from the satellite to ground stations. In thiscase there is assumed to be only one ground station. Wewant to analyze the signal-to-noise ratio,SNR , of thecommunication link established between the communicationsubsystem and the ground station, which must be greaterthan a minimum level,SNRmin , based on the error rateacceptable in transmission.

The SNR Analysis block in Figure?? represents theSNR analysis that we want to perform. The link equationused for the analysis uses design variables specific to the com-munication subsystem (Communication block), network ofground stations (Ground Network block), atmosphere (Atmo-sphere block), and the satellite trajectory (Orbital Elementsblock).

Figure??shows the parametric model for theSNR Analysisblock. The parametric model shows the link equation (calc-SNR constraint property) which relates theSNR analysisvariable to the system design variables owned by the commu-nication subsystem, ground stations, atmosphere, and satellitetrajectory. The parametric model also shows the space lossequation (calcLS constraint property) that relates the spaceloss (L s) to propagation path distance (Lp). These equationsare represented in log form according to industry practice.

SysML parametrics are acausal in nature. The mathematicalconstraints in the parametric model are represented in adeclarative manner. This implies that there are no fixed inputsand outputs specified at the parametric model level. The sameparametric model can be solved with different combinationsof inputs and outputs such as y=kx and where we solve fory given x and k. Or x=y/k where we solve for x given y andk. We can solve the equations with different combination ofdependent and independent variables.

7

RAX 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

RAX Mission System

Activity Analysis

- Behavior and Interactions

Cameo Simulation Tool Kit

- Animation of SysML state machines

and activity models

RAX Power Analysis

- Power gathering

- Subsystem power usage

PHX ModelCenter

- Animation of SysML

parametric diagrams.

- Interface with STK and MATLAB

RAX Orbit Dynamics

- Orbit and attitude. - Data collection and ground station

access opportunities.

- Solar power collection.

Systems Tool Kit (STK) - Mission modeling,

analysis, and visualization

RAX Comm Downlink Analysis

- Signal to noise ratio

- Downlink data rage

- Available power

ParaMagic

- Execution of SysML parametric models

- Integration of models in Mathematica, MATLAB/Simulink and Excel in context

parametric models

MATLAB

Excel

Figure 8. RAX Models and Simulations as related to various simulation environment

So the intent is to use the given parametric model in threedifferent analysis scenarios:

• Analysis Scenario 1: Given the data download rate (rdl)and the available power (pdl), compute theSNR for thecommunication link.

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

• Analysis Scenario 3: Given the available power (pdl) andthe desired SNR, compute the data download rate (rdl) thatcan be achieved.

ParaMagic leverages the SysML standard to execute paramet-ric models in the context of block instances, where each in-stance represents a specific design alternative or configurationor scenario in this case. With ParaMagic, we can execute agiven parametric model for different causalities - input andoutput variables can be switched on-the-fly.

Figure?? shows the SysML instance structure (block defini-tion diagram)for an analysis of a specific design configurationwith specific values of the properties of the design. Figure??shows the ParaMagic browser for Analysis Scenario 1. Asshown in the figure, all of the value properties have assignedvalues except forSNR and L s. SNR is assigned targetcausality as the value of interest for Analysis Scenario 1 andL s is left with undefined causality which means it will besolved only if needed to find the target value. Figure??showsthe solved value of SNR, boxed in red. AsSNRmin = 13 dB,this value is acceptable and therefore the power allotted inthe design is sufficient for the specified data download rateand acceptable error rate. The Update to SysML button atthe right of the browser allows the user to update the solvedvalues to the instance model and diagram.

Figure ?? shows the ParaMagic browser for Analysis Sce-narios 2 and 3 (SysML instance structure not shown). Itshows thatSNR has been assigned given causality and value13, equal toSNRmin . For Analysis Scenario 2 (LHS),

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 BDD illustrating theSNR Analysis model setup

the power required for download pdl is computed given theminimum acceptableSNR and data download rate. ForAnalysis Scenario 3 (RHS), the data download rate rdl iscomputed given the minimum acceptableSNR and availablepower.

Simulation Model and Results

Power Analysis—To capture realistic power scenarios, wehave developed a simulation that consists of PHX Model-Center as the glue that ties together simulations and analysiscomponents from STK, SysML, and MATLAB. We modelthe dynamics of opportunities to collect energy and downloaddata and how this impacts the time history of the satellitestates, including the on-board energy and data, and theamount of downloaded data.

We create a workflow for an example mission scenario, whichincludes data and energy collection, on-board operations,anddata download over a specified ground station. The simula-tion is executed during a specified scenario time. These statedynamics are a function of performed operations, includingnominal, payload, and download operations, and availableenergy collection from the sun. We implement the RAX-specific scenario by combing the MagicDraw parametricmodel in Figure?? with an orbital scenario from STKR©andcustom analysis MATLAB scripts using PHX ModelCenter,as shown in Figure??.

The simulation is a workflow that is created graphically bydragging and dropping reusable components and combiningthem using if-else branches, loops, and other flowchart-like

constructs (using PHX ModelCenter). The graphical linkeditor is used to specify what data should be passed fromone application to the next when the model runs. Througha graphical user interface accessible from within the MBSEtool or PHX ModelCenter, we then execute a PHX Model-Center model defined by a SysML parametric diagram.

With this simulation environment, we can evaluate designconfigurations, perform trade studies, and check requirementscompliance. Analysis can also be automatically re-run withupdated the attribute values.

We execute the power scenario in Figure?? using the sim-ulation workflow created in PHX ModelCenter, which auto-matically executes the workflow one or more times, utilizingparallel computing resources as needed. When instructed,each component is executed automatically, transferring in-formation between components. Using the simulation envi-ronment described above, we can perform a parametric studyusing the multi-dimensional data visualization tools in PHXModelCenterR©to help interpret and analyze the results.

Flight System Behavior Analysis—Cameo Simulation Toolkitwas used to analyze the RAX behavior and interactions.Simulation in this context means to execute the model sothat an understanding of the RAX System interactions andbehaviors can be understood. Since a model is a simplifiedrepresentation of the actual System, in this case RAX, creat-ing a model that allows for simulation to be useful for analysiswas an iterative process.

CAMEO Simulation Toolkit provides the ability to execute,

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 the communication link analysis model

animate, and debut state machines and activity models. Thesequence of steps is to run a simulation, view the behavior bythe model, and update the design appropriately if a differentbehavior is needed. This type of functionality also supportsverification and validation of the system.

The Mission Operations System (MOS) consists of the hard-ware, software, procedures, and personnel that enable controlof the Flight System as well as analysis of the Flight Systembehavior. The MOS operation team generates sets of com-mands that are to be executed on-board the Flight System. ForRAX the on-board computer (OBC) is the main handler forprocessing commands and sending them out to the relevantsubsystems for execution. This process was simulated in theRAX Model as described below.

Figure?? shows the interface between the RAX Flight Sys-tem and the RAX Ground System. The sets of commands areuploaded to the Flight System and provide the schedule onwhen and how to perform an experiment. For the RAX space-craft, the experiment times are based on when the spacecraftis over the target of interest and there is the predicted level ofenergetic activity.

The upload consists of sending a command signal from theground station that traverses the Flight-Ground Interfaceas isthen received by the OBC. The OBC has knowledge of thetime and can dispatch the command information to the ap-propriate subsystems when a command approaches executiontime.

Figure ?? shows the states for the Main Flight Computer.Also shown are states that have underlying behavior that ispertinent to that state. In this case the Command ProcessingState has underlying behavior for dispatching commands.

Figure ?? depicts the behavior that the OBC performs inorder to analyze command files sent from the ground. Inthis snippet of the process shown, the OBC determines whatsubsystem is being affected and whether or not this system isgoing to upload or download mode. Once the determinationis made, the OBC sends the final signal data to the Commu-nications Subsystem, shown in Figure??.

In Figure??, the states for the Communications Subsystemare shown. Nominally the system is in the beaconing mode,but once a signal is received from the Main Flight Computer

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

that indicates whether the Flight System is uploading ordownloading data, the communications system transitions tothe relevant state.

Using CAMEO Simulation Toolkit allows for the interfacesto the different systems of the RAX Mission System to beanalyzed and the actual information exchange between sys-tems to be depicted and tested. The expected behavior as wellas on-flight observed behavior can be compared against whatthe model is saying will occur. If a model is developed in theearly phases of the Mission, these types of simulations willallow for verification and validation of the mission softwareand interfaces.

7. CONCLUSION

Summary

The RAX model described in this paper demonstrates theutility in using a standards-based approach for modeling thesystem design and analysis using a ”develop as you fly”philosophy. The BDD and IBD diagram structures of SysMLare the starting point, establishing the fundamental relation-ships and interfaces between the components of our system.Going beyond traditional static system representations, weadd parametric diagrams to enable interactive analysis of thedesign based on established physical principles (e.g. com-munications link margin, power constraints). Furthermore,time evolution of our system introduces the various statesthe flight and ground system undergoes. These states aredefined in the State Machine diagrams. Block representation,parameterization, and state definition all serve as the gluethat ties the system together, and provides the framework forintegrating the design model with the analytical models.

The role of the systems engineer is to understand all parts ofthe system in order to describe how the whole system works.Unlike traditional requirements approach using declarative”shall statements”, the formalized descriptive language ofSysML is not only human readable, but also allows for

machines to read and interpret the description. This capabilityallows for the integration of seemingly disparate analysistools (e.g. Excel, Mathematica) into an integrated modelingenvironment.

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. All modeling elements were introduced in the contextof building or executing an analysis or simulation, whichensured they were required and minimize the complexity ofthe model. The framework is thus easily extended to includeadditional modeling elements, higher fidelity simulators,ormore interactions between the components. We also inte-grated existing software code into the simulator. A varietyof modelers with different levels of expertise (ranging frombeginner to expert SysML user) contributed to the model.Beginners found the learning curve reasonable, as they werebuilding off the work of the experts and thus learning asthey contributed. Beginners found working with SysML asthe beginning easier if they had experience with the CubeSatsystem itself or other simulator.

Lessons Learned: Challenges and Successes

Throughout developing the models and simulations in thispaper, we have experienced several lessons learned that arelisted below:

• We were able to extract time-dependent parameters inPHX ModelCenter using a specific post-processing script andvendor support. This was a great advantage for executing thedynamic power system scenario.

• We were able to setup and executeSNR analyses forthe communication sub-system for different scenarios usingParaMagic. It enabled us to setup the parametric modelonce and execute it for different causalities, e.g. computingSNR given available power and data download rate, and

13

Figure 16. Internal Block Diagram - RAX Flight System - RAX Ground System

14

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. State Machine - Main Flight Computer

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 OBC Dispatch Commands Behavior

computing required power given acceptableSNR and datadownload rate.

We also encountered several challenges, listed below:

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

Future Work

Beyond the models, simulations, and analyses demonstratedin this paper, there are additional ways to extend this work tomore sophisticated analyses that can aid in both vehicle andmission operation design. Extensions include:

• Using ParaMagic to execute parametric models, such ascompute different performance parameters, during state ma-chine simulations in a given state and during transitions.

• Wrapping STK models and AGI components as parametricconstraints and execute using ParaMagic. This capability isin a prototype 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 approach toinclude constraint-based solving would give the full analysispicture. With simulation the different states can be con-strained from occurring based on value properties receivedfrom the constraint modeling. With both methods working

15

[State Machine] Communication Communicationstm [ ]

Beacon

High rate Download Upload

Spacecraft Downloading

Data

Spacecraft Nominal

Spacecraft Uploading

Data

Spacecraft Nominal

Figure 19. State Machine - Communication Subsystem

together, a dynamic approach of changing input values couldbe used to evaluate the equations and to visualize the behaviorof the spacecraft 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 done ef-ficiently. In particular, it would be helpful to be able to assessthe robustness of operational schedules to perturbations invarious input parameters, which can likely be achieved withthe Monte Carlo analysis in PHX ModelCenter.

• Beyond demonstrating mission scenarios and performingtrade studies, this environment may also be useful for com-bined vehicle and operations optimization. In particular,dueto the ease of identifying inputs and outputs, it is possibleto vary specific parameters (assigned as inputs) and monitorhow they impact other parameters (assigned as outputs). Thistype of analysis can be extremely useful for designing groundsystems, sizing satellite components, etc. Furthermore, thesetypes of trades can be useful for developing the simulationsystem that will be used for later design trades and flightsimulations, along the lines of develop with what you fly with.

• 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 in-valuable review, contributions, and guidance of this work andpaper.

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. Cutle, 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] T. Moretto, “Cubesat Mission to Investigate IonosphericIrregularities,” in Space Weather: The Journal of Re-search and Applications, November 2008.

[4] I. C. on Systems Engineering (INCOSE), “Mbseinitiative,” January 2007. [Online]. Available:https://connect.incose.org/tb/MnT/mbseworkshop/

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

[6] I. C. on Systems Engineering (INCOSE),INCOSE Website. [Online]. Available:http://www.incose.org/ProductsPubs/products/sevision2020.aspx

[7] O. M. G. (OMG), OMG Website. [Online]. Available:http://www.omgsysml.org/

[8] 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.

[9] 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.

16

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. .

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,nanosatellite missions. He is developing next generationcommunication capability, design optimization techniques,and space weather measurement missions. His research labis developing and flying multiple nanosatellites 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.

17

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.

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 is currently pursu-ing a Ph.D. in Aerospace Engineering at

the University of Michigan The focus of her ongoing doctoralwork is on developing models, simulators, and determin-istic and stochastic optimization algorithms for schedulingsmall satellites and diverse heterogeneous ground networkstowards 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