# Presentation: 916296

## The Automated Planning and Scheduling ENvironment (ASPEN). Overview and Lessons Learned

- SPLAT Team
- 	Jeff Lubelczyk*:  **	*_[Jeffrey.T.Lubelczyk.1@gsfc.nasa.gov](mailto:Jeffrey.T.Lubelczyk.1@gsfc.nasa.gov)_
- 	Lynne Case*:  **	*_[lynne.case@commerceone.com](mailto:lynne.case@commerceone.com)_
- 	**Jeff Robinson:  ****	**_[jeffrey.robinson@commerceone.com](mailto:jeffrey.robinson@commerceone.com)_
- 	Tundey Akinsanya*: *_[babatunde.akinsanya@commerceone.com](mailto:babatunde.akinsanya@commerceone.com)_

**Notes:**
Welcome and thanks for attending the ASPEN Lessons Learned TEA. 

Let me introduce our team: Our Goddard Contact is Jeff Lubelczyk. The project leader is Lynne Case. My name is Jeff Robinson and I’m a developer. I was
responsible for the back end or server portion of SPLAT. Tundey Akinsanya is the other developer on the team and he was responsible for the SPLAT GUI.

What’ll be presented today is an overview of the ASPEN system, how ASPEN was used in the SPLAT tool, and the lessons learned during development.

## Agenda

- What is ASPEN?
- What is SPLAT?
- ASPEN Details
- SPLAT System Model
- ASPEN Lessons Learned
- SPLAT Demonstration

**Notes:**
Here’s the Agenda for today’s presentation. 
We’ll briefly describe ASPEN and SPLAT
Give and overview of ASPEN’s features an operation
Show a system model for the SPLAT Tool.
Go over the lessons learned during development
An give a brief demonstration of the SPLAT tool.

## What is ASPEN

- ASPEN is the **A**utomated **S**cheduling and **P**lanning **En**vironment.
- An object-oriented planning and scheduling engine.
- Developed by the Artificial Intelligence Group (AIG) at the Jet Propulsion Laboratory (JPL).
- ASPEN is composed of the following pieces:
- Server or Scheduling Engine
- Graphical User Interface (UI) Client
- Primary application area is the spacecraft operations domain.
- A continuous planning extension for ASPEN is available. The Continuous Activity Scheduling Planning Execution and Repair (CASPER).

**Notes:**
What is ASPEN. Well, ASPEN is an acronym standing for Automated Scheduling and Planning Environment. 
A object oriented planning and scheduling system designed and developed by the Artificial Intelligence Group at JPL. 
JPL is still developing ASPEN. Enhancements and modifications are currently underway with an eye on moving the ASPEN/CASPER system on-board. Recompile underway using VxWorks compiler. 
JPL defines ASPEN as an object-oriented system which provides a reusable set of software components that implement elements commonly found in complex planning/scheduling systems. What are the components found in these systems? : An expressive modeling language (AML), a constraint management system for representing and maintaining spacecraft operability and resource constraints. A set of search strategies, A temporal reasoning system for expressing and maintaining temporal constraints, and a GUI for visualizing plans/schedule.
Scheduling Engine or server is written in C++ and is tied to the UNIX platform (Solaris and LINUX). 
Client is written in JAVA so it’s platform independent. Note the we were able to get the client to running correctly on Solaris, Windows NT and Windows ME. However the client didn’t behave properly under Windows 98.
 The primary application area is the spacecraft modeling domain.
CASPER stands for Continuous Activity Scheduling Planning Execution and Repair. It’s an extension to ASPEN that allows for real time replanning based on current events. We don’t have experience using CASPER. It was simply mentioned here for completeness.

## ASPEN System Model

**ASPEN Server**

**ASPEN GUI**

**Model**
**Files**

**Activity &**
**Resource **
**Instances**

**Schedules**

**UNIX/LINUX**

**Heuristics**

**Timeline**
**Instances**

**User **
**Function**
**Libraries**

