March 26, 2001
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.