Horizon: CDR

The Horizon Project Team

September 29th, 2006

2

Horizon CDR: Agenda• Horizon Overview• Framework Overview

– Horizon Purpose and Use– Domain Model

• Open Issues from PDR– Aeolis-Subsystems - Testing– Constraint Checking

• STL Map– Dependencies– Schedule Validation– Value Function– GUI interface

• Final Delivery– Documentation

• User Guide• Code Comments

– Unit Testing• cppunit testing• _ASSERTE• CSC “Expert”

• Future Modifications for Horizon Improvement

– Scheduler Improvement• Options• Dependency/Constraint Optimization -

“Fail Fast”– Robust/Release Code– “Optimize” code for speed

• Open Source Tools• Development in Visual Studio Express

using STL, (no Windows MFC)• GNU General Public License and GNU

Lesser General Public License– xmlParser– mySQL++– Doxygen

Horizon Project Overview

4

Design Iteration and Requirements Feedback

A-Spec

Segment Specs and Interface

Documents

Utility Analysis

Models and

Equations

Final Specs for

Sell-off

Vetted Desig

n?

Horizon

5

Glossary• Environment - The entity in which systems reside, and to whose physical

rules they are subject• System - A stateful entity that performs tasks• Subsystem - A component representing an aspect of the system, possibly

dependent on other subsystems• State - A collection of variable values that record the properties of a system

at a specific point in time• Variable - A varying quantity that completely or partially defines the state of

a subsystem• Constraint – An externally imposed restriction on the legal values of a

variable• Schedule - A time-ordered sequence of events• Event - A scheduled performance of a Task during a time interval• Task - An action to be performed at a target, whose interaction with the

Geometry Model provides limitations and suggestions for scheduling• Target - A named object with a position that may vary• Scheduler - An actor that creates valid schedules for a system• Schedule Evaluator - An actor that assigns values to schedules

6

Version Control

• Using Subversion– Single Computer at Cal Poly is Subversion

Server• IP : 129.65.180.100

– Tortoise Subversion Client• Connect via pinhole and port 3690• Username and Password Protected• Uses SSH for transfer security

Horizon Framework Overview

8

Domain Model

9

Namespaces• horizon – main program• horizon::eval - value function• horizon::geom – Environment, Position,

Propagator, Sun• horizon::sub – all Subsystems• horizon::sub::dep – subsystem dependancies• horizon::ui – User Interface• horizon::util – Matrix, Quaternion, ODE, etc…• horizon::util::umath – utility math operations• std – Standard Namespace

10

Class List• horizon::Constraint • horizon::Event • horizon::Schedule • horizon::Scheduler • horizon::State • horizon::StateVar • horizon::Subsystem • horizon::System • horizon::Target • horizon::Task• horizon::eval::ScheduleEvaluator • horizon::eval::QuantitativeSchedul

eEvaluator• horizon::geom::Environment

• horizon::geom::Position • horizon::geom::Propagator• horizon::geom::Sun• horizon::sub::ADCS • horizon::sub::EOSensor • horizon::sub::SSDR • horizon::ui::TextUI• horizon::ui::UI • horizon::util::eoms • horizon::util::Matrix • horizon::util::matrixIndex • horizon::util::ode • horizon::util::odeResult• horizon::util::Quat

11

Documentation• Doxygen

– Open source tool for creating documentation from source code comments– Structured Format– Example:

• list< Schedule * > horizon::Scheduler::schedule (System & system, const list< const Task * > & tasks, const State * initialState, double startTime, double endTime, double stepLength )Generates valid schedules for the systems

• Parameters:– system the system for which to generate schedules tasks the tasks to schedule initialState the

initialState of the system startTime the earliest time at which tasks can be scheduled to start endTime the latest time at which tasks can be scheduled to end stepLength the amount of time between each possible task start time

• Returns:– a list of dynamically allocated schedules

• Definition at line 13 of file Scheduler.cpp. • References horizon::System::canPerform(), END_TIME_KEY,

horizon::System::getPosition(), horizon::System::getSimulationStartJD(), START_TIME_KEY, and TASK_START_TIME_KEY.

Constraints

13

Constraint Summary

