Date post: | 13-Dec-2015 |
Category: |
Documents |
Upload: | sophie-benson |
View: | 223 times |
Download: | 1 times |
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