Horizon: A System-of-Systems Simulation Framework

Cory M. O’Connor, Dr. Eric A. Mehiel

May 9th, 2007

What is the Horizon Simulation Framework?

• The Framework is a library of integrated software tools supporting rapid space system modeling and utility analysis

• The Framework provides an extensible and well-defined modeling capability concurrent with a scheduling engine to generate operational schedules of Systems-of-Systems with corresponding state data

• As a compliment to the Multi-Disciplinary Optimization (MDO) approach, the Framework answers the following question: Does the current design meet system level requirements that are based on a Use Case and cannot be verified by direct analysis?

The System Simulation Problem

• There are several existing ways to approach the problem of system level requirements verification via system simulation– MDD/MDO: Varying system design parameters to

reach a satisfactory (or optimal) design point– Process Integration for Design Exploration: Products

like Model Center network the various custom design data sources together with output visualization

– Visualization Simulation: STK, FreeFlyer and SOAP are excellent for visualizing the behavior of systems and determining geometric access to targets

Why is Horizon Useful?• Fills the niche between generalized integration tools and

specialized geometric-access and visualization tools• Can implement subsystem models, CONOPS

requirements and Use Case scenarios while producing valid simulation output data

• Provides direct access to state data to verify Use Case requirements, and conduct Day In The Life (DITL) utility analysis

• Allows system modeling at any level of fidelity to support the design process from Conceptual Design through CDR

• Helps find any design bottleneck or leverage points hidden within the system design

The Horizon Design Philosophy

• Simply put, Horizon was designed to be useful and reusable

• Interfaces are Key!• Three guiding principles

– Modularity– Flexibility– Utility Scheduler/System

Interface

Main Scheduling Algorithm

System Parameters (Input)

Simulation Parameters (Input)

Final Schedule, State Data (Output)

System Model

Subsystem

Subsystem

Subsystem

Horizon Simulation Framework

Interface between Subsystems

The Horizon Design Philosophy: Modularity

• Modularity increases simulation component value and simplifies extension

• Two degrees of Horizon modularity:– Modularity between the

scheduler and the system model

– Modularity between subsystems inside the system model

Scheduler/System Interface

Main Scheduling Algorithm

System Parameters (Input)

Simulation Parameters (Input)

Final Schedule, State Data (Output)

System Model

Subsystem

Subsystem

Subsystem

Horizon Simulation Framework

Interface between Subsystems

A 1C 2 3B

The Horizon Design Philosophy: Flexibility

• Enables comprehensive modeling and simulation capability

• Two main degrees of flexibility:– Flexibility of fidelity

• Capable of simulating systems as simple or complex as user desires

– Flexibility of system• Capable of simulating any

system (satellites, aircraft, ground vehicles, troops, etc..)

• No preset vehicle or subsystem “types”

Scheduler/System Interface

Main Scheduling Algorithm

System Parameters (Input)

Simulation Parameters (Input)

Final Schedule, State Data (Output)

System Model

Subsystem

Subsystem

Subsystem

Horizon Simulation Framework

Interface between Subsystems

Subsystem

Subsystem Subsystem

SubsystemSubsystem Subsystem

Subsystem

Subsystem Subsystem

SubsystemSubsystem

The Horizon Design Philosophy: Utility

Scheduler/System Interface

Main Scheduling Algorithm

System Parameters (Input)

Simulation Parameters (Input)

Final Schedule, State Data (Output)

System Model

Subsystem

Subsystem

Subsystem

Horizon Simulation Framework

Interface between Subsystems

dtF svd() eig() Matrix Quaternion

• Utility Libraries promote rapid system modeling

• Current Utilities Include:– Matrix class– Quaternion class– Coordinate rotations and

transformations– Single Value Decomposition– Eigenvalue/Eigenvector

algorithms– Runge-Kutta45 integrator

The Horizon Software Architecture

Architecture: The Basic Simulation Elements

• Task – The “objective” of each simulation time step. It consists of a target (location), and performance characteristics such as the number of times it is allowed to be done during the simulation, and the type of action required in performing that task.