• A constraint is an externally applied restriction on the state of the system

14

The Constraint Class• The Constraint class is the base class off of

which each constraint is derived as its own class. For example, a constraint on power would have its own class derived from Constraint

• Each constraint keeps a list of subsystems that must be run in order to generate the state data to be checked

• Each constraint overrides the virtual function Constraint::Pass(State), which contains a conditional statement that checks whether the state data in question is acceptable

15

The Subsystem List• This list must include the subsystems that are directly related to the

relevant state data and all prior subsystems that they are dependent on.

• The two examples below show subsystem lists for a constraint on state data written by subsystem A

Sub A

Sub B

Sub C

Sub A

Sub B Sub C

SubsystemList{B}

(Note: Dependencies travel in the direction of the arrow.On the right, A is dependent on both B and C)

SubsystemList

{B, C}

16

The Pass Method

• The state data generated by running the subsystems in the subsystem list is then evaluated by Constraint::Pass(State)

• Pass is passed the current state of the system and then checks the constraint

if state variable acceptable return trueelse return false

Dependencies

18

Dependency Summary

• Subsystems are often dependent on other subsystems for necessary information. Since neither subsystem should be explicitly aware of the other, this information must be obtained through a third party interface called a dependency.

19

The Dependency Class

• The Dependency class allows subsystems to access dependency functions that obtain and modify information from another subsystem

• The class keeps a list of all dependency names and maps these names to the appropriate dependency functions, which are declared in the Dependency header file and defined in the Dependency source file.

20

Dependency Names

• Each dependency has a name based on the relationship between the two subsystems

• “DependentSub_InfoType_SourceSub”• With this naming scheme a dependent

subsystem can quarry the Dependency class for all dependencies of a certain type without knowing what the other subsystems are or how many there are

• The static method that returns the list of dependency names is:Dependency::searchDependent(“DependentSub”, “InfoType”)

21

Dependency Map

• Each dependency name is mapped to its corresponding dependency function. For example, “DependentSub_InfoType_SourceSub” could be the key for the function DependentInfoSource(State)

• A dependency is called with the static method Dependency::depFunc(“DepName”, State). It uses the name as a key to the appropriate function and then passes it the state. It returns a list of type list<pair<double,StateVar>>, a flexible container for values that is also used by the State class

22

Schedule Validation

• Test results are available so testing is Underway

23

Test Output

-150 -100 -50 0 50 100 150-60

-40

-20

0

20

40

60

24

Value Function

• Currently set as the number of Events in a Schedule– The final delivery will contain a list of

recommended approaches• State Variable Value• Resource Conservation• Etc…

25

GUI interface

• Derek is working the GUI from the CEC end– Xml input files are well suited for GUIs– A list of input parameters to the Simulation

Framework need to be made– Any other input parameters need to be

identified– Some hard coded values need to be moved to

input fields

26

Documentation

• User Guide– Under development– “Step-by-step.doc”

• A guide to building a simulation model with constraints and dependencies

• Code Comments

27

Unit Testing

• cppunit testing– Not implemented

• _ASSERTE– Used to test obvious necessary conditions

during debug

• CSC “Expert”– We need someone!

28

Future Modifications for Horizon Improvement

• Scheduler Improvement

• Options

• Dependency/Constraint Optimization - “Fail Fast”

• Robust/Release Code

• “Optimize” code for speed

29

Open Source Tools

• Development in Visual Studio Express using STL, (no Windows MFC)

• GNU General Public License and GNU Lesser General Public License– xmlParser– mySQL++– Doxygen

30

Issues from Derek’s Visit• Feedback from schedule via subsystem.canPerform as to why the subsystem failed/performed

• Documentation (doxygen) linked to flow chart of main framework function calls/logic

• add variable schedule list size for Greedy Alg option - DONE• add time scale windowing

• DOCUMENTATION – IN PROCESS (5%)

• Run time studies – WE CAN NOW START– target deck size and time step size

• Profile run time – WE CAN NOW START

• Outline of Users Guide (10%)– How to set up a system (20%)

• Validation plan– Subsystems– Framework - Bogus model vs. full model

• Validation cases on flow chart of main framework function calls/logic