Viewing page 17 of 172

This transcription has been completed. Contact us with corrections.

A study done by the training division at NASA Johnson Space Center (JSC) to assess the mission simulation capacity of the SMS concluded that the SMS cannot support more than 12 to 15 flights per year (ref. 5). This is less than the scheduled rate prior to STS 51-L.

The STA's are used to train the pilot and commander of an STS mission for the final phases of entry and landing. Currently, there are three STA's. Including maintenance and ferry time, 127 hours of STA time are required on the average per mission. With the three STA's currently in the inventory, a maximum of 2150 hours per year of STA time will be available. These numbers assume no unforeseen problems with the STA's.  Studies conducted by the Flight Crew Operations Directorate have concluded that, within NASA's current requirements and safety constraints, the STA's can support training for a maximum of 17 NSTS missions per year (ref. 6).

Like the SMS, the STA's require an increasing level of maintenance, inspections, and upgrades as they get older. There are currently no increased funds allocated for these purposes.

2. Procedures State

The procedures required for the conduct of an NSTS mission are contained in the Flight Data File (FDF). The FDF consists of the Crew Activity Plan (CAP), checklists, cue cards, maps and charts, and support hardware (including portable onboard computers). The development and production of the FDF is impacted by changes to the procedures that are brought into the system late. These changes may be due to late manifest changes, problems with the procedures discovered during training, problems with the hardware found during NASA Kennedy Space Center (KSC) testing, or late inputs from the customers or investigators. Starting with STS 41-C in April 1984, the change traffic had stabilized and was not considered to be a major issue affecting training. The late arrival of manifest changes, payload data, and software often caused the mission-specific FDF to be later than desirable.

3. Flight Software

The Orbiter flight software development and verification process is characterized by strict configuration control, rigorous software development, process management control, substantial automation of the software reconfiguration process, and an independent test and verification philosophy.

Data indicates that software testing has been thorough and consistent through the Space Shuttle Program. Software shelf life remains a concern. Change traffic continues high for an "operational" program. Additionally, late software patches are frequently required and are used for operational convenience. These late changes, due to the lack of shelf life, represent an element of increased risk and in a mature operational program should be minimized.

-55-