**Notes:**
This is a block diagram of the ASPEN system showing the major components and inputs/output for the system. Notice that the ASPEN Server (Scheduling Engine) must be hosted on a UNIX/LINUX environment. However the ASPEN client (GUI), can be run on any platform supporting JAVA.
The connection between the client and server is socket based. 
ASPEN takes as input the following:
Model files – Contain definitions of the spacecraft resources, activities, parameters, states.
Heuristics – Detail functions to use during schedule repair and optimization.
Time line instances – A list of state variables, resource, etc. to be modeled on timelines.
User Function Libraries – Custom parameter functions used in model activities, user defined scheduling functions, and custom heuristic functions used during schedule repair and optimization
Activity & Resource Instances – Instances in time of activities and resource defined in the model files.

From this series of input files and operator interaction with the GUI ASPEN can be used to create plans and schedules. 
The GUI provides a graphical display of plans and schedules. It allows for manipulation of schedules via drag and drop functionality.

## What is SPLAT

- SPLAT – The **S**olid State Recorder (SSR) **PL**ayback **A**utomation **T**ool.
- Automates the process of generating playback schedules and pass plans for the SSR buffers.
- Developed as the first phase of the Goal Oriented Command Generation (GOCG) project.
- Client and Server written in JAVA.
- Objectives of SPLAT:
- Provide a useful tool to assist in a manually intensive portion of the scheduling process for TERRA.
- Gain a better understanding of the ASPEN system.
- Prove ASPEN’s usefulness in a real-world application.

**Notes:**
The Terra SSR Management Tool partially automates the generation of SSR Playback schedules and Playback Pass Plan preparation
These activities are performed by members of the flight operations team using manual procedures supported by Microsoft Excel spreadsheets. 

Proof of Concept to prove ASPEN’s usefulness in a real world application.

The main components of the SPLAT system are the GUI client and SPLAT server. 
Both are written in JAVA. The server is restricted to the UNIX environment at this point. 
The JAVA client can run on any platform supporting JAVA. Currently, it’s been tested on Solaris (UNIX) and Windows NT.

## Running ASPEN

- ASPEN can be started at the command line or via UNIX shell script.
- Commonly started via script due to large amount of information that needs to be specified to server.
- Example invocation of ASPEN
***%aspen –S 2000 –j –F functions.so –h heuristics.tab –m test.mdl –i test.ini***
- Modes of Operation
- Batch mode
- Interactive via command-line
- Interactive via JAVA GUI

**Notes:**
Information such as the port number for Socket communication, all model files, instance files, parameter function libraries, heuristics, preferences, etc. are generally passed to ASPEN at startup. Note that these can also be specified using the load project option available in the GUI.
The example ASPEN invocation start the ASPEN server with socket communication listening on port 2000 and the java GUI. A user functions library called functions.so, a user defined heuristics table (heuristics.tab) the model file test.mdl and instance files (.ini) ASPEN has three modes of operation: batch, command line and gui.
Aspen can be run in one of three modes, batch, interactive via a command-line or interactive via the ASPEN GUI.
Batch mode execution is indicated by the –b command line argument. In this mode of operation, ASPEN is controlled via script. The script or plan file contains ASPEN commands and runs without operator intervention (plans, saves, and exits).
Command line mode. ASPEN is started in a shell command loop. All commands such as project load, dispatch and repair are available and are entered in the shell. Schedule details if desired can be viewed in a textual interface.
Interactive via Java GUI. All commanding of the server is via Socket connection.  The GUI can run on any hardware which supports JAVA. The GUI provides a visual display of the current schedule. The display includes Activity and Resource timelines with activity instances overlayed on the timelines.The GUI allows users to manipulate a schedule using drag and drop procedures.

## Spacecraft Modeling with ASPEN

- Model Components
**A**spen **M**odeling **L**anguage (AML)
- Parameter Functions
- Aspen Provided
- User Supplied
- Creating an ASPEN Model (TERRA SSR example)
- Activity Instances vs. Activity Definitions

