NASA Goddard Space Flight Center
Robert T. Caffrey, NASA/GSFC
The following material is taken from the paper, "Forth in Space: Interfacing SSBUV, a Scientific Instrument, to the Space Shuttle," written by Robert T. Caffrey for the June, 1992, Rochester Forth Conference. It describes the development of the Forth-based Small Payload Accommodations Interface Module (SPAIM), which interfaces the Shuttle Solar Backscatter Ultraviolet (SSBUV) instrument to the Space Shuttle’s avionic systems. The SSBUV instrument is used to calibrate ozone measuring instruments aboard NOAA satellites. The SPAIM firmware was developed using chipFORTH and custom hardware based on a 87C196KC16 CPU.
There is always great concern about software reliability, especially with flight software. The effects of a software error in flight could be dramatic. We were able to produce reliable software by writing a Forth routine on the PC, downloading the software, and testing it interactively. We varied the inputs to a routine and checked the ability of the routine to operate correctly under all conditions. As a result, during the STS-45 Shuttle mission, the Small Payload Accomodations Interface Module (SPAIM) flight software worked perfectly and without any problems.
The multitasking operating system enabled SPAIM to operate with a flight program in background and a monitor program in foreground. This feature is probably the single most important element enabling us to develop reliable software quickly and efficiently. The monitor program permitted "spying" on the flight software as it would operate in flight. The data structures, counters, error flags, and status registers were easily accessible and could be checked as the flight system was running. This demonstrated the proper performance of the flight software. The development system is an integrated package, so monitoring the flight software didn’t require a special debugger program or unusual debugging commands.
We used the development system to model hardware before the actual interface was available. In the foreground, the development system would place a command string in the queue, monitor the background flight program, and verify its proper operation. We used a similar method to test the other interfaces before the hardware was available. This produced tested and proven software interfaces before the hardware was present, which greatly accelerated the system integration schedule.
The ability of the chipFORTH development system to debug hardware and software interfaces, model missing hardware, simulate system malfunctions, and support system integration dramatically helped in the quick generation of error-free software. The interactive, integrated and multitasking features of the chipFORTH system proved to be the key elements in the success of the SPAIM systems development.