• State – The state vector storage mechanism of the simulation. The state contains all the information about system state over time and contains a link to its chronological predecessor.

• Event – The basic scheduling element, which consists of a task that is to be performed, the state that data is saved to when performing the task, and information on when the event begins and ends.

• Schedule – Contains an initial state, and the list of subsequent events. The primary output of the framework is a list of final schedules that are possible given the system.

• Constraint – A restriction placed on values within the state, and the list of subsystems that must execute prior to the Boolean evaluation of satisfaction of the constraint. Also the main functional system simulation block, in that in order to check if a task can be completed, the scheduler checks that each constraint is satisfied, indirectly checking the subsystems.

• Subsystem – The basic simulation element of the framework. A subsystem is a simulation element that creates state data and affects either directly or indirectly the ability to perform tasks. This simple definition is necessary when considering the framework elements that a subsystem is supposed to interface with, and the requirements for accurate simulation.

• Dependency – The limited interface allowed between subsystems. In order to keep modularity, subsystems are only allowed to interact with each other through given interfaces. The dependencies specify what data is passed through, and how it is organized. Dependencies collect similar data types from the passing subsystems, convert them to a data type the receiving subsystem is interested in, and then provide access to that data.

• System – A collection of subsystems, constraints, and dependencies that define the thing or things to be simulated, and the environment in which they operate.

Architecture: The Constraint-Checking Cascade

• Primary algorithm when checking whether a system can perform a task

• Internal constraint process (1):– Subsystems which contribute state data

to Qualifier are evaluated– Qualifier evaluates validity of state– Constraint fails if a subsystem or the

qualifier fails • Constraint-Checking Cascade (2):

– Constraints are checked in user-specified order contributing subsystem data to the state while they execute

– The remaining subsystems not needed to evaluate a constraint are then checked

– If any of the checks fail, no event is added to the schedule and the state is discarded

– If all of the checks succeed, the task and state are used in the creation of a new event, which is added to the end of the schedule

• “Fail-fast” constraint methodology

Constraint

Subsystem 1

Subsystem 2

Subsystem N

Qualifier

Constraint Passes

State

Data

Constraint Fails

Fail

Pass

Pass

Pass

Pass

New Task

Fail

Fail

Fail

Constraint 1

State

Data

Constraint 2

Constraint N

Remaining Subsystems

Possible Schedul

e

New Task

EVENT

Pass

Fail

EVENT

Fail

Fail

Fail

Pass

Pass

Pass

(1)

(2)

Architecture: Subsystems and Dependencies

• Dependencies are the interpreters between subsystems• Example: Power subsystem dependent on ADCS subsystem for power input

of solar panels due to solar panel incidence angle to sun vector– Power subsystem has no business knowing what a quaternion is or what

orientation the spacecraft is in– Power only interested in how much power generated– ADCS has no business knowing how much power the solar panels generate due to

slewing maneuvers– ADCS only interested in orientation– The dependency function would translate the orientation of the spacecraft into how

much power the solar panels generate

• Dependencies structured as they are to avoid “subsystem creep”– Information about and functions from each subsystem slowly migrate into the other

subsystems– Evolutionary dead-end in simulation frameworks– Against the tenets of object-oriented programming

Architecture: The System State

• State is unique to each event• All the data generated over the

course of the event is stored in its corresponding state

• Storage like a bulletin board– Only changes from previously

recorded values are posted– Most recent saved value of the

variable is also the current value

• Many objects have access to the state, including subsystems, constraints, dependencies, data output classes and schedule evaluation functions

0.5s0.85s

1.5s

Event Start Event End

Wa

tts

300270

500

Time

Power Subsystem

5001.5

2700.85

3000.5

00

WattsTime

Other Subsystems

State

Architecture: The Main Algorithm• Contains the interface between the main scheduling module and the main

system simulation module• Guides the exhaustive search in discrete time steps and keeps track of the

results• Essentially a call to the main system simulation routine inside a series of

nested code loops, with checks to ensure that schedules that are created meet certain criteria from simulation parameters