**Notes:**
Here we intend to discuss how a spacecraft’s resources and operations are modeled into a form useable by ASPEN.
For each spacecraft to be scheduled, a model must be created. So we’ll discuss the components of the model briefly.
Next we’ll discuss the spacecraft modeling language used in ASPEN (AML).
Then we’ll touch on parameter functions which are an important part of AML models.
Next we’ll give a brief description of how the components in the TERRA SSR Model
Then we’ll discuss the differences between an activity instances and definitions.

## Model Components

- Model Horizon
- Contains information such as the name of the model, the planning horizon, and time units. (start and stop time/date)
- Activity Definitions
- Activities are the core feature of ASPEN models.
- They represent an action or step in a plan or schedule. An example of an activity would be an image take for a specific instrument.
- Activities can be composed of other activities (decompositions)
- Parameters
- Parameters within ASPEN represent user defined types such as constants, strings or lists.
- Parameter Dependencies
- Parameter Dependencies represent a functional relationships between two parameters. (e.g. Activity end time is a function of start time and duration)

**Notes:**
A spacecraft model in ASPEN is comprised of the following components. A model horizon, Activity definitions, parameters, parameter dependencies, temporal constraints, resources, and state variables.

The Model Horizon describes the extent of the planning horizon, time units used in the timeline displays and general information pertaining to the entire planning horizon.
Activity definitions are the Central feature of a model. They represent actual operations performed by spacecraft. Example of activities in the TERRA SSR model are Imaging activities for the different instruments and playback activities for each of the SSR buffers.  Note that an individual activity can be a composite of multiple child activities. For example A Downlink may be a composite of multiple playbacks and each playback may be a composite of an individual buffer or instrument playback.
Parameters are used to represent user defined data types in ASPEN. Examples of parameters in the TERRA SSR model are the imaging and playback rates for each of the instruments and buffers.
Dependencies within a model describe functional relationships between two parameters. (An example of a dependency would be the Activity end time. It is a function of start time and duration of the activity).

## Model Components (Continued)

- Temporal Constraints
- Temporal Constraints represent relationships between the start or end of one activity and the start or end of another activity.
- Specified in activity definitions.
- Resources
- Represent the profile of a physical resource or system variable over time.
- Stored internally as integers. Range limited to –230 to 230-1
- Can be extended to other values through use of Generic Time Lines (GTL).
- Specified in the *resources.mdl* file.
- State Variables
- Represent the values of discrete variables over time.
- Example: A state variable could be used to represent whether it is day or night for the spacecraft.
- Specified in the *state-variables.mdl* file.

**Notes:**
Temporal constraints indicate relationships between the start of one activity and the end of another. These are commonly used in activity decompositions to determine ordering when an activity decomposes into several child activities. 
Different types of resources exist within ASPEN. These include depletable and non-depletable resources. An example of a depletable resource in the TERRA SSR model is the ASTER SSR buffer. It can be filled and emptied. An example of a non-depletable resource in the TERRA SSR model is the ASTER instrument. 
Note that Generic Time Lines option is still under development. Modifications are needed to speed up processing and change handling of GTL resource depletion in AML.
State variables are used to represent the values of discrete variables overtime. For instance one might use a discrete variable to model day and night events for a spacecraft.

## ASPEN Modeling Language (AML)

- Used to model the Spacecraft behavior and operation.
- AML syntax is similar to C code.
- The basics are very easy to learn.
- Documentation is lacking for advanced features.

**Notes:**
What is the ASPEN modeling Language? It’s the language used to specify a spacecraft’s operation and resource in a way that ASPEN can understand. In order to correctly model a spacecraft’s behavior, all activities, resources, state variables, parameters, instances, timelines, etc. are specified in AML code.
The AML syntax is very similar to C code. Definitions of activities, parameters, etc. are similar to structure definitions in C. 
Creating a basic model with AML is simple. We were able to accomplish this is a matter of days. 
However, in order to develop a useful model one needs to be aware of and understand the advanced modeling features available in AML.These advanced features were poorly documented and required consultation with JPL personnel to completely understand them.

## AML Example

