Horizon: CDR The Horizon Project Team September 29 th, 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 : –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 programhorizon horizon::eval - value functionhorizon::eval horizon::geom – Environment, Position, Propagator, Sunhorizon::geom horizon::sub – all Subsystemshorizon::sub horizon::sub::dep – subsystem dependancieshorizon::sub::dep horizon::ui – User Interfacehorizon::ui horizon::util – Matrix, Quaternion, ODE, etc…horizon::util horizon::util::umath – utility math operationshorizon::util::umath std – Standard Namespacestd

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 eEvaluatorhorizon::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 horizon::Scheduler::schedule (System & system, const list & tasks, const State * initialState, double startTime, double endTime, double stepLength )Generates valid schedules for the systemsScheduleSystem TaskState 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.13Scheduler.cpp References horizon::System::canPerform(), END_TIME_KEY, horizon::System::getPosition(), horizon::System::getSimulationStartJD(), START_TIME_KEY, and TASK_START_TIME_KEY.horizon::System::canPerform()END_TIME_KEY horizon::System::getPosition()horizon::System::getSimulationStartJD() START_TIME_KEYTASK_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 BSub C Subsystem List {B} (Note: Dependencies travel in the direction of the arrow. On the right, A is dependent on both B and C) Subsystem List {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 true else 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 >, 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

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