– Outermost loop is a forward-time progression stepping through each simulation time step

• Avoids recursion, where subsystems “reconsider” their previous actions– Then, it checks to see if it needs to crop the master list of schedules (more on that

next slide)– The inner-most loop attempts to add new tasks onto each current schedule

• Checks that schedule is finished with previous event at current time step• Checks whether the task can be performed again• Checks whether the system can perform this combination of schedule and new task

– The “system simulation” step– Adds state data to state

• If successful, create new event with the new task and state, and add it to the end of a new schedule copied from the current one

Architecture: Schedule Evaluation and Cropping

• Scheduler attempts to create new schedules by adding each task (in the form of an event) to the end of each schedule in the master list from the previous simulation time step

• Number of possible schedules grows too quickly during a simulation to keep every possible schedule

• When number of schedules exceeds a simulation parameter (maxSched), the scheduler rates them based on a user-defined “value function” and then keeps only a user defined number (schedCropTo) of schedules

• Changes the basic scheduler from exhaustive search to a “semi-greedy” algorithm

Aeolus: A Horizon Framework Test Case

Aeolus Mission Concept• Aeolus: The Greek

god of wind• Extreme-weather

imaging satellite• Circular, 1000km,

35 degree inclined orbit

• Simulation date: August 1st 2008 for 3 revolutions

• Targets clustered into high-risk areas, including Southeast Asia and the Gulf of Mexico

• Sensor has ability to generate data while in eclipse

180 W 150

W 120

W 90

W 60

W 30

W 0

30

E 60

E 90

E 120

E 150

E 180

E

75 S

60 S

45 S

30 S

15 S

0

15 N

30 N

45 N

60 N

75 N

Asset Start Pos. Asset End Pos. Ground Station Imaging Target

Aeolus System Model• Subsystems

– Access – Generates access windows for different types of tasks. The access subsystem created in the framework for this test is not a physically identifiable spacecraft subsystem. However, as previously defined, a subsystem in the Horizon framework is anything that generates state data.

– Attitude Dynamics and Control System – Orients spacecraft for imaging– Electro-Optical Sensor – Captures and compresses images when it has access

to an imaging target and sends data to the Solid-State Data Recorder– Solid-State Data Recorder – Keeps imagery data before being sent down to a

ground station– Communications System – Transmits imagery data when it has access to a

ground station– Power – Collects power usage information from the other subsystems, calculates

solar panel power generation and depth of discharge of the batteries• Constraints

– During imaging, no information can be sent to ground stations – The data recorder cannot store more than 70% of its capacity– The depth of discharge of the batteries cannot be more than 25%

Aeolus Simulation Results: Power/Data

0 5000 10000 150000

0.5

1

Simulation Time (s)

Bat

tery

DO

D (

%)

Event Start

0 5000 10000 150000

50

100

150

Gen

erat

ed S

olar

Pan

el P

ower

(W

)

Simulation Time (s)

0 5000 10000 150000

0.5

1

Buf

fer

Usa

ge (

%)

Simulation Time (s)

0 5000 10000 150000

1

2

3

4

Dow

nlin

k D

ata

Rat

e (M

b/s)

Simulation Time (s)

Horizon Conclusions

Framework Performance

• Modeling mantra is still true: “The better the model the better the output”

• Aeolus test case, 3 revolutions, 300 targets, 10 minimum schedules, 500 maximum schedules: ~900 seconds

• Parametric testing conducted to determine effects of simulation parameters on simulation run time– Order equation:

• Modular and flexible modeling capability provides significant benefits when changing subsystem models

systnDSO 2max

Future Plans• A robust user interface in C# for entering simulation

parameters, initial conditions and output types• Automatic code-template generation for subsystems,

constraints, and dependencies based on system diagram built in GUI

• Optimization of scheduling algorithms possible when the system is constrained

• Output visualization through either custom-built graphics tools or automatic scenario generator for standard industry visualization tools (STK, Matlab)

• Parallelization of the main algorithm• Creation of a large asset/subsystem module library