- Example AML activity definition
- Activity ASTER_Playback {
-   int buffer_usage;		 	// Amount of ASTER Buffer used
-   int amt=[-infinity,0];                		// Amount to download
-   playback_rate pb_rate;                	// Playback rate 131.25 MBits/sec
-   ASTER_capacity aster_cap;
-   // Grab buffer usage from timeline
-   timeline_dependencies =  buffer_usage <- aster_buffer_usage;
-   // Don't allow ASPEN to add playbacks
-   no_permissions = ("add");
-   // Calculate amount of ASTER buffer to downlink
-   dependencies = amt <- playback_amt(duration, pb_rate, aster_cap, buffer_usage);
-   // Removed amount played from buffer
-   reservations = aster_buffer_usage use amt;
- };

**Notes:**
This activity definition is taken directly from the TERRA SSR model. This activity controls playback of the ASTER buffer in the SSR.
Lines 2-5 define variables used in the activity.  Note that the amt variable is limited to the range [-infinity, 0]. If the variable exceeds this range, a conflict will occur. Lines 4 and 5 contain variables based on parameter definitions.
Timeline dependencies are used when one needs to grab the value of a resource at a given time. The local variable buffer_usage is assigned the value of the timeline resource aster_buffer_usage.
Permissions are specified with a “permissions or no_permissions” command. They specify what operations the repair and optimization algorithms can perform on an instance of this activity.
Dependencies exist between timeline values (buffer usage) and the amount of data to be played back. This in mind, a parameter function was created to calculate the amount of the buffer to be played back based on the activity duration and the buffer usage.
Reservations allow the activity to change the setting of a resource. One the buffer playback amount has been determined, subtract the calculated amount from the buffer resource.

## Parameter Functions

- ASPEN provides a core set of Parameter Functions that can be used to manipulate values in models.
- Multiply – return the product of two numbers
- Sum – return the sum of two numbers
- Subtract – return the difference of two numbers
- Max – return the larger of two numbers
- Min – return the smaller of two numbers
- Inv – returns the inverse of the argument
- Extendable via User Defined Parameter Functions.
- Written in C++.
- Must adhere to the ASPEN Parameter Function interface.
- No documentation but simple functions are easy to create.
- Compiled into a shareable object prior to ASPEN execution.
- Loaded into ASPEN with model. (-F switch)

**Notes:**
Parameter functions provide a means to calculate values needed for an activity.  Generally parameters to an activity or resource values are passed to a parameter function which computes a return value based on the arguments. ASPEN provides a series of parameter functions. These functions provide the basic math operations, add, subtract, multiple, divide, min, max and inverse.
Parameter functions are extendable by the user but require knowledge of the interface to ASPEN. Additionally creating more than basic function types requires an intimate knowledge of the ASPEN class structure. 
User defined parameter functions are specified in external C++ files and must adhere to the following rules. All arguments and return types must be (real, int, bool, float, or const char*). 
All user defined parameter functions are loaded into ASPEN at startup via the –F commandline switch. They can also be specified during project load in the ASPEN GUI.

## Creating an ASPEN Model (TERRA SSR)

- Creating the TERRA SSR model involved examining the spacecraft operation and determining the following:
- Activities and events which affect the Solid State Recorder.
- The resources needed to accurately model behavior of the SSR
- State variables needed to reflect discrete events.
- All resources that were to be modeled on timelines
- Parameters needed to model instrument rates.

**Notes:**
Creating the TERRA SSR model involved deciding which of the resources and activities of the TERRA spacecraft affected the operation of the SSR buffers. It is important to note that only those resources and activities are modeled in the TERRA SSR model. We didn’t need to model information about system buses because they had no bearing on scheduling. 
The idea was to model imaging and playback activities, resources and states for all instruments. CERES, MODIS, MISR, ASTER, and MOPITT.
Determining activities for the model include understanding which spacecraft operations affected the SSR Buffer state. Activities identified here included imaging, playback, orbit maneuvers and NADIR day/night crossings. 
Resources in the SSR model include the SSR buffers for ASTER, MISR, MODIS, and LRS.  These are depletable resources. Additional resources include the actual instruments (CERES, ASTER, MISR, MODIS, MOPITT) are examples of resources in the TERRA SSR model. 
State variables are used to model the S and K band inview/outview periods, playback lockout times (such as orbit maneuvers), and day/night events for the spacecraft.
Resource timelines used in the model include any and all resources to be modeled over time. These include the SSR buffers, the S and K band inview/outview times, playback lockout times, and the day/night events.
Separate parameters are used to define the individual imaging and playback rates of the different instruments and modes of operation. Note that ASTER has 14+ modes of operation and MODIS images at a different rate for DAY and NIGHT.

