Simulation
This simulation ties together all other components of the modeling framework, taking the mission scenario as an input and producing the output information to fully describe and evaluate the mission scenario.
Inputs
The mission scenario can be generated either by users or by the optimization module. When users want to simulate/evaluate existing mission scenarios, they define the mission scenario, then execute the simulation and get output.
Outputs
The outputs from the simulation have been carefully determined. Currently the simulation generates three different types of histories:
- Element History (EHistory)
- Node History (NHistory)
- Crew/Cargo History (CHistory)
Each of the histories describes the mission scenario from a specific viewpoint.
EHistory tracks the elements, giving the location and transportation history of each element. It also provides the mass (propellant and dry mass) and crew/cargo information for each element.
NHistory tracks the nodes and provides information on which elements are located on each node at a specific time. CHistory racks crew/cargo and shows which element the crew/cargo belongs to at a specific time. Information provided by the three histories is not independent. Some of them are redundant and form different interpretations of the mission scenario.
SpaceNet outputs the time history of a scenario in Excel format for postprocessing and visualization. The Excel file below shows the history of fuel across time and nodes for each element in a reference lunar exploration sortie scenario.
Excel file: CS1x.xls (enable Macros when opening)
Three types of histories, which are the results from the simulation, are used to calculate the measures of effectiveness (MOE) and also to generate the visualization which will help users to understand the simulated mission scenario. Both of them are explained in different sections.
Software Architecture
There are two different ways to propagate a simulation: time-driven and event driven. In the time-driven propagation method, a time step is specified and "states" of the simulation object are updated on every time tag determined by the time step. The time-driven method performs well when we are interested in knowing the states of the simulation object as a function of time (e.g. position/velocity/ acceleration of a launch vehicle). The selection of the time step is very important in this type of simulation. If the time step is too small, the output data become very large. Too large time step makes it hard to capture the change of states properly. An event-driven method, on the other hand, updates the state upon every "event" which causes a change in states. If we are primarily interested in the processes (or events) and related changes in states instead of the full descriptions of the processes themselves, the event driven method is more efficient.
As a result, the ISCMLA simulation uses the event-driven method. We are not interested in what happens "during" the process (e.g. transporting from one node to another or waiting in one node). Rather, the important questions for the users are the following: what are the states "before" a specific process, what are the characteristics of the process, and what are the states "after" the process? Suppose that an element is placed in the LEO and transported to the lunar surface. We want to know the information about the element and node before the transportation process (mass and crew/cargo of the element, physical node characteristics and time), characteristics of the transportation process (departure node, ΔV, time of flight, arrival node), and information after transportation process.
