Franz Developers Symposium

March 26, 2001

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

Jason Kantz

Johnson Engineering Corporation

 

Flight 7A.1, scheduled for July 12, 2001, is a re-supply flight carrying a Multi-Purpose Logistics Module (MPLM) to the International Space Station.  As the Crew Station Operations Division at NASA plans and integrates the stowage within the MPLM, the people involved will go through a process of settling what they want to bring with what they can bring.  The determination of what can be flown requires an analysis guided by the following questions: Will our stowage fit?  What does it weigh? Will anything break if we load it according to the current plan?  Based on the analysis, decisions are made as to where racks, stowage provisions, and thousands of pieces of hardware will be located.  Many are involved in the decisions, and many change their minds.  While previous flights have relied on a combination of CAD tools and spreadsheets, Flight 7A.1 is 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 made 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?  What would it cost to hire the needed people to bring the software up to date?  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 many glitches, but this didn't create so much skepticism about the project as did the prospect of finding the right 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 Steve Haflich, a senior developer from Franz, Inc.  With this training investment and with the productivity of Common Lisp the project has become 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 every timesaving feature of the language and development environment.  Since the existing code had a default behavior of killing the Lisp whenever an error was signaled, we added an error handler that would catch an error condition, compute the restarts, and present them to the user in a CLIM 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.  If the development environment didn't provide all the information I needed, the process of making changes to the code would have been next to impossible. 

 

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 is 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 add complexity to the positioning procedures because their possible locations may be enumerable, infinite, or a combination of both depending on the container.  Each combination of bag and container type warrants a slightly different procedure for positioning.  Positioning cargo bags into RSR's requires the selection of a compartment from a menu and then interactive positioning with the mouse 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 mouse, to a position in the rack." 

   ...)

 

Another 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.  Organizing the procedures for these special cases would not have been so simple in a language that uses static typing and a message-passing model for object methods.  Without generic functions I would have spent less time writing useful code and more time trying to figure out how to perform this dispatch on multiple types.

 

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 for developing an initial load plan for an MPLM flight can take up to two weeks.  Using the CPACS, the same planning and analysis can be done by one flight lead in about 6 hours.  The process of specifying locations for parts is faster since the CPACS can auto-pack containers using different strategies and priorities.  When a manifest changes, less work is repeated because existing load plans can be saved, copied, changed and reverted to.  When changes to the manifest require parts to be moved around, weights and mass properties are automatically recalculated.  Communication is improved by the reports generated in CPACS, and data can be shared with other software by exporting to a file using a comma-delimited format.  Since these timesaving capabilities have been integrated with the RSP, the Cargo Bags, and the data import, the investment by Crew Station Operations has certainly paid off.  Now the CPACS has four users analyzing flights 5a.1, 7a.1, UF1 and UF2 in less time than ever before.