## Activity Definitions vs. Instances

- It’s important to understand the difference between activity definitions and activity instances.
- What are Activity Definitions?
- Define the operation of an activity.
- What resources are used.
- Activity hierarchy (Decompositions).
- Temporal constraints among child activities.
- What are Activity Instances?
- An instantiation of an activity definition to be placed on the timelines.
- Contains a start time, stop time or duration and any parameters for the activity.

**Notes:**
Activity definitions define the actions performed by an activity or event and any restrictions or dependencies the activity may have. These include the resources used, any child activities, temporal constraints, dependencies. Activity definitions can be thought as a class definition or template for an activity. How the activity does it’s work
Activity instances represent an instance of an individual activity. They define an instance of an activity on a timeline. Rather than defining how the activity acts, they define where the activity is on the timeline, the duration of the activity and they provide any additional parameters needed during activity scheduling. Analagous to an Object in Java.

## Planning and Scheduling Algorithms

- Simple Placement
- Simply grounds activity start times at the earliest time and places them on their timelines.
- Forward Dispatch
- Expands activities first, then places activities on the timelines at legal locations in a forward-sweeping manner
- Timeline Manager
- Similar to Forward dispatch, except it removes activities that are found to violate timeline conflicts
- Pack Activities
- Pushes each scheduled activity to its earliest possible start time.
- User Defined Scheduling Algorithms
- Custom scheduling algorithms developed as add-on to ASPEN
- Difficult to implement.

**Notes:**
ASPEN provides five options for initial planning and scheduling algorithms. These algorithms are used to generate an initial schedule from the input model and instance files. They are as follows:
Simple placement does no checking for constraint violations or conflicts. It simply drops activities on the timeline at the earliest location on the timeline. 
Note that we didn’t use the timeline manager or pack activities algorithms. They are mentioned here for completeness
Users can also develop their own scheduling algorithms to fit special needs. Note that we didn’t develop and user defined scheduling algorithms. These seemed complex and weren’t well documented. Additionally we didn’t need this feature. Developed much like parameter functions. They are an extension to ASPEN. Compiled externally into a shared object and loaded into ASPEN at execution via command line options.

## Conflict Resolution

- Iterative Repair
- Addresses conflicts one at a time until no conflicts exist, or a user defined time limit or number of repair iterations has elapsed.
- Repair Heuristics
- Used by the iterative repair algorithm to decide what to repair and how to repair the conflict.
- Help to prune search and rule out less promising planning choices
- Choice Points and Built-in Heuristic Functions
- Twelve choice points where decisions are made during conflict resolution.
- Built-in functions can be used to control behavior of conflict repair at each of the choice points.
- Customizable via modification to the ‘*heuristics.tab*’ file.
- User has option of adding custom heuristic functions. Custom functions must be written in C++.

**Notes:**
Often times a schedule generate by ASPEN is not conflict free. Conflicts can be of many types. Perhaps they involve an over subscription of a resource or a violation of parameter dependencies. They could also occur due to violation of temporal constraints among activities. In any case, ASPEN provides a means to resolve scheduling conflicts.
The method for repair schedules in ASPEN is know as iterative repair. Iterative repair involves addressing scheduling conflicts one at a time until all conflicts are resolved. 
Repair heuristics are provided as a way to guide the conflict resolution process. These heuristics tell the repair method what choices to make during schedule repair. They idea here being that these heuristics help to prune the search and rule out less promising planning choices. 
The heuristics are customizable by the operator. Not only can one choose which repair method will be used at a particular point but one can also create custom heuristic functions. Again no experience here creating custom heuristics.  But they’d be created and loaded into ASPEN much like the parameter functions. 

