A Cargo Planning, Analysis, and Configuration System for the International Space Station

Franz Developers Symposium

Harvard University, Cambridge, MA

Flight 7A.1, which launched August 10, 2001, was a re-supply flight carrying a Multi-Purpose Logistics Module (MPLM) to the International Space Station. As the Crew Station Operations Division at NASA planned and integrated the stowage within the MPLM, the people involved went through a process of settling what they wanted to bring with what they could bring. The determination of what could be flown required an analysis guided by the following questions: Will our stowage fit? What does it weigh? Will the payload be balanced? Will anything break if we load it according to the current plan?

Based on the analysis, decisions were made as to where racks, stowage provisions, and thousands of pieces of hardware were to be located. Many people were involved in the decisions, and many changed their minds. While previous flights had relied on a combination of CAD tools and spreadsheets, Flight 7A.1 was the first MPLM flight to be planned and integrated using a Common Lisp application called the Cargo Planning and Analysis System (CPACS).

The Boeing Company created the original CPACS as a Commercial Off The Shelf (COTS) product for NASA. The application was first developed on a Symbolics Lisp Machine. Before delivering the CPACS to NASA, Boeing ported it to the Sun Solaris platform using the Allegro Common Lisp compiler sold by Franz, Inc. As delivered to NASA, the CPACS didn't model the complete range of stowage provisions. Nevertheless, a project engineer at Johnson Engineering (JE) had used the CPACS and found it quite useful for his analysis. This prompted a NASA

program manager to approach the Crew Station Operations Division about the potential benefits of the software. Could the CPACS be of any benefit to one of the labs making Space Station Crew Configuration Drawings?

Debbi Boettger, a technical coordinator and developer from one of the JE labs, began an analysis of the software and the cost of a Lisp development project. The demonstration of the software contained glitches, but this didn't create so much skepticism about the project as did the prospect of finding and training a person to write Common Lisp code for an application using the Common Lisp Interface Manager (CLIM).

Since the software had the potential to eliminate much of the tedium associated with stowage integration, the project was initiated, and the search for a Lisp developer started. This was where I entered the project. I was hired to add NASA's new stowage provisions and integrate them with the auto-packing procedures and mass-properties calculations in CPACS. The CPACS also needed a way to import manifest characteristics data from the Vehicle Master Database (VMDB) for thousands of parts.

When I began the job of modifying and supporting the CPACS, I had no experience developing software with Common Lisp. My

manager invested in a month of training with a senior developer from Franz Inc. With this training investment and with the productivity of Common Lisp the project became a success. Before I could update the application to meet the new requirements, I faced two significant challenges: making the application friendly to debugging and understanding the design of the application.

During the month of training I learned to take advantage of the many timesaving features of the language and development environment. I learned to add an error handler that would catch an error condition, while the program was running, compute the possible restarts, and present them to the user in a menu. This menu also presented the option of E-mailing a bug report or invoking the debugger. By invoking the debugger I learned to inspect the call stack of the running application, automatically jump to the source code of the problem procedure, incrementally compile the correction, and finish without ever having to restart or recompile any other part of the application. This was also an important improvement for anyone using the CPACS. Now an error would not kill the application and lose someone's work.

To understand the design of CPACS, I learned to use the Composer tool to graph class hierarchies. This provided a reference

for understanding the class relationships and helped answer questions like, "Is an EXPRESS-RACK an MPLM-CONTEE?" I used the graphical inspector, also a part of Composer, to browse the slot-values of class instances. A function call to this graphical inspector, placed in the command menus of application objects, allowed an instance of a class like RACK or TRAY to be selected and inspected right within the running application. This saved the time of having to build an instance at the top-level, or having to capture an object using a special variable. Another time-saver I learned was the use of two monitors. Since I work on a PC, which is next to the Solaris where Allegro is installed, I can use X-windows to display Emacs on the PC and CPACS on the Solaris. In this set-up I can take advantage of incremental recompile without having to flip through layers of buried windows.

The groundwork for debugging and understanding the application carried through to the rest of the project. To implement new stowage provisions I had to understand what existing objects and methods were related to the new requirements.

By adding new code I would inevitably break something, so I would then debug and refactor the combination of old code and new. As I went through the process of coding changes to the CPACS, the adaptability of the Common Lisp Object System (CLOS) made the job easier. The way I updated the CPACS method CHOOSE-POSITION illustrates the flexibility of the language. For current flights most of the stowage is packed into cargo transport bags, but the COTS CPACS only modeled the positioning of trays within Re-supply/Stowage Racks (RSR).

All RSR's have a number of discrete positions for holding trays. In CPACS a tray was placed into a rack by selecting a position from a menu created within the method CHOOSE-POSITION:

(defmethod choose-position ((contee enumerable-contee) conter)
   "Present a menu and return the selected IJK position" 

   ...)

The cargo bags added complexity to the positioning procedures because their possible locations may be discrete (enumerable), continuous, or a combination of both depending on the container. Each combination of bag and container type warranted a slightly different procedure for positioning. Positioning cargo bags into RSR's required selecting a compartment from a menu and then interactive positioning with the pointer to choose a position and orientation somewhere within that compartment. This unique way of positioning a bag in an RSR was easily distinguished by using a more specialized method:

(defmethod choose-position ((contee bag) (conter RSR))
   "Project the screen position, chosen by moving the bag around 
with the pointer to a position in the rack."  
   ...)

Another newly designed rack, the Re-supply Stowage Platform (RSP) holds its bags in discrete positions. Again, CLOS facilitated the specialization:

(defmethod choose-position ((contee bag) (conter RSP)) 
   "Present a menu and return the selected IJK positions."  
   ...)

Whatever the context--printing location codes, assigning find-numbers, auto-packing, etc.--I was able to create specialized methods that organized the behavior of Cargo Bags and RSP's and other hardware types. The separation of methods from objects also allowed for placing methods in separate files to be compiled and loaded separately into the system. This greatly simplified patching and reduced compile time because touching or adding a method would not force all code that operated on a certain class to be recompiled.

When I finished coding and testing the Cargo Bags, the RSP, and the automated data import, the CPACS was capable of planning a flight. Using spread sheets and a CAD tool, the planning and analysis required to developing an initial load plan for an MPLM flight could take up to two weeks. Using the CPACS, the same planning and analysis could be done by one flight lead in about 6 hours. The process of specifying locations for parts was faster since

the CPACS could auto-pack containers using different strategies and priorities. When a manifest changed, less work was repeated because existing load plans could be saved, copied, changed and reverted to. When changes to the manifest required parts to be moved around, weights and mass properties were automatically recalculated. Communication was improved by the reports generated in CPACS, and data could be shared with other software by exporting to a file using a comma-delimited format. The CPACS was a successful investment in Common Lisp and has enabled flight leads to analyze flights like 5a.1, 7A.1, UF1 and UF2 in less time than before.

References

Franz Inc. (2001). Allegro Cl 6.0 [computer software]. Berkeley, CA. Available from http://franz.com/products/allegrocl/

Franz Inc. (2000). CLIM 2 User Guide. Retrieved from https://web.archive.org/web/20030311074404/http://www.franz.com:80/support/documentation/6.0/doc/clim-ug.pdf

Petty, J.I. (Ed.), (2005). ISS Assembly Mission 7A.1. Retrieved from https://www.nasa.gov/mission_pages/station/structure/iss_assembly_7a1.html

Petty, J.I. (Ed.), (2005). Multi-Purpose Logistics Module. Retrieved from https://www.nasa.gov/mission_pages/station/structure/elements/mplm.html

___

Copyright © 2005 Jason Kantz

http://www.kantz.com