## Schedule Optimization

- ASPEN can generate more than one conflict free schedule from a series of input files.
- Conflict free schedules may not be optimal.
- ASPEN provides for rating schedules using preferences.
- Schedules are ranked on a scale from 0 to 1. With 0 being the least optimized and 1 being a perfect schedule.
- Schedule optimization is similar to schedule repair.
- A set of optimization heuristics is specified in a heuristics file. The optimization heuristics tell ASPEN engine how to proceed during schedule optimization.

**Notes:**
What is schedule optimization? Schedule optimization is a method provided by ASPEN to improve the quality of a given schedule. 
It is important to note that ASPEN can generate multiple conflict free schedules. It is also possible that those schedules are not optimal. 
Preferences allow the user to specify how the schedule should be rated. Much like repair, preferences are used at checkpoints to rate certain aspects of the system. From these preferences a score for the schedule can be generated. 
Schedule optimization can occur for any schedule whose score is less than one. 
Optimal schedules would have a score of 1. Non optimal schedules would have a score of  < 1.
Schedule optimization behaves like schedule repair. The optimization routine uses optimization heuristics defined in the heuristics tables to make choices about what type of optimization to perform during the optimization. Note that schedule optimization stops after 200 iterations or a schedule score of 1 is achieved.

Note that for SPLAT preferences and schedule optimization weren’t used. When no preferences are specified, the score of a schedule is 1.

## Schedule Formats

- ASPEN schedules can be saved in one of two formats.
- AML Format
- Saves schedule in AML format. All activities, resources, states, etc. instances saved in a flat text file.
- Default file name is *Schedule.ini* but is operator selectable.
- User Defined Format
- Saves schedule in a user defined format to a flat file.
- Commands.fmt file specifies mapping of Activity names to output format. Entries exist in commands file for each activity to be stored.
- Default file name is *schedule.cmd*.

**Notes:**
ASPEN allows the user to save a generated plan/schedule or portion of schedule to output. These schedules can be saved in one of two formats. Either AML format or a User Defined format. 
A schedule saved in AML contains all activities, resources, states, timelines, etc. It is saved as AML activity instances in a flat text file. Both the directory for the file name of the schedule are user selectable. 
Optionally, the user can choose to save a schedule in a user defined format. In order to do this the user specifies how the output schedule will look in commands.fmt file. The commands file contains a mapping from the activity and resource definitions to the users specified format. Individual activities and parameters can be saved in a user defined format. Again as was the case with the AML schedule save, the directory and named of the saved command file are user selectable.

## SPLAT System Model

**ASPEN Server**

**Daily Reports**

**SPLAT Server**

**SPLAT GUI**

**ASPEN GUI**

**Timeline**
**Instances**

**TERRA**
**Model**
**Files**

**Playback**
**Schedules**

**PassPlan**
**Sheets**

**Starts**

**Notes:**
This is the block diagram showing the SPLAT system.
It is important to note that all operator interaction with the splat system is via the SPLAT GUI. 
The SPLAT GUI starts the ASPEN GUI after playback schedule generation
The SPLAT GUI and server communicate through JAVA RMI.
THE ASPEN GUI and ASPEN server communicate via a socket interface.
The SPLAT SERVER commands and controls the operation of the ASPEN Server through the same socket interface used by the ASPEN GUI.

## How SPLAT works

- SPLAT operates as follows:
- Four Daily reports are ingested for each day to be scheduled. They are:
- AM1 Integrated Report
- ATC Load Report
- Buffer States Report
- DAS Report
- The daily reports are parsed, extracting activities, resources, and contact periods.
- Timeline files containing AML activity instances from the extracted activities, resources, constraints, etc. are created and stored.
- Create Playback Schedules from the timelines files and store these in AML format.
- Create & Store Pass Plans for selected contacts in a playback schedule.
- Generate (Print) Pass Plan Sheets created by ASPEN.

**Notes:**
Note ingestion can be manual through GUI or automatic via FTP from MMS system.

## Lessons Learned

- ASPEN is a powerful scheduling engine which can be used to model multiple spacecraft.
- ASPEN was more powerful than required for the SSR scheduling task.
- Terra already has a planning and scheduling tool so using ASPEN as an external tool was overkill
- Development of Terra model in short-time demonstrated ASPEN’s flexibility
- Support from JPL for problems inconsistent
- Programmers support customers as needed while still enhancing the system
- They came through with critical bug fixes and performance improvements when necessary
- Building ASPEN locally was not a trivial task
- Compiler differences led to errors during build.
- Lack of documentation makes complex models difficult to develop
- Resource types and precision are inadequate
- Resources must be integers
- Limited range –230 to 230-1
- Generic Time Lines not a viable alternative yet. (Cumbersome and slow)

**Notes:**
Note that we built ASPEN using GNU C++ 2.95.2 while JPL was using GNU C++ 2.85. Template casting problems were identified as warnings in 2.85 but identified as errors in 2.95.2. Required changes all over the source code. 
Only documentation on model creation was the example models included with the distribution. A very simple model without much interaction among activities was easy to develop. However tasks such as creating a split playback activity to handle orbit maneuvers during a contact period were difficult to create. 
Additionally, the way resource usage is modeled on timelines required partitioning long running activities into a group of shorter duration activities. Resource usages for an activity is applied to the resource timeline at the start of an activity. For an activity of duration 120 seconds which fills a buffer, the entire resource usage is applied at the beginning of the activity rather than linearly over time as one would expect.
The types of resource available in ASPEN and the range of values the resources code take (precision) are inadequate. Resources modeled on timelines must be integers. The can have a range of –230 to 230-1. This range was not wide enough to accurately represent the buffers in the SSR. These buffers ranged in size from 1 billion to 90 billion bits and needed to be modeled to the bit level. An advertised solution involved extending the resource timeline types using the Generic Time Lines framework. However the execution speeds of the terra model using GTL’s proved to be woefully slow. Apparentyl GTL’s have problems that need to be addressed. JPL is aware of the problems but as of yet they have not been fixed.
 Software maturity is a big issue. We continually encountered crashes and ungraceful exits on models that had run correctly before. Crashes were difficult if not impossible to track down and solve.

## Lessons Learned (Continued)

- Socket Interface to server is not documented well.
- Sparse documentation at best.
- Fragile
- Software Reliability
- Many crashes and ungraceful exits by the server.
- Performance
- System performance is largely a function of
- Schedule size (Number of activities)
- Schedule complexity
- Faster to generate a more abstract schedule.
- Documentation
- ASPEN documentation is very poor.
- A limited out of date User’s guide exists.
- No Programmers manual.
- Source code documentation is sparse at best.
- Conflicting or incorrect documentation in some instances.

**Notes:**
We found that the performance of ASPEN is largely based on the size of the schedule. Not necessarily the length but rather the number of activities to schedule. An additional factor includes the complexity of the schedule. Many interacting activities with multiple decompositions can affect the execution speed of ASPEN. In essence, the more abstract the schedule, the faster it’ll schedule.

The lack of documentation particularly, a programmers guide is the biggest deterrant to using the more advanced features in ASPEN. These features require an intimate knowledge of the ASPEN source code structure and interface. The documentation for these interfaces and the classes need is lacking at best. Source code documentation is also sparse and often incomplete. Additionally the User’s guide is out of date and incomplete.

## SPLAT Demonstration

**Notes:**
What we want to show here is the a basic demonstration of the SPLAT tool. 

## Resources

- ASPEN Website
- _[http://www-aig.jpl.nasa.gov/public/planning/aspen/aspen_index.html](http://www-aig.jpl.nasa.gov/public/planning/aspen/aspen_index.html)_
- CASPER Website
- _[http://www-aig.jpl.nasa.gov/public/planning/casper/](http://www-aig.jpl.nasa.gov/public/planning/casper/)_
- SPLAT Website
- _[http://pioneer.gsfc.nasa.gov/public/splat/](http://pioneer.gsfc.nasa.gov/public/splat/)_