[J1] Mission Planning and Operation Team Report

Preliminary

Revision A

 

 

May 1986

---

Tommy W. Holloway, Lead, MPOT

---

Harold M. Draughon, Deputy, MPOT

 

 

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION

LYNDON B. JOHNSON SPACE CENTER

HOUSTON, TEXAS

I. NARRATIVE SUMMARY.

II. GENERAL ASSIGNMENT LETTER.

III. ORGANIZATION/METHOD OF INVESTIGATION.

IV. ACRONYMS.

V. MISSION PLANNING AND OPERATIONS TEAM REPORT.

A. STS 51-L Planning and Preparations.

B. STS 51-L Mission Operations.

C. Mission Planning.

D. National Space Transportation System (NSTS) Mission Operations.

E. NSTS Flight Rate and Flight Scheduling.

VI. MAJOR FINDINGS AND CONCLUSIONS.

VII. REFERENCES.

 

APPENDIX A. RANGE SAFETY REPORT (Not Reproduced).

APPENDIX B. KSC LANDING CONSIDERATION REPORT. (Not Reproduced).

APPENDIX C. CREW ESCAPE SYSTEMS REPORT. (Not Reproduced).

APPENDIX D. ORBITER MAINTENANCE/INSPECTION SYSTEMS SUMMARY. (Not Reproduced).

APPENDIX E. EXECUTIVE SUMMARY OF FLIGHT SOFTWARE REVIEW BRIEFING TO THE PRESIDENTIAL COMMISSION. (Not Reproduced).

APPENDIX F. FLIGHT CREW INVOLVEMENT IN THE SPACE SHUTTLE PROGRAM. (Not Reproduced).

APPENDIX G. STS 51-L FLIGHT OPERATIONS TEAM SUMMARY REPORT. (Not Reproduced).

[J2] I. Narrative Summary.

Approximately 11:39 a.m. eastern standard time (EST) (01:13 mission elapsed time (MET)) on January 28, 1986, the Space Shuttle Challenger experienced vehicle breakup. Preliminary investigation teams were activated within the hour. On March 6, 1986, Mr. Tommy W. Holloway was notified by teleconference of the establishment of the Mission Planning and Operations Team (MPOT) of the Space Transportation System (STS) 51-L Data Design and Analysis Task Force. The letter appointing him Lead and Mr. Harold Draughon, Deputy, along with the general assignment for the MPOT, is contained in section II of this report. The primary task of this team was to respond to the needs and interests of the Mission Planning and Operations Panel of the Presidential Commission on the Space Shuttle Challenger Accident. Additionally, the team was tasked to undertake a critical review and analysis of the National Space Transportation System (NSTS) mission planning, mission operations team functions, flight rate, and flight scheduling, and to determine what effects these activities had on the STS 51-L accident.

The scope of this investigative effort was limited due to the lack of time to permit in-depth, thorough review and analysis. The basic report of findings are in section V of this report with selected backup technical reports included as appendices. The major findings and conclusions are in section VI. Additional data and reports are provided in section VII. Also, presentations, documents, and material provided to the Commission Panel are listed in section III.

The data in this report will show that the STS 51-L mission was a typical STS mission with nothing in the mission operations reconfiguration out of the ordinary. From the period of time during the prelaunch countdown and launch until the vehicle breakup, there was no mission operations abnormality. Also, there was no survival action possible to the STS 51-L crew or possible action the Mission Control Center (MCC) flight control team could have taken to assist the crew.

Data made available during this investigation showed that, in the areas of NSTS mission planning and NSTS flight rate and flight scheduling, although 1985 was considered a very successful year, meeting the milestones for 1986 was going to be a difficult goal.

There is an indication of the need to reevaluate the baseline operational goals for the STS in light of today s program resources.

The findings of this report support the contention that the NSTS had done a commendable job in the areas reviewed prior to the STS 51-L accident. The findings also suggest that careful consideration should be given to assessing flight rate buildup strategy for implementation before Space Shuttle flights resume.

II. General Assignment Letter.

March 20, 1986

51-L DATA AND DESIGN ANALYSIS TASK FORCE

TO: T. Holloway

FROM: Task Force Chairman

SUBJECT: Appointment of Lead, Mission Planning and Operations Team

1. By letter of March 11, 1986, Attachment 1, the Acting Administrator delegated to me, as Chairman of the 51-L Data and Design Analysis Task Force, the power to designate teams required to support the Task Force. By the same letter. he also delegated to me the power to establish procedures for organization and operation.

2. Pursuant to the delegation, I hereby establish the Mission Planning and Operations Team of the Task Force and assign you to be the Lead for that Team. The duties, functions and responsibilities of that Team are stated in Attachment 2.

3. As Team Lead, it will be your responsibility:

a. To assign tasks to Team members and coordinate their efforts.

b. To delegate authority to your Deputy Lead to act for you as you see fit with or without your being present at the Team's regular office at KSC.

c. To coordinate the Team's activity with other Team Leads in areas of mutual interest.

d. To consult with the Task Force Vice Chairman on a regular basis on all aspects of Team activity.

e. To prepare, for consideration and approval by the Task Force, documents that memorialize in appropriate formats, the facts and analysis in the Team's assigned area.

Richard H. Truly

[J3] General Assignment for Mission Planning and Operations Team.

The Mission Planning and Operations Team shall perform, as a priority task, the Task Force efforts needed to respond to the needs and interests of the Mission Planning and Operations Panel of the Presidential Commission. The Team Lead and his deputy shall establish a working relationship with the Commission Panel Leader consistent with the procedures of the Task Force and the Commission.

The Mission Planning and Operations Team shall undertake a critical review and analysis of the NSTS mission planning. The purpose of the review and analysis is to ascertain the adequacy of this program activity. The Team shall focus on relevant areas of interest such as the following:

1. Flight planning capabilities as constrained by current resources and schedules.

2. Schedule pressures and impacts.

3. Expansion of the developed flight envelope.

4. Mission planning preparedness.

The Team shall assist the Commission in its investigation of mission planning so as to determine if there were any aspects of mission planning that could have contributed to the STS 51-L accident.

The Mission Planning and Operations Team shall undertake a critical review and analysis of the NSTS Mission Operations Team functions and a qualitative assessment of their performance. The purpose of this review and analysis is to ascertain the adequacy of this program activity.

The Team shall focus on relevant areas of interest such as the following:

1. Flight operations capabilities.

2. Flight operations preparedness.

3. Flight procedures adequacy and maturity.

4. Range safety requirements.

5. Mission operations safety.

The Team shall assist the Commission in its investigation of the Mission Operations Team so as to determine what effect the Mission Operations Team had on the STS 51-L mishap.

The Mission Planning and Operations Team shall undertake a critical review and analysis of the NSTS flight rate and flight scheduling. The purpose of the review and analysis is to ascertain the adequacy of this program activity.

The Team shall focus on relevant areas of interest such as the following:

1. Technician and engineer workload.

2. Flight controller training adequacy.

3. Adequacy of time allotted to mission design and development.

4. Hardware and software testing program content changes.

5. Postponement of repairs, modifications, and software changes.

6. Effects of flight rate coupled with other programmatic pressures on mission planning and mission operations.

The Team shall assist the Commission in its investigation of flight rate and flight scheduling so as to determine what effect these factors had on the STS 51-L mishap.

III. Organization/Method of Investigation.

The day following the Data Design and Analysis Task Force (DDATF) introduction meeting at NASA Kennedy Space Center (KSC) (March 10, 1986), the Lead, Mission Planning and Operations Team (MPOT) called an organizational meeting to assign actions for the Presidential Commission Panel visit the following day. At that time, it was decided to subdivide the work effort for the team into 16 working groups (fig. 1), each group to perform data gathering activities (1) to support the work of the Mission Planning and Operations Panel (MPOP) to the Presidential Commission, and (2) to determine if any organization or functional area of the National Space Transportation System (NSTS) had had an effect on the Space Transportation System (STS) 51-L accident. An administrative/executive support working group was established to develop administrative procedures for the team and take action on any otherwise unassigned action items. Policies and procedures for the MPOT as well as protocol for presentations to the MPOP were established. An action tracking system and a secure filing system were set up, and a special MPOT runner system was activated with the assistance of the Mission Operations Directorate (MOD) Flight Data File (FDF) Branch. To accommodate comparisons of like sources of data in evaluating norms and trends, an evaluation STS flight set was established consisting of STS 5, 6, 7, 41-DR, 41-G, 51-A, 51-F, 51-I, 61-A, 61-B, and 61-C. By the end of the first week of activity, Leads had been assigned for each working group. The group leads were provided with a packet containing:

• Appointment Memorandum
• Policies and Procedures
• Presidential Panel Protocol
• MPOT General Assignment
• Working Group Preliminary Work Plan

The investigative work to be conducted by each working group was defined by either a DDATF/MPOT action item assignment or work plan implementation. All investigations were scoped down to consider only factors relating to NSTS mission planning or NSTS mission operations since other DDATF Task Teams were assigned to consider such areas as failure analysis and launch systems and processing analysis.

Meeting with the Mission Planning and Operations Panel

From mid-March through mid-April 1986, a series of meetings were held between the Mission Planning and Operations Panel of the Presidential Commission and the Mission Planning and Operations Team of the NASA Task Force. The following comprises a list by date of the topics covered by formal presentations.

1. March 11, 1986

a. General Mission Planning and Operations Introduction.

b. STS 51-L Flight Design.

c. STS 51-L Crew Activity Planning.

d. General Abort Modes/STS 51-L Abort Boundaries.

e. STS 51-L Training.

 

2. March 12, 1986

a. Safety Reliability and Quality Assurance Review.

b. Manifesting Process and Change Effects.

 

3. March 24, 1986

a. Range Safety.

b. Major Milestone History.

c. Orbiter Landings.

d. Weather Flight Rules/History of Weather Calls.

e. RTLS Rain Damage Assessment.

 

4. March 25, 1986

Space Shuttle Main Engines - Containment.

 

5. March 31, 1986

a. Orbiter Hardware Testing.

b. Summary of the Operations Base.

c. Payload Safety Process.

d. Training.

e. Procedures State.

 

6. April 8, 1986

a. Workload Assessment in Key Areas

[J5] b. Software

c. Manifesting

 

7. April 9, 1986

a. KSC Landing Considerations

b. TAL Landing Considerations

 

8. April 15 1986

a. Expansion of Ascent Envelope

b. First Stage Abort Option History

Material provided to the Mission Planning and Operations Panel

The following material was requested by and given to the Mission Planning and Operations Panel of the Presidential Commission during the course of their investigation.

1. Documents

a. A complete set of all STS-51-L Flight Requirements Documents

b. Flight Readiness Review Minutes for STS 51-L

c. Cargo Integration Review Minutes for STS 51-L

d. Flight Operations Review Minutes for STS 51-L

e. STS 51-L Flight Operations Team Summary Report

f. Space Shuttle Directives, JSC-20939

g. NASA Handbook 5300.4 (10-2) - Safety, Reliability, Maintainability and Quality Provisions for the Space Shuttle Program

h. Problem Reporting and Corrective Action System Requirements for the Space Shuttle Program - JSC-08126A

i. Procedures for Problem Reporting and Corrective action - JSC-09296

j. Safety Policy and Requirement, NHB 1700.7A

k. Implementation Procedure for STS Payloads System Safety Requirements, JSC-13830A

l. Space Shuttle Payload Design and Development Safety Guidelines and Requirements, JSC-20052, vol. 7

m. Interpretations of STS Payload Safety Requirements, JSC-18798

n. Union/Employer Agreement Between NASA, LBJ and AFL-CIO, Local 2184

o. The JSC Workforce in Profile: FY85

p. Expansion of the Ascent Flight Envelope, TE-86-059

q. STS Flight Software Review, April 21, 1986

2. Miscellaneous Background Data

a. Launch minus one day briefing packages for the Terminal Countdown Demonstration Test and for the Launch for STS 51-L

b. Levels II and III documentation related to changing SRB O-ring seals from criticality IR to 1

c. Minutes of August 1, 1985, Senior Safety Review Board

d. JSC Mission Control Center manning lists for STS 51-J, 51-B, 51-D, and 61-A

e. A summary of past flight techniques as related to first stage aborts, DDATF-86-69

f. A list of STS 51-L accident related JSC documents, ECLSS DDATF-86-33

g. An assessment of the cost of changes made to the 61-C manifest, DDATF-86-49

h. A set of anticipated trajectory parameters for STS 51-L including altitude, speed, Mach number, dynamic pressure, and throttle position, DDATF-86-22

i. A history of Aerospace Safety Advisory Panel

j. A history of the Space Shuttle Crew Safety Panel, NS/86-M017

k. A complete list of STS 51-L systems maintenance and inspection deferrals with rationale

1. A description of all planned abort sites including facilities and deficiencies. DDATF-86-58

m. Design crash loads data for the Orbiter and payloads

n. A complete set of minutes from the Senior Safety Review Board since STS-1

o. The minutes of all Systems Integration Board meetings between December 1, 1982, and July 1, 1983

p. A chronology of events related to assessment of the 61-C brake anomaly and the impact of brake failures on a Dakar Landing, DDATF-86-65

q. A copy of JSC Flight Director Loop voice transcripts of the period immediately prior to until shortly after the STS 51-L launch

r. An overview of the spare parts situation from the JSC perspective, VP3-86-M037

s. An assessment of the impact of the STS operations contract on the JSC workforce, DA-RRR-86-06

t. Report of Working Group on Expansion of the Entry Flight Envelope, DM5-86-24

u. SOPC/SMS Loading/Response to SOPC Support Questions, March 6, 1986.

IV. Acronyms.

V. Mission Planning and Operations Team Report.

Introduction

The findings of the Mission Planning and Operations Team (MPOT) of the Space Transportation System (STS) 51-L Data Design and Analysis Task Force (DDATF) were presented to the Mission Planning and Operations Panel (MPOP) of the Presidential Commission on the Space Shuttle Challenger Accident in a series of eight formal meeting sessions and three data exchange meetings between March 11 and April 15, 1986. Ten of these sessions were at the Lyndon B. Johnson Space Center (JSC) and one at the George C. Marshall Space Flight Center (MSFC). In addition to the formal briefing sessions, the MPOT also provided responses to 38 action items from the MPOP. This report is a synopsis of all the information presented to the panel with emphasis on those areas of the NSTS found to be deficient or in need of possible further analysis. The basic report presents the background data used to make findings and conclusions listed in section VI. The MPOT is well aware that there are some areas of the NSTS organization and functions which are not addressed in this report; they were not overlooked, but were omitted because of lack of time and the lack of any indicators of a need to pursue them.

V.A. STS 51-L Planning and Preparations.

Introduction

Overall, the planning and preparations for Space Transportation System (STS) mission 51-L were very typical of the missions being planned and flown in late 1985 and early 1986. For the most part, the techniques and procedures that were planned to be used during the mission were not new for this flight but were baselined from previous missions. This section uses the flight preparation template as the framework by which to describe the planning and preparations accomplished for STS 51-L, starting with determining the makeup of the flight manifest.

1. Flight Manifest Determination

The original mission for Space Transportation System (STS) 51-L was baselined in the Flight Definition and Requirements Directive (FDRD) dated May 30, 1984. The configuration was

Ten FDRD changes applicable to STS 51-L (summarized in table 1 and figure 1) were approved prior to flight. The final configuration consisted of

The NASA crew assignment was released on January 27, 1985, and consisted of the following:

• CDR -Francis R. Scobee
• PLT -Michael J. Smith
• MS -Ronald E. McNair
• MS -Ellison S. Onizuka
• MS -Judith A. Resnik

The Teacher in Space Program (TISP) payload specialist (PS), Christa McAuliffe, was added to the crew with a Flight Requirements Document (FRD) change signed on June 13, 1985. Although the PS was on the manifest, her payload was not in the documentation. This editorial correction was made in FDRD change number 126 on January 7, 1986. The Hughes PS, Gregory B. Jarvis, was added to the crew with an FRD change signed on November 11, 1985.

Changes to the payload manifest caused the baseline flight design process to be delayed, which required a launch date slip from the initial early July 1985 date to the final date in late January 1966. After the Cargo Integration Review (CIR) was accomplished, the primary payload manifest was very stable. However, several changes to the secondary manifest occurred after the L-5 freeze point. With the exception of the addition of the PS's as their payloads were added to the manifest, the crew assignment was never changed.

2. Baseline Flight Design

Using the baselined FDRD manifest dated May 30, 1984, the initial Cargo Integration Review Dry Run (CIRD) and Cargo Integration Review (CIR) were scheduled on June 27 and September 4, 1984, respectively. The intent of these reviews was to perform the preliminary engineering assessments and evaluate the conceptual flight design's feasibility. The end product was to baseline the FRD. These review dates were subsequently slipped to August 21, 1984, for the CIRD and October 2, 1984, for the CIR. The CIRD was conducted on August 21, 1984, but the CIR was rescheduled to November 27, 1984, to accommodate the manifest change deleting EOS-1 and adding Aussat 1. This...

---

---

[J12]....date was subsequently slipped to December 18, 1984 and slipped again to January 22, 1985. Before the CIR could be held in January, the manifest and the Orbiter assigned both changed. Aussat was deleted, the HS-376 was added, and OV-104 replaced OV-099. The CIR was rescheduled to March 18, 1985, and the launch date slipped from July 2, 1983, to November 27, 1985. Again, prior to this CIR, the manifest, the Orbiter, and the launch date changed, requiring that the CIR be rescheduled to June 18, 1985. The HS-376 was deleted, the Orbiter was changed back to OV-099, and the launch date was slipped to January 22, 1986.

The June 18, 1985, CIR was held on the scheduled date. Table 2 shows the CIR history in graphic form, Even though there were six changes to the CIR date for STS 51-L, due primarily to payload manifest changes, the relationship between the final CIR and the January launch date was according to the planned flight preparation template and the final process worked very smoothly.

3. Flight Product Development

a. Production Milestones

Once the primary payload manifest was stable and the CIR process was completed, the flight design process became relatively straight-forward, with nothing out of the ordinary associated with the STS 51-L mission operations reconfiguration process from a flow management standpoint.

The most noticeable, and potentially significant, result of slips in the production process was to delay the start of flight-specific Shuttle Mission Simulator (SMS) standalone and integrated training. Without a launch slip, the delay in starting training compresses the training activity and increases the crew and flight controller workload in the last month before flight.

The portions of the flight production template that directly involve the Mission Operations preparations are shown in figure 2, along with the planned and actual delivery dates of key production milestones for STS 51-L.

The L-5 month Flight Planning and Stowage Review was conducted on August 20, 1985, with the purpose of addressing any open items and any proposed changes to the existing baseline, and of establishing a finalized set of requirements for STS 51-L. The FRD, Crew Activity Plan (CAP), and flight design/consumables status were reviewed as well as the current status of the engineering integration, photo/TV requirements, and crew compartment stowage. Significant actions resulting from this review included the need for further review of the launch window requirements with the intent to provide a longer launch window, looking at potential tradeoffs to allow carrying the OASIS payload, and the requirement to carefully define and fully document the activities and requirements for the Teacher in Space Program (TISP), which had. not been completely finalized yet. Work on the launch window constraints, particularly the SPARTAN constraints, continued past the Flight Operations Review (FOR). The OASIS was never manifested, and the TISP work was all completed satisfactorily.

b. Flight Data File

The CAP was never published in preliminary form as the publication template has the preliminary CAP produced at L-7.7 months and the CIR was not until L-6.5 months. Instead, since one of the most critical portions, the tracking and data relay satellite (TDRS) deployment timeline, was almost identical with the previous STS 51-E mission, the STS 51-E CAP was used as the baseline document until the STS 51-L basic edition was published at L-4 months. The CAP cycle for STS 51-L was affected by several late manifest changes and incomplete documentation on some of the payloads that were added. Late changes, in this context, are changes to the manifest after the FOR has baselined the payload-related Flight Data File (FDF) and included the addition of CHAMP, FDE, and PPE. Except for CHAMP, these changes were all minor, were within the capability of the system, and were similar to changes on other flights. CHAMP was slightly more difficult to integrate into the timeline because the activities had to be accomplished at very precise times and thus displaced other previously planned activities. The incomplete documentation consisted of Payload Integration Plans (PIP's) for the TISP and PPE. Not having all the payloads' requirements available in the PIP's made integrating payload activities into the timeline impossible until any constraints were identified. The end result was a delay in performing the update to the timeline. The impact of the delay in publishing the final CAP was minimized by delivering the attitude timeline on December 13, 1985, and using the basic edition of the CAP, dated November 15, 1985, for simulations until the final edition was available. Both activities served their purpose well, and, except for the CAP preparation function, there was no impact of the late publication. Table 3 contains a chronology of changes to STS 51-L along with change impact to the CAP and CAP publication dates.

In addition to the CAP, 24 other FDF documents were published in preparation for STS 51-L. Half of the documents published were either flight-specific flight supplements to generic procedures already carried onboard, or flight-specific books published specifically for STS 51-L (such as the IUS Deploy Checklist). The remaining half of the documents published in preparation for the mission were changes and updates to generic procedures that were not necessarily flight specific (such as updates to the Data Processing System (DPS) dictionary and updates to the Medical Checklist). The number of documents published for STS 51-L was fairly typical for missions in that timeframe and was not considered excessive. From an FDF standpoint, STS 51-L was considered a moderately complex flight because of the rendezvous and proximity operations conducted in support of SPARTAN. The procedures were not new, but they did have to be tailored to support the SPARTAN's requirements. The inertial upper stage (IUS) deploy, again from an FDF standpoint, was considered standard because of the fact the procedures had been baselined from STS 6 and STS 51-E. All procedures were validated by January 9, 1986. Changes to the FDF are made via NASA Johnson Space Center (JSC) Form 482. Figure 3 depicts the 482 traffic experienced for STS 51-L as a function of time prior to launch. The traffic was not unlike the customary traffic for similar missions and was well within the capabilities of the system.

The FOR for STS 51-L was conducted on October 22 to 24, .1985, to review the payload-related FDF and associated mission documentation and to note discrepancies against the documentation. At that time, 235 discrepancies were submitted: 166 were approved, 2 were disapproved, and 67 were withdrawn. There were no major procedure changes in any of these discrepancies, with the majority of changes consisting of editorial and format changes. As a result of the FOR, 13 action items were generated. Those of significance included tasking JSC and NASA Goddard Space Flight Center (GSFC) to develop procedures for conducting a backup SPARTAN mission with the SPARTAN still in the bay (i.e., it could not be deployed), and also tasking the STS Program Office and GSFC to determine the earliest launch time for the period from January 22 through January 30, 1985, and to set the planned STS 51-L launch time and window. The SPARTAN in-the-bay procedures were completed, verified, and practiced by the crew, and the launch window issue was finalized by the time of the Flight Readiness Review (FRR).

In summary, the FDF was complete and ready for flight. The number of changes processed late (post-FOR) was well within the system's capability and were primarily due to manifest changes and refinements in the SPARTAN rendezvous and malfunction procedures. The number of changes processed was also fairly typical of missions being flown in that timeframe.

c. Flight Rules

The STS 51-L Flight Rules consisted of the generic All Flights Rules and the STS 51-L Flight-Specific Rules Annex. The All [J13] Flights book used was dated December 16, 1985, and had one pen and ink change posted (dated January 23, 1986). The Flight Rules Annex containing the STS 51-L flight-specific rules was first published as a preliminary edition prior to the FOR. After the FOR, a final edition dated December 20, 1985, was published which incorporated the updates agreed upon in the FOR with any open items being reserved for a page change notice (PCN). Some open items were closed later than anticipated, so the PCN was held and issued as a pen and ink change. Most open items involved waiting for actual new data to be provided, such as the final ascent targeting numbers and IUS transfer orbit performance estimates. The only open item that also included open work was the decision on where the weather alternate for the transatlantic abort landing (TAL) site would be (Sidi Slimane or Casablanca) and the SPARTAN constraints on the final launch window. All these items were closed and pen and ink change I was published on January 20, 1986. In the last few days prior to launch, a second pen and ink change was published, dated January 24, 1986, that further refined some trajectory and guidance rules and some SPARTAN latching definitions, but none were controversial or involved. One IUS issue was worked before flight that was not published in the Flight Rules Annex, but it did have an approved change request completed. The topic of the change request was IUS deploy without cable tray separation. The Safety Office participated in the review of this rule change, and an approved rule wording was agreed upon in a teleconference between all interested parties. The crew was briefed on the rule change and understood and agreed on its contents. The rule change will be incorporated in the baseline rules for the next IUS mission.

d. Flight Techniques and Payload Operations Meetings

There was only one Orbit Flight Techniques meeting for STS 51-L. The Orbit Flight Techniques meeting was conducted on December 6, 1985, and baselined the forward reaction control system (RCS) separation technique to be used, if needed, for the IUS deploy, and several procedural topics concerning SPARTAN deploy and retrieval, and the SPARTAN in the bay mission. Following this Orbit Flight Techniques meeting, no unresolved issues or controversial topics were left open and the only action items concerned implementing the procedures baselined in the meeting. Additional Orbit Flight Techniques meetings were not required because the nature and agenda of the Payload Operations Working Group (POWG) meetings allowed most on-orbit topics to be worked in those forums.

Five Ascent/Entry Flight Techniques meetings were held in the 12 months prior to STS 51-L. None of these meetings addressed any STS 51-L flight-specific topics.

One IUS/TDRS POWG was conducted August 23, 1985, for STS 51-L. From an IUS/TDRS standpoint, very few new topics were to be worked for STS 51-L since most issues had been worked for STS 51-E, which was the baseline for STS 51-L. Topics of interest discussed included the use of a star scan attitude update technique for the IUS, when the "GO" for deploy should be given to the crew, the criteria for making the decision to deploy, and the data rates at which the IUS and the Orbiter would transmit telemetry while on orbit.

Two SPARTAN 203 (SPARTAN-Halley) POWG's were held for STS 51-L. The first, held on November 29 and 30, 1984, served to review the SPARTAN 203 requirements and to address and accelerate the baselining of the SPARTAN 203 PIP annexes. The SPARTAN 101 mission, flown on STS 51-G, was the baseline for SPARTAN 203. The second SPARTAN POWG was conducted on August 20 and 21, 1985, where the details of the operations aspects of the SPARTAN mission were reviewed and some configuration details were decided (such as the color coding of the reflectors, etc.). Final details of the FDF procedures continued in development up through the FOR. The exact techniques and formats for programming the SPARTAN microprocessor and for performing the SPARTAN "in-the-bay" mission were worked out in several informal meetings among the crew, the SPARTAN engineers, and the flight controllers at JSC.

The small number of Flight Techniques and Payload Operations Working Group meetings dedicated to STS 51-L reflected the generally high level of maturity of the techniques and procedures that were planned for STS 51-L. All the TDRS-related procedures had been baselined from earlier missions. The SPARTAN-Halley procedures were baselined from standard deploy and rendezvous techniques also flown on earlier missions, but with the SPARTAN-Halley unique requirements folded in. None of the middeck experiments required any new Orbiter specific procedures to support their conduct; however, the payloads themselves had their own specific procedures. The ascent and entry procedures were all standardized procedures with STS 51-L flight-specific performance figures.

4. Training

The crew completed all required training for STS 51-L. Table 4 lists the planned and actual hours spent in both crew training and integrated simulations. These hours do not reflect self-study hours (i.e., workbook, etc.). Higher than required hours indicates that a lesson may have taken longer than planned or that the crewmember repeated the lesson for review. All required lessons were completed. Less than required hours does not indicate omission of lessons. Rather, it indicates a lesson was completed in less time than planned.

All of the NASA crewmembers, except for Michael Smith, had previously flown a Space Shuttle mission. Michael Smith had started the training cycle with the STS 51-C crew when he was to be a replacement for a crewmember who had a possible physical problem. However, STS 51-L was his first flight.

The crew started their Single Systems Trainer (SST) training at L-37 weeks. Generic Shuttle Mission Simulator (SMS) standalone training started at L-36 weeks, and flight-specific SMS standalone training started at L-9 weeks. The distribution of the crew's training workload from L-9 weeks to launch is shown in table 5, which also breaks the training workload down into formal (scheduled) training in the SMS and other simulators and informal (unscheduled) training and also includes Shuttle training aircraft (STA) flying hours in parentheses.

Integrated training allows the crew to train with the flight controllers in the Mission Control Center (MCC) and in remote control centers. The SMS generates the telemetry for the control centers just as the real Orbiter does. The integrated training for STS 51-L was divided into ascent and entry training, which was run with the ascent and entry teams in the MCC, and on-orbit simulations, which were run with the flight control team that would be on duty during the portion of the flight being simulated. The orbit simulations included three TDRS deploy simulations, one SPARTAN deploy simulation, and two SPARTAN rendezvous simulations. Also included in the orbit simulations was a "systems" simulation for the MCC planning team and a deorbit prep and entry simulation for the entry MCC team. The TDRS flight control team at the White Sands Ground Terminal (WSGT) in Las Cruces, New Mexico, and the IUS flight control team at the Air Force Satellite Control Facility (AFSCF) in Sunnyvale, California, participated in all three TDRS deploy integrated simulations (which are referred to as joint integrated simulations (JIS's) when remote sites participate). The SPARTAN mission management and engineering support personnel were present in the MCC and participated in all SPARTAN integrated simulations. Table 6 summarizes the integrated simulations (including JIS's) for STS 51-L.

The launch date slips for STS 61-C became a scheduling factor for the integrated simulations for STS 51-L. The STS 61-C launch pushed a bow wave of STS 51-L terminal countdown demonstration test (TCDT) and cargo end-to-end (ETE) testing activities at NASA Kennedy Space Center (KSC); these activities required STS 51-L prime crew and/or MCC resources and.....

---

---

[J17] ....thereby constrained the time at which integrated simulations could be conducted. The STS 51-L training schedule was changed several times during the last 6 weeks prior to launch due to the launch slips of STS 61-C and the desire to suspend simulations between the Christmas and New Year holidays. Since STS 61-C slipped after the holidays, STS 51-L simulations were rescheduled, but never canceled, to either stay ahead of the STS 61-C bow wave or to fill in behind as STS 61-C continued to slip. The final impact of the STS 61-C launch slips on STS 51-L training was a compression of the spacing between the dynamic phase (ascent and entry) simulations during the last 2 weeks before flight. All the on-orbit simulations were accomplished with typical spacing between the simulations.

The training for the IUS flight control teams at the AFSCF consisted of standalone simulations (AFSCF only), intercenter exercises with the TDRS team at the WSGT, and JIS's with WSGT. JSC, and the crew. The TDRS flight control teams completed the same types of simulations at their facility at the WSGT. A summary of the training planned and complete d at the AFSCF and the WSGT is included in table 7.

Even though slips in the flight production process caused flight specific training to start later than planned, the crew and the flight control teams at all three control centers completed all planned training for STS 51-L and several crewmembers actually completed more than was planned. The effect of the STS 61-C launch slips was to compress the time available for some of the later ascent and entry simulations, but no training time was lost and all requirements were met. The flight crew preparations for STS 51-L were typical and satisfactory and had no effect on the accident.

5. Launch Site Flow

The KSC Launch Site Flow Review, originally scheduled for October 15, 1985, was slipped to October 16, 1985. Its purpose was to baseline the launch site flow activities. Several Orbiter modifications were incorporated into the flow, and three pieces of new/modified flight crew equipment were identified for monitoring to avoid any potential impact to KSC. The Solid Rocket Booster (SRB) history was reviewed, noting all hardware had been flown or used in major ground tests at least once.

KSC's planning for Orbiter Processing Facility (OPF) and pad operations is documented as an "operations assessment." The portions of the assessment supported by the Space Shuttle operations community are shown in figure 4, together with key flow milestones.

Noteworthy payload-related activities in the flow consist of SPARTAN 203 installation into the payload bay on December 9, 1983 (on schedule), and the Interface Verification Test (IVT) on December 10, 1985. Significant IUS/TDRS activities consisted of IUS/TDRS installation into the payload bay on January 5, 1986, with IUS/TDRS IVT being accomplished on January 10 and the cargo ETE test on January 11, 1986. These last activities had to wait until activities associated with STS 61-C launch preparation and the TCDT for STS 51-L were completed. The vehicles were found to be in excellent operating order, as were the control facilities and their interfaces.

The TCDT for STS 51-L, using operations and maintenance instruction (OMI) S0017, was conducted on January 7 and 8, 1986. The launch count for STS 61-C caused some inconvenience for the STS 51-L crew since the crew quarters and other facilities were being used by the STS 61-C crew. Workarounds for these problems were found, and the TCDT went smoothly and provided the crew with an excellent rehearsal of most launch countdown activities.

The mission operations participation in the launch site flow activities was straight-forward and typical of the support provided for similar missions. The schedule for the flow was affected by the STS 61-C launch slips, and eventually affected the launch date, but all flow activity was completed or waivered.

6. Flight Readiness Review

The STS 51-L level I FRR was conducted on January 15, 1986. The agenda consisted of the following:

Agenda items 4 through 8 addressed the flight readiness of the hardware, with all areas confirming that they were ready to fly pending any work still scheduled for completion. Agenda items 2 and 3 addressed the topics most pertinent to Mission Operations Flight Readiness and are the only items discussed in this report.

In presenting item 2, the lead Flight Director, Brock R. Stone, reviewed the mission, discussed the launch window, and presented the Flight Readiness Statements for Mission Operations and the Communications and Data Network. The launch window was a composite of Orbiter, IUS/TDRS, and SPARTAN requirements. Since launch windows are designed to satisfy payload requirements, as manifested payloads were changed the STS 51-L launch time was changed to accommodate mission requirements. The STS 51-L launch originally was scheduled for a morning liftoff. When SPARTAN-Halley was manifested, the launch Window was changed to afternoon.

Launch windows are generally determined by the launch and landing lighting constraints imposed by the Orbiter for the nominal end of mission and the various abort modes, and by the flight-specific requirements imposed by the payload being launched. The Orbiter requirement for a lighted abort-once-around (AOA) landing at Edwards Air Force Base (EAFB) was initially the only lighting constraint. All other landings could be made at night because of the landing aids available at KSC for return to launch site (RTLS and end of mission) and at the primary TAL site, Dakar, Senegal. However, the only available weather alternate to Dakar for a TAL abort was Casablanca, Morocco, which was not equipped for night landings and. therefore, was only available during daylight.

The strategy for determining the launch window for STS 51-L was designed to satisfy SPARTAN-Halley requirements by using an afternoon launch time, at the expense of giving up the TAL weather alternate at Casablanca (because of darkness there), until such time as the SPARTAN-Halley requirements could no longer be met. After that date, the launch time would be moved to the morning in order to regain the TAL weather alternate site. The IUS/TDRS requirements were met for this entire range of launch times in question and were not a factor.

The duration of the window was three hours, which was the maximum allowable time for the crew to remain strapped into their seats during unplanned holds.

The SPARTAN-Halley requirements were to provide at least 90 seconds per orbit of occulted viewing time of Halley's comet. This is the time in each orbit that the comet would still be in view while the Earth occulted the Sun. If this requirement could not be met, the SPARTAN-Halley would still be able to see the comet but the glare from the Sun could have compromised the quality of their data. Because of the comet's motion, the occulted time available at deploy was greater than that available 45 hours later when the SPARTAN was to be retrieved.

The afternoon window was anchored in time by specifying when it would close, and then having it open 3 hours earlier. The closing [J18] time was set as 15 minutes after sunset at the AOA site at EAFB. If the Space Shuttle was launched at the opening of this window, the SPARTAN would not receive the full 90 seconds of occulted time each revolution at retrieve (it would have started at greater than 90 seconds at deploy and, because of the comet's motion, decreased throughout the 45 hour free-flyer mission). The concession was made that if all systems were go at the opening of the window, and were projected to remain that way (i.e., no weather problems closing in), then the lift-off would be held until the 90 seconds at retrieve line was met.

The afternoon launch window required by SPARTAN resulted in a nighttime TAL landing-. This was acceptable at Dakar, Senegal, since Dakar was equipped with a microwave landing system (NILS) and lighted landing visual aids. However, during January, an extended period of unacceptable visibility conditions at Dakar, due to blowing dust, raised major concerns about possible launch delays while waiting for Dakar weather to clear. STS 51-L could not reach the normal TAL weather alternate site at Moron, Spain, because its distance exceeded 51-L abort performance capability. Accordingly, expedited action was taken to implement an alternate TAL site at Casablanca, Morocco. However, since the night landing provisions required by the Space Shuttle were not available there, the site could only be used for launches with daylight TAL landings.

As the launch date became later in the month, the window that allowed SPARTAN to have 90 seconds occulted time decreased to zero. After this date, there was. no reason to still give up the TAL weather alternate site and the launch time was moved earlier in the day to regain Casablanca as the backup TAL site.

So, the strategy initially accepted the risk of delayed launches if there was a wait required for Dakar to clear, in order to ensure that SPARTAN data on Halley's comet was not degraded. However, once the SPARTAN requirement could not be met, then the risk of launch delays possible with no TAL weather alternate available caused the launch time to be adjusted earlier to make Casablanca lighted and, therefore, available. The same technique for determining the end of the morning window was used (i.e., sunset plus 15 minutes) and for the opening of the window (i.e., 3 hours earlier than it closed). The planned date for shifting from the afternoon window to the morning window was to be January 28, 1986.

The morning and afternoon windows were grouped into primary windows and secondary windows. The primary windows were the series of windows from January 25 through January 30, 1986, that the above described strategy defined. The secondary windows were the windows defined by Casablanca lighting during the days that the SPARTAN-Halley requirements were being honored, and the latest lighted AOA when the lighted TAL site was the driver.

Figure 5 lists the primary and secondary launch windows and depicts the launch windows in graphic form.

Mr. L. G. Williams presented agenda item 3, reviewing the Cargo Integration and Payload Safety area, including an assessment of systems margins. No open issues were identified. In reviewing the performance summary, Mr. Williams identified a performance margin of 214 pounds less than the 3( margin with a launch probability of 92 percent. It was pointed out that this was the first launch from pad 39B, and the only open work remaining for Systems Integration was to complete the installation of the middeck payload lockers and to complete the waiver for RTLS and TAL landing weights. The presented performance summary data are listed in figure 6.

Figure 6. STS 51-L FRR Performance Summary Data.

7. L-1 Day Crew Briefing

The L-1 day crew briefing was conducted on January 24, 1986. The standard format was followed for this briefing, with both the KSC launch team and the JSC flight control team addressing each subsystem and covering its status and any operational constraints or procedural workarounds required. The crew was briefed on main engine/orbital maneuvering system (OMS)/reaction control system (RCS) history with no open problems, and also on the data processing system (DPS) and environmental control and life support system (ECLSS). A hydrogen (H₂) tank heater anomaly briefing was given to the crew as was a flow transducer bias for the fuel cell/power reactants storage and delivery system. Neither anomaly impacted the mission. Further, the crew was briefed on flight software, guidance, navigation and control (IGNC), hydraulics (HYD)/ auxiliary power unit (APU), and instrumentation as ready to support. A manipulator positioning mechanism (MPM) stow switch rigging condition was mentioned in the briefing that required a minor procedural workaround for stowing the remote manipulator system (RMS), but had no mission impact. The main propulsion system (MPS) and Space Shuttle main engine (SSME) systems were briefed as nominal. The crew was briefed on an intermittent left RCS crossfeed 3/4/5 talkback, and valve operation was confirmed to be nominal. The right OMS regulator B locked up at the secondary regulator pressure, indicating the failure of the primary regulator. The crew was briefed to close the B regulators after main engine cutoff (MECO) for the remainder of the flight and to use the A regulators. The OMS and RCS propellant loads were confirmed to be as planned before the mission. Specifically, they were 83 percent left and right, with 80 percent loaded in the forward RCS and 100 percent in the aft RCS. The crew was also briefed on the thermal protection system, which was ready for flight. Because of weather exposure at pad B (i.e., the rain protection....

[J20] ....curtains available at pad A were not yet installed at pad B), areas of the lower surface waterproofing had degraded and a second coating of Scotchgard had been applied to the lower surfaces of all four elevons and portions of the lower wing surfaces aft of the main landing gear doors. All parties at the crew's L-1 briefing indicated they were ready for launch and had no issues that would be an impact to the mission.

8. Planned Mission Timeline Summary

STS 51-L was planned for a duration of 6 day, with the I US/TDRS deployed on day 1, the SPARTAN deployed on day 3, and the SPARTAN retrieved on day 5. The STS 51-Lascent phase included an OMS-1 burn after MECO with a second OMS burn at 44 minutes mission elapsed time (MET) to insert the Orbiter into a 153.5 nautical mile high circular orbit in preparation for the IUS/TDRS deploy. After opening the payload bay doors (PLBD's) and configuring the Orbiter for on-orbit operations, the "GO" for staying on orbit was scheduled for approximately 1:40 MET. The remainder of flight day (FD) I consisted of two periods of fairly high activity. The first was from approximately 2:50 MET until 3:45 MET, during which the early checkout activities were performed for the IUS/TDRS.

After a lunch break, an RMS checkout was to be conducted and the second high-activity period started. This second period ran from 7:40 MET until 11:45 MET and consisted of the final predeploy checkout activities for the IUS and the TDRS, the actual deployment, and the postdeployment separation maneuvers. The first sleep period was scheduled to be 8 hours long, starting at 13:15 MET.

Crew wakeup on FD 2 was scheduled at 21:15 MET. Flight day 2 was the backup TDRS deploy clay and, depending on the date of the launch, the CHAMP data takes were scheduled to begin on this day (i.e., after January 28, 1986, the comet and sunset times were too close to be able to perform the CHAMP activities). Also scheduled on FD 2 was the initial teacher in space videotaping and a recircularization burn to return the Orbiter to a 152 nautical mile circular orbit in preparation for the SPARTAN-Halley deploy on FD 3. (The orbit had been made slightly elliptical as a result of the FD 1 separation maneuvers following the IUS/TDRS deploy.)

Flight day 3 consisted of the crew programming the SPARTAN-Halley satellite with data prepared and uplinked to them by the flight controllers in Houston, then the SPARTAN deployment was followed by the separation maneuver away from the SPARTAN by the Orbiter. The separation maneuver set up the Orbiter to drift for 16 revolutions until, at around 90 miles behind the SPARTAN on FD 4, the nominal correction 1 (NC 1) burn, which is a phasing maneuver, was to be performed to start the Orbiter closing with the SPARTAN again. The FD 4 activities, in addition to the NC1 burn done late in the day, consisted of continuing the fluid dynamics experiment started on FD's 2 and 3 on the middeck and of delivering the two live TV lessons by the teacher in space.

After drifting back in toward the SPARTAN for 10 revolutions, the second rendezvous burn, NC2, was scheduled on the morning of FD 5. Two revolutions after NC2, another bum called "TI" (Terminal Phase Initiation) was planned to initiate the terminal phase of the rendezvous and to allow the Orbiter to be flown back to the SPARTAN in order to capture it with the remote manipulator system (RMS) and restow it in the payload bay.

Flight day 6 was dedicated to performing the flight control system (FCS) checkout in preparation for entry day. to perform the RCS hot fire test which exercises all the high priority RCS jets needed for entry that were not used on orbit, and to spend the afternoon performing cabin stowage. A crew news conference also was scheduled, if requested by the Public Affairs Office, just following the lunch period.

Flight day 7 was scheduled to start with crew wakeup at 5 days, 16:30 MET, with the crew starting their deorbit preparations checklist at 5 days, 19:37 MET. This activity included loading the entry flight software, closing the PLBD's, loading the deorbit burn targets, and configuring the Orbiter's controls to fly the reentry. The deorbit burn was scheduled for 5 days, 23:37 MET, and would have resulted in a landing on the 97th orbit at KSC at 6 days and 34 minutes MET on KSC runway 33. An overview of, the projected timeline for the mission is shown in figure 7.

Several backup timelines were developed before the mission that could be used in the event of various anomalies. The first set covered insertion into a less than nominal orbit, such as an abort-to-orbit (ATO) (105 by 105 nautical miles). The recovery plans provided for the most efficient use of the propellant remaining onboard to raise the orbit for the TDRS deploy as high as possible and still have sufficient fuel to recircularize the orbit for SPARTAN deploy, separation, and rendezvous, with a subsequent deorbit to KSC.

Backup timelines for late deploys for the TDRS were published in the CAP, assuming the nominal deploy for a revolution 8 IUS burn was not performed. Deploy opportunities that were 1 and 2 revolutions late were published and carried onboard, as was the timeline for an FD 2 deploy for a revolution 18 IUS burn if all FD 1 attempts were not performed.

The SPARTAN deploy on FD 3 had both a 1 and a 2 revolution late timeline developed but, since the activities were more straightforward, only the nominal was onboard. All that would have been required for the late SPARTAN deploy was to voice up some new programming codes and new deploy times. The rendezvous would have changed for late deploys, but only insofar as when the NCI burn occurred, so the rendezvous would have remained at the same MET (i.e., the late deploy would have shortened the SPARTAN's free-flyer mission time).

Deorbit and landing opportunities at KSC were planned for the nominal +1 and nominal +2 day timeframes in the event weather or systems problems prevented deorbit at the nominal end of mission. One revolution late deorbit opportunities at EAFB were planned as backups to all KSC opportunities.

In case the Orbiter encountered a failure that reduced redundancy in an entry system, a priority flight was planned to perform only the high-priority on-orbit activities and come home early. The TDRS deploy and backup opportunity were on FD's 1 and 2, with SPARTAN deploy on FD 3 and SPARTAN retrieve on FD 5. Deorbit was tentatively planned on FD 6. The ground -rules for determining priority flight and for late deploys and ATO recovery actions were all documented in the flight-specific Flight Rules Annex. The crew carried the CAP onboard with all the backup TDRS deploy timelines in it, and the ground also had available the Operations Support Timeline (OST), which had greatly expanded ground support scheduled activities for all the TDRS primary and backup deploy activities.

9. Findings

a. Changes to the payload manifest required launch slips from the initial early July 1985 date to the final date in January 1986. After the CIR, the primary payload manifest was very stable. However, several changes to the secondary manifest occurred after the L-5 freeze point. With the exception of the addition of the PS's the crew assignment was never changed.

b. Even though there were six changes to the CIR date for STS 51-L, clue primarily to payload manifest changes, the relationship between the final CIR and the January launch date was according to the planned flight preparation template and the final process worked very smoothly.

C. From a production process flow management standpoint, STS 51-L was a fairly typical mission. The most noticeable result of slips in the production process was to delay the start of flight-specific SMS standalone and integrated training.

d. Even though slips in the flight production process caused flight-specific training to start later than planned, the crew....

[J22] ....and the flight control teams at all three control centers completed all planned training for STS 51-L and several crew members actually completed more than was planned. The effect of the STS 61-C launch slips was to compress the time available for some of the later ascent and entry simulations, but no training time was lost and all requirements were met. The flight crew preparations were all satisfactory and had no effect on the accident.

e. The FDF was complete and ready for flight. The number of changes processed late (post-FOR) was well within the system's capability and was primarily due to manifest changes and refinements in the SPARTAN rendezvous and malfunction procedures.

f. The mission operations participation in the launch site flow activities was straight-forward and typical of the support provided for similar missions. All required flow activity was completed.

g. The planned mission did not contain any new techniques or procedures except for the payload unique operations for programming the SPARTAN-Halley computer and the operation of the middeck experiments. All other procedures and techniques had been baselined from previous missions and resulted in a timeline that was well understood and straight-forward to accomplish. Backup timelines had been developed that could be used to respond to various anomalies.

h. The STS 51-L mission was well prepared for, and the flight team was well trained and qualified to execute the flight.

V.B. STS 51-L Mission Operations

Introduction

This portion of the report addresses the activities conducted after the planning and preparation functions had been completed. The general type of support provided by the operations community during the pre-launch countdown and during the portion of the mission actually flown was typical of similar missions flown and did not require any unusual activities.

1. Pre-launch Activities

The launch date for Mission 51-L was postponed three times and slipped once from the baselined date of January 22, 1986.

The first postponement was documented in Flight Definition and Requirements Directive (FDRD) change 126, signed December 23, 1985. This change slipped the date to January 23, 1986, in order to accommodate the final integrated simulation schedule because of the slip in launch date of Space Transportation System (STS) mission 61-C.

On January 22, 1986, the Program Requirements Change Board (PRCB) issued directive number 33567 which initially slipped the launch from January 23 to January 25, but was modified to slip the launch to January 26, 1986, primarily because of NASA Kennedy Space Center (KSC) flow considerations due to the slips in the launch date of STS 61-C.

At this same time, because the weather at Dakar was questionable, the decision was made to go ahead and go to the morning window for the launch attempt on January 26 to pick up Casablanca as the transatlantic abort landing (TAL) site. The two days that the launch had slipped would also help the circadian shift required by the crew. The SPARTAN payload representatives were agreeable with giving up their 90 second occulted time (only available with an afternoon launch) in order to substantially increase the probability of avoiding launch delays due to TAL weather problems.

The third postponement of the launch date occurred during a January 25, 1986, evening Mission Management Team meeting to review the KSC weather forecast. The forecast was for unacceptable weather on January 26, so the early countdown activities which had already started in support of a January 26 launch attempt were terminated.

The fourth change in launch date was a result of the launch attempt and subsequent scrub on January 27, 1986. The launch attempt initially was delayed because of a problem with the removal of the exterior hatch handle used for ground operations of the crew hatch. However, by the time the handle problem was resolved and the hatch was secured, the winds at the KSC landing site used for return to launch site (RTLS) aborts had increased and were exceeding the velocity allowed for crosswinds. Therefore, the launch attempt was scrubbed and replanned for January 28, 1986.

A brief chronology of the mission operations participation in the countdown activities as perceived by the Mission Control Center (MCC) in Houston follows (KSC ice team activities are shown only to provide a reference from a timeline standpoint):

These prelaunch operations were typical in that some delays and problems were encountered and resolved. The operations team's participation in these activities was straight-forward and had no effect on the accident.

2. Post-launch Activities

Following lift-off, all real-time operations were seen in the MCC as nominal up until data were lost at 73 seconds. Only two voice calls, both of which were standard calls, were made by the Houston CAPCOM. The first was an acknowledgment of the commander's (CDR's) call "Roll program" just after tower clear. The second was approximately 65 seconds into the mission to advise Challenger that they were "GO at throttle up" after the Space Shuttle main engines (SSME's) had come back up from being throttled back during the period of max Q. The CDR's acknowledgment of this call was the last voice communication received from the Challenger.

The MCC Contingency Operations Plan was initiated at 1 minute 30 seconds mission elapsed time (MET) in order to capture and record as much data as possible in the MCC.

Following the STS 51-L incident, the following tasks were accomplished by the flight operations team:

a. All mission-related data were secured in accordance with the MCC Contingency Operations Plan. The Network and MCC configurations were frozen as was the JSC Center Computing Facility (CCF) configuration in building 12. The MCC configuration was released at 21:00 Greenwich mean time (GMT) on January 29, 1986. The Network configuration was released at 13:00 GMT on January 29, 1986. The CCF configuration was released at 09:36 GMT on January 29, 1986.

b. All real-time data tape originals were impounded and copied. These copies have been the data sources for all products requested by other investigation teams.

c. All flight controller logs and hardcopies were impounded in J SC building 30, third floor action center. Access is being controlled via Mission Data Request Form (MDRF), and no originals have been allowed to leave the room. However, copies of data were made and removed.

d. An inventory of all impounded data was provided to the MER's central data facility.

e. A copy of each ascent team member's statement of the accident was provided to the MER for review.

f. All STS 51-L Flight Data File (FDF) change and verification records were impounded. The backup Flight Data File was impounded at KSC.

g. The JSC command history, starting with activation of the Space Shuttle communications system, was reviewed.

h. A telemetry and trajectory reconstruction of lift-off through the event was done in the MCC on January 29 and 30, 1986, by a second ascent team. A mission operations computer (MOC) checkpoint was established for trajectory analysis that picks up at L-5 minutes.

i. All flight control disciplines reviewed the ascent data for ground or crew reconfiguration of the vehicle from lift-off through the incident.

j. All training records of both the flightcrew and the flight control team were reviewed.

Playbacks of MCC data from the STS 51-L launch were analyzed by a second ascent flight control team on January 29 and January 30, 1986. The playbacks used various sources and synchronization processing. By using minor frame validation, loss of signal (LOS) was extended from 1 minute 11 seconds to I minute 13 seconds. No trajectory processing was available for the seven playbacks on January 29, but two playbacks were accomplished on January 30 with active trajectory processing. A checkpoint was established for trajectory analysis that picks up at L-5 minutes for future use, if necessary.

The results of the data playbacks on January 29 and 30 confirmed that the STS 51-L ascent flight control team had no indication of an impending catastrophic failure. The observations made by the ascent team reviewing the data playbacks were provided to the Failure Analysis Team and also included in the Flight Operations Team's Summary Report.

The chamber pressure difference between left and right Solid Rocket Boosters (SRB's) was within a tolerance range of that observed on previous missions until approximately 10 seconds before LOS. At this point, the left SRB continued to increase thrust as expected but the right SRB began increasing thrust at a degraded rate. At 6 seconds before LOS, the right SRB thrust was no longer increasing. Given that the operator has a large [J24] amount of digital data to review, it is reasonable to conclude that such small deviations would not be noted in so short a timespan, Most importantly, there is no reason to monitor for thrust differences in this time period because there is no acceptable procedural option that can be safely implemented while the SRB's are thrusting.

The Flight Operations Team published a Summary Report, dated February 18, 1986. The report included a summary of the team's postflight analysis efforts, statements from all flight controllers in the Mission Control Center, an impounded data inventor), list, and the findings of the Flight Control Team as of the date of the report.

After the STS 51-L accident, the International Business Machines (IBM) primary avionics software system (PASS) flight software team conducted a software audit and data analysis which confirmed that the STS 51-L flight software performed nominally and in accordance with system requirements throughout the actual prelaunch and ascent flight sequences.

The post-STS 51-L accident audits did reveal two discrepancies in the expected values of constants (K-loads) that define the external tank (ET) separation body rate inhibit limits and the fast separation (Fast Sep) liquid hydrogen prevalve close delay timer. These K-load discrepancies had no effect on the STS 51-L accident and will be corrected before the next flight (refer to appendix E of this document).

In summary, the STS 51-L flight software performed nominally and was not a contributing factor to the accident.

3. STS 51-L Abort Modes

The Space Shuttle system design contains no capability to safely accomplish a contingency abort while the SRB's are thrusting. There is no capability to physically separate the SRB's from the stack while SRB's are thrusting. Although the Orbiter can be separated from the external tank (ET) during SRB thrusting, this action is not survivable.

System design precludes the capability to jettison the RB's until SRB burnout has occurred. The only information with regard to SRB chamber pressure available to the crew is a message "P_c < 50" (indicating both SRB chamber pressures less than 50 psi) on a cathode-ray tube (CRT) display, which indicates SRB burnout and that SRB separation is imminent. Should the flight computers not detect "P_c < 50", SRB separation is delayed until 2 minutes 15 seconds MET to guarantee that SRB burnout actually has occurred. Separation then will be commanded if vehicle rates and dynamic pressure are within limits. The only function that can be accomplished by the crew is to manually override the rate and dynamic pressure check and cause SRB separation. Three SRB chamber pressures from each SRB are displayed at 1 sample/sec in the MCC. The data are used to relay to the crew whether a delayed SRB separation can be expected because of instrumentation failures.

System design does allow Orbiter separation from the ET while SRB's are thrusting. However, SRB separation from the ET does not occur. From ET separation initiation the system was designed to take 3.4 seconds until the Orbiter physically separates from the ET to allow main engine shutdown, engine prevalve closure, and disconnect valve closure. Past studies indicate that the Orbiter would not structurally survive an attempted Orbiter separation from the ET while the SRB's are thrusting. These studies show the Orbiter would rotate about the aft attach points and wing structural failure would occur. Additionally, disconnect valve rupture could allow explosive mixing of cryogenic propellants with spraying into the aft Orbiter structure and probable disintegration of the ET. Current use of this capability is limited to after SRB burnout for multiple main engine failures. Thus, for the mission STS 51-L failure, no survivable abort options were available.

After SRB separation, at approximately 120 seconds after liftoff, several intact abort modes were available to STS 51-L. An intact abort consists of a controlled landing on a runway. The first abort mode available would have been a Return to Launch Site (RTLS) abort. In this abort mode, flight is continued downrange in order to burn excess main engine propellant until the Orbiter and the ET can be turned around and flown back to a point near the Florida coast where the engines can be shut down and the Orbiter, after separating from the empty ET, can glide back to the Shuttle Landing Facility (SLF) at KSC. At 231 seconds after lift-off, the downrange velocity of the Orbiter would have been too great to enable flyback to KSC; and the next mode to be used, if needed, would have been a TAL abort. This mode covers the period when RTLS is no longer available, but there is not enough performance to make it either once around to Edwards or to continue on to a low orbit.

A TAL abort allows an intact landing at the TAL site chosen. For STS 51-L, the TAL site was Dakar, Senegal, with a single SSME failure prior to the "single engine" call, and with two engine failures after the call. The TAL and RTLS abort modes overlap for a brief period of time. The current ascent Flight Rules normally would have the crew perform RTLS rather than TAL during the period they overlap.

At 320 seconds after lift-off, STS 51-L would have achieved enough performance to be able to continue on to main engine cutoff (MECO) targets with a single engine failure and have at least enough performance to accomplish an abort-once-around (AOA). An AOA would have had STS 51-L deorbit on its first orbit and land at Edwards Air Force Base. At 427 seconds into AOA flight, STS 51-L would have been able to sustain two SSME failures and still make an AOA. Again, the abort modes overlap, this time between TAL and AOA. The current Flight Rules favor AOA over TAL. Once enough performance existed to enable continuing on into a low, but safe, orbit, the choice between performing an AOA back to Edwards or performing a more favored abort mode known as abort-to-orbit (ATO) would be made. This decision, made after MECO, depends on when the engine failures occurred and how great the loss of performance was. This performance loss is measured as an "underspeed" below the velocity required to insert the Orbiter into a 105 by 105 nautical mile orbit. If the Orbiter had enough propellant to make up the underspeed and still be able to deorbit later, the decision is normally to perform the ATO. After the ATO is performed, the remaining propellant onboard is again evaluated to see whether the orbit can be raised further, still keeping enough propellant to deorbit and also to perform the on-orbit operations required during the mission.

A graphic representation of the intact abort modes available to STS 51-L is shown in figure 1.

Early abort mode capability is based on a certain period of time, at the beginning of the abort mode, in which only a single SSME fails. For cases in which two, or all three SSME's fail before achieving single engine capability, an intact abort may not be possible. In this case, a contingency abort would occur. Contingency aborts are always based on the assumption that two or three SSME's have failed, cannot be implemented before normal SRB jettison (same as intact abort), and usually result in a water landing or ditching. The operations community's general attitude towards ditching is that it does not have a high probability of crew survival.

4. Range Safety

The event timeline of the STS 51-L flight shows that data were lost at 73.6 seconds, the vehicle breakup showed on the Range Safety displays at 75 seconds, the range safety switch (RSS) was armed at 102 seconds, and the destruct command was sent at 107 seconds. The key to an analysis of Range Safety actions on STS 51-L is the time of SRB no longer endanger (NLE). SRB NLE is a Range term that signifies that point in ascent at which, under certain assumptions, a free-flying SRB can no longer endanger a populated landmass. The critical assumption in the computation of SRB NLE time is that the SRB would tumble after separation....

[J26] ....under this a assumption, the STS 51-L NLE time was 59 seconds. The Flight Rule regarding this case states that the Range Safety Officer (RSO) will initiate flight termination action after SRB NLE only if a flight termination line is violated.

When the destruct command was sent during STS 51-L, the flight was beyond the SRB NLE time and no flight termination line was violated. The rationale for the decision to destruct was that the RSO had video coverage of the SRB's and had clearly observed they were not tumbling, thus undermining the key assumption in the SRB NLE computation and invalidating the Flight Rule. Without positive confirmation that both SRB's were being tracked and were headed downrange, the destruct action was deemed appropriate. Had video coverage not been available, no Range Safety action would have been taken.

In light of the circumstances cited above, the actions of the RSO were appropriate and the range safety system destruct of the SRB's did not contribute to the accident (refer to app. A)

5. Findings

a. The pre-launch activities conducted by the operations teams were typical in that some delays and problems were encountered and resolved. The operations team's participation in these activities was straight-forward and had no effect on the accident.

b. The results of the data playbacks on January 29 and 30 confirmed that the STS 31-L ascent flight control team had no indication of an impending catastrophic failure.

c. The STS 31-L flight software performed nominally and was not a contributing factor to the accident.

d. For the mission STS 51-L failure, no survivable abort options were available.

e. The actions of the RSO were appropriate, and the range safety system destruct of the SRB's did not contribute to the accident.

V.C. Mission Planning

Introduction

This report contains a discussion of training, flight procedures, flight software ascent and entry envelope expansion, payload safety, and operational maintenance and inspection. Each subject was investigated to identify and highlight any problems relating to safely preparing for and executing the scheduled flight rate.

In spite of limited resources and increasing perturbations to the planning process, 1985 was a year of significant achievement. Although only 9 flights were flown, planning for effectively 12 flights was accomplished due to remanifesting. Significant mission redesigns were accomplished to work around the tracking and data relay satellite system (TDRSS) battery failures and the SYNCOM IV-3 failure and subsequent repair. The system was operating at nearly maximum capacity. Indications are that the milestones for preparation for the 1986 flight manifest could not have been achieved. The combination of increased flight rate, lack of adequate facility and skilled manpower reserve, and production development problems precluded recovery of these milestones. Findings of problems pertaining to the aspects of mission planning investigated are summarized in the final section.

It was found that crew training is evolving towards an efficient, sound process; flight procedures are mature and the number of changes per flight is decreasing; and except for the Centaur upper stage, the payload safety review process is adequate, rigorous, and effectively works issues at all levels of NASA management.

1. Training

Training is the process of preparing National Space Transportation System (NSTS) flight crews and flight controllers to carry out an NSTS mission. The training is accomplished through the use of workbooks, computer aided instruction, briefings, single system trainers, Shuttle training aircraft (STA) and the Shuttle Mission Simulator (SMS). The SMS is used both for standalone and integrated training. Integrated simulations provide training for both the crew and flight controllers. Integrated training is either generic or flight-specific, which implies the use of a training software load for an upcoming mission with the crew and flight control teams assigned to that mission. This report will focus on the two main aspects of crew training that generated the findings summarized in the final section; i.e., training schedules and crew workload, and training facilities.

a. Schedule and Crew Workload

Currently, crew training is normally scheduled over a 25-week period. From launch minus 25 weeks (L-2 5) to L-11, standalone training is accomplished utilizing training software loads for other missions. At L-11, the flight specific training software load is scheduled to be available for standalone training. From L-11 to L-0, SMS training is accomplished with flight-specific software in a flight configured SMS using flight-specific procedures. If any of the necessary elements is late (software. SMS configuration, procedures), required training is compressed, increasing the number of hours that are scheduled in the last few weeks prior to flight. Figure I shows the number of days prior to launch during which standalone training began for flights Space Transportation System (STS) 41-B through STS 51-L. There is a trend beginning with STS 51-I towards a late start of standalone training. Both STS 61-C and STS 51-L were about 3 weeks late. STS 151-E was going to begin standalone training at least I month late. The trend was projected to continue into the future. Figure 2 shows the number of hours per week scheduled for the crew from missions STS 51-I through STS 51-L. The average begins at about 45 hours per week at L-9 and increases to about 60 hours per week at L-1. This chart includes 10 hours per week for meals and travel. The result is that the hours per day workload of the crew close to flight is large. Reducing the formally scheduled training to the projected levels would aid in lowering the crew workload during this timeframe.

Two factors causing the late delivery of the required training elements are late changes in the mission manifest and flight design and failure of the production system to meet schedule commitments. If the manifest, including secondary payloads and payload specialists with their experiments, could be stabilized at the L-5 month milestone, it would give the training process a chance to proceed according to the template. Late manifest changes initiate unplanned training requirements, especially if the crew assignment is impacted. Launch slips have provided some schedule relief in the past. However, launch slips also cause inefficiency in the training system by necessitating a reallocation of previously scheduled facilities and a replanning of training schedules. The impact of a launch slip affects not only the assigned crew, but the crews immediately following in the training cycle. If one element of the production process fails to meet its schedule, the effect is to serially impact the training schedule until the product is available.

b. Facilities

The main STS training facility is the SMS. It has been a constant source of problems throughout the entire program. Today, the facility computers and equipment are old and obsolete. Plans exist to update the equipment and increase the capacity of the SMS as a teaching machine. However, the funds for those modifications are programmed out over a 10-year period and are minimal.

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, .....

---

[J28] .....there are three ST'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.

4. Ascent Flight Envelope Expansion

For a discussion of the ascent flight envelope, see reference 1. In summary, the approach to verifying the data base and obtaining the data required to remove ascent placards and constraints is conservative. The envelope, in fact, had been reduced as a result of data obtained on previous flights. There are no attempts to reduce margins or pressures to perform dynamic tests that would result in the Space Shuttle flying outside of. the conservatively established ascent envelope. The expansion of the envelope is dependent on obtaining data from flights on an instrumented Orbiter with large planned performance margins. These flights were planned for future missions. In general, the expansion of the ascent flight regime is still in the development phase.

5. Entry Flight Envelope Expansion

A discussion of the entry flight envelope is contained in reference 2. The capability of the Orbiter to perform the entry flight phase is a function of many complex systems, developed by many disciplines, and integrated by members of the disciplines working together, These systems have performed well and the Orbiter capabilities are considered verified to specification requirements (except for landing and rollout system; see appendix B). There are a small number of open issues being actively worked to expand the Space Shuttle entry envelope. These include expanding the system performance capabilities outside of the specification envelope and development of abort propellant dump capabilities to control center of gravity and total landing weight.

In general, Space Shuttle entry capability for flights launched from the Eastern Test Range (ETR) is considered to be operational. For flights from the Western Test Range (WTR), the thermal/structural capabilities continue to be assessed due to high predicted entry temperatures and thermal gradients.

Entry testing continues on a flight-by-flight basis. The approach is conservative, and no pressure has been placed on the system to fly outside of the existing entry flight envelope.

6. Payload Safety

The payload safety process ensures that each payload is safe to fly and that the total integrated cargo complement does not create a hazard. The implementation of this process is consistent with the overall program policy to minimize NSTS involvement in the payload design process; that is, the payload developer is responsible for assurance of safety and verification of compliance with requirements. The safety panel safety and control assessments are based on material presented by the payload developer. The NSTS Safety Review Panel is chaired by the Assistant Manager for Payload Safety of the STS Integration and Operations Office. The responsibilities of the panel include interpreting safety requirements, conducting safety reviews, and assessing payload compliance with NASA Handbook (NHB) 1700.7A.

There is a potential for the appearance of a conflict of interest with the present panel organization. This is caused by its chairman coming from the same organization responsible for integrating payloads. It has been suggested that the Safety, Reliability, and Quality Assurance (SR&QA) Office co-chair the panel with the present chairman to remove the potential conflict. There is no evidence that payload safety has been compromised to date as a result of the current organization.

Generally, the current payload safety process is adequate. A number of past problems have highlighted issues that should be worked. Though the process is rigorous, it occasionally identifies problems for resolution later than desired. This can be due to late changes in the payload design or late inputs from the payload developer. A problem with ARABSAT caused by dealing with a third party rather than the payload contractor has been procedurally corrected. The Payload Safety Panel will always deal directly with the prime payload contractor.

Payload safety documentation needs to be updated. The requirements documents NHB 1700.7 and JSC-18798 contain some conflicting statements. One such inconsistency concerns conducting safety reviews at the contractor's facilities. There is currently no formal statement that authorizes NASA to audit a payload developer to assure compliance with NSTS payload safety requirements,

The Centaur upper stage is the most complicated payload to be integrated into the Orbiter to date. The payload safety process for Centaur, as a result, has been unique and more troublesome than for any other payload.

The Lewis Research Center is responsible for the Centaur vehicle and support equipment. JSC is responsible for integration of the Centaur and support equipment into the Orbiter. Integration of a pressure stabilized cryogenic upper stage into the STS is, without doubt, the most demanding payload integration activity undertaken by the STS. The potential for a catastrophic hazard is present until the Centaur is deployed from the Orbiter. The control of hazards associated with launch aborts with the Centaur onboard the Orbiter drives many of the demanding hardware and software requirements.

Several areas of concern still exist with respect to the Centaur design and/or integration into the STS in that potentially serious single point failures continue to be identified in the present timeframe that were not identified by the Centaur program through the normal safety process. The normal payload safety [J29] process was inadequate in that it allowed single point failures to remain undetected until within months of the planned launch.

Due to the time constraints on this report, an adequate review of Centaur safety processes was not conducted. Such a review should be conducted in the near future.

7. Operational Maintenance and Inspection

A discussion of the Orbiter maintenance and inspection requirements system is contained in appendix D of this report. Requirements for the operational era started to be introduced into the system in early 1985 but are still not fully defined or implemented. The foundation for the system, the Operations and Maintenance Requirements and Specifications Document (OMRSD), provides a sound base on which to build a mature system as future requirements are defined.

Some problems have been encountered while progressing toward a mature system. Implementation of newly defined requirements is not always accomplished according to an agreed upon plan that can be supported by all involved functional areas. Level II also lacks an active closed loop audit system to check the quality of compliance with established requirements. Additionally, there is no baseline postflight turnaround schedule to use as a basis for tracking long-term trends in waivers, deferrals, additions, or deletions to the KSC flow. The current informational data base is, however, being upgraded to provide trend analysis and compliance data to managers so that they will have adequate oversight of the system and up-to-date status of the KSC launch site flow.

The NSTS Program Manger has directed the establishment of an Orbiter Maintenance Inspection Program which will involve all Space Shuttle elements including engineering, subsystem management, hardware spares, and Safety, Reliability, and Quality Assurance (SR&QA). This program is in Phase 1 which will establish a master plan for government/contractor responsibilities. This plan will provide top management visibility, involvement, direction, and approval. This can serve as a vehicle to correct past deficiencies in the SR&QA area which include insufficient data for adequate oversight by Level II managers and a lack of a centralized data system which keeps managers at all levels and locations properly informed.

8. Findings

1. The currently configured and baselined SMS can support a maximum of 12 to 15 flights per year, less than the scheduled 1986 manifest.

2. The current fleet of three STA's can support a maximum of 17 flights per year.

3. Crew workload in the last weeks before flight is high. The problem is aggravated by the late delivery of software or procedures.

4. Secondary payloads and payload specialists should be stabilized at the L-5 month point to ensure that flight procedures, software, safety reviews, and crew training are available and can be accomplished according to plan without an unacceptable effort.

5. Late changes to a mission adversely impact training and procedure development for downstream missions.

6. There is no formal statement that authorizes NASA to audit a payload developer to assure compliance with NSTS payload safety requirements.

7. The normal payload safety process failed to identify potentially serious single point failures in the Centaur upper stage.

8. The Operational Maintenance Inspection Program is immature and does not yet provide Level II with adequate closed loop oversight. It lacks a comprehensive system to track and audit compliance with established requirements.

Conclusion

1. An inspection and maintenance program should be implemented that will ensure flawless performance of critical Space Shuttle hardware into the 21st century.

V.D. National Space Transportation System (NSTS) Mission Operations

Introduction

This report was compiled by a review of working group briefs to the Presidential Commission Panel on Mission Planning and Operations and draft reports in the areas of program base, procedure state, range safety, weather. and NASA Kennedy Space Center (KSC) landing considerations. The Space Transportation System (STS) 51-L Flight Operations Team Summary Report of February 18, 1986. (app. G) was also used to obtain information for this report.

1. Flight Operations Capability

The operations capability demonstrated to date, as shown in table 1, is satisfactory with the thrust of first time activities occurring in the 1983-84 timeframe. The demonstrated capability was scheduled to be further expanded in 1986 with two Centaur flights and the first launch from the Western Test Range (WTR).

[J31] 2. Transitioning to an Operational System

The conclusions drawn in this section are based on an overall assessment of the data contained in multiple areas of this report. The original STS Operations Baseline Operations Plan (BOP), of November 20, 1978, defined required capabilities for the STS system before it was designed. It defined what the meaning of an operational system was at that time. This operational system would fly 6 flights the first year, 15 the second, 24 the third, and by the sixth year a total of 60 flights. To meet this flight rate, turnaround was to be completed in 14 days. The vision of the operational Space Shuttle was clearly much larger than the resource base eventually established to create the real capability.

As the Space Shuttle system was developed, with numerous changes and compromises, a comprehensive set of requirements was developed to ensure the success of a Space Shuttle mission. What evolved from the process in 1981 was a system where the turnaround, flight planning, flight control, and flight training were accomplished with extreme care applied to every detail. This process checked and rechecked everything to ensure its accuracy and was both labor and time intensive. It was slow, but was both appropriate and necessary for a new system still in the developmental phase. After the first series of flights, the system had developed basic plans and templates to accomplish required flight support functions. The challenge was to streamline these so that they could be accomplished more quickly. This goal would be achieved through automation, standardization, and centralized management. Automation included innovations such as development of computer programs to build and check the flight software loads. Standardization would occur in many areas such as flight design where individually tailored flight profiles would be replaced by more standardized ones. But the system still depended on the experts to ensure the data were correct. Finally, all the products generated for direct flight support at JSC (MCC software, flight software, and simulator software) would be controlled by a single manager, the Director of Mission Operations. This reorganization would result in a production-oriented process designed to deliver needed products at the proper time.

The conversion from the previously described developmental phase type of operations to the mature-system type of operations without a compromise in quality was a challenge to the system. It required that experts in all functions carefully analyze their areas for those things that could be standardized and automated. For those areas which could be streamlined, two ingredients were necessary for effective conversion to "the operational mode": expertise on the part of the individuals designing the change and time for them to effectively do their job.

Expertise and time cannot be isolated and analyzed separately because two factors tied them together: the increasing flight rate and the loss of skilled personnel. The increasing flight rate had the highest priority. Obviously, quality products had to be ready to support flights. The process of establishing the flight rate and its associated manifests did not, however, adequately consider whether all functions required to support the final plan could handle it while simultaneously developing the additional capability needed to support an increasing flight rate. This situation was further aggravated by the fact that schedules and budgets which controlled the development of needed facilities, software, and hardware did not support required levels of capability. In the end, whatever time and resources were left after supporting the flight schedule could then be directed toward efforts to become "operational." In other words, it appears that the flight rate was not tied to the ability of the system to support it, but rather the system was reacting to the established flight rate. This situation was a result of the concept of establishing goals the system could not meet in order to attain a maximum number of flights in any given year. In trying to meet those goals, the system was expected to mature. The result, however, was to overstress the system and actually impair efforts to become operational.

At the same time the flight rate was increasing, a variety of' factors were reducing the number of skilled personnel available to deal with it. These included retirements, hiring freezes, transfers to other programs like the Space Station, and transitioning to a single contractor for operations support. This transition eventually would require significant training resources to train the new employees.

An overall view of the flight support process at JSC in January 1986 is one of a reduced capability in terms of qualified personnel, trying to deal with an increasing flight rate, a conversion to a production-oriented system, and a transition to a single operations support contractor. The result of this is a system which in some areas projected the use of all or almost all of its reserve capacity for 1986, indicating inability to meet required production schedules.

In order to develop a fully operational capability, a conscious effort must be made to constrain the flight rate within the capacity of NSTS Program while maintaining reserve resources to develop this operational capability. Additionally, periodic plateaus in the flight rate would allow the system to assess its progress, make necessary adjustments, and make adequate plans for the next incremental increase. Initiatives such as these will allow an orderly transition to the operations era while maintaining the high quality of flight support which is critical to successfully manned spaceflight operations.

In summary, the existing program commitments in January 1986, precluded devoting adequate resources to developing the capability to support an increasing flight rate.

3. Flight Operations Preparedness

Since STS-1, there have been frequent occasions for the mission operations team conducting STS flights to call upon its diverse technical expertise to deal with significant problems in either Orbiter or payload systems. The record of STS flights to date shows that, in all instances leading up to STS 51-L, high levels of operations preparedness were demonstrated by the repeated ability of the mission operations team to conduct successful flights in spite of occasional major failures and anomalies (e.g., two general purpose computer (GPC) failures on STS-9, loss of control of the Solar Maximum Satellite on STS 41-C, dump nozzle freezeups on STS 41-D, and premature engine shutdown on STS 51-F). Flight operations preparedness is directly dependent on the quality of preflight training for mission operations personnel and, although it has been previously acknowledged that training requirements in 1986 and beyond were projected to exceed the capabilities of the system, no indication was found of a degradation in flight operations preparedness.

4. Range Safety Requirements

As currently defined, the Range Safety responsibilities date back to the Webb-McNamara Agreement of 1963 giving responsibility for range safety during NASA flights to the Department of Defense (see app. A, "Range Safety Report").

The most fundamental issue remaining is the philosophical decision of whether to put a destruct system on a manned vehicle. This concept has been debated repeatedly over the years revolving around the tradeoff between voluntary and involuntary risk. This issue is out of scope of this report and will be addressed by NASA/DOD in the future.

5. Mission Operations Safety

The matter of safety has received significant attention since the STS 51-L accident. The subject is very broad in its scope, ranging from prelaunch maintenance/inspection activity through inflight crew activity and management decision making. Here we will only address three issues pertinent to mission operations safety: weather decisions, crew escape systems, and NASA Kennedy Space Center (KSC) landing considerations.

[J32] a. Weather

Weather decisions for launch and landing have been and always will be difficult because of such factors as Orbiter thermal protection system (TPS) damage potential, lightning strike damage potential, wet runway hazards, etc. For launch, the responsibility for the weather call is jointly shared by the Flight Director/JSC, the Launch Director/KSC, and the Launch System Evaluation Advisory Team Chairman/JSC for abort landing site weather, launch and ascent weather, and launch loads and performance respectively. Element project managers are also responsible for advising on potential weather impacts to their respective STS element systems. For landing, primary responsibility for the weather call is with the Flight Director/JSC. Both launch weather launch commit criteria and landing site weather criteria have been developed through an iterative process over the years. They appear to be well-founded but, because of the difficulty in making a short-term weather forecast which will remain valid throughout the launch or landing phase, the ultimate decision remains difficult. Accurate, localized weather forecast capability is needed before the Mission Operations Team relies on anything but overly conservative weather decisions. A review of weather decisions for STS missions 5 through 51-L affirmed that the decisions were conservative. An assessment of the RTLS rain damage conducted by the Engineering Directorate/JSC concluded that flying the Orbiter through rain will cause damage to the tile surface resulting in increased boundary layer and skin friction, drag increase, lift derivative loss (~10 percent), and decrease in vehicle performance (~10 percent). They concluded, however, that there was no loss in control surface effectiveness. A similar assessment for ascent rain damage resulting from ascent through an overcast has not been accomplished, but is planned by the Engineering Directorate/JSC. Although tile damage from rain during the subsonic portion of entry is accepted as a refurbishment issue, insufficient data is available to dismiss it as a safety of flight issue for ascent. It is well established that the KSC weather is highly dynamic and subject to rapid changes and, therefore, in order to provide acceptable KSC landing conditions conservative weather decisions must continue to be made. In addition, the program attitude toward KSC weather phenomenon should continue to be one of extreme caution. Waveoffs for marginal situations should be readily accepted and applauded at all levels of management throughout the program.

For further discussion on weather, refer to appendix B.

b. Crew Escape Systems

The NSTS considered all known methods of providing Orbiter and/or crew recovery from emergency situations during the first stage of ascent flight. Ejection seats and pressure suits were provided for the Orbital Flight Test (OFT) Program, although they afforded limited capability. Additional methods for the post OFT period were either baselined and then deleted or considered and not implemented because of one or a combination of limited utility, technical complexity, lack of reaction time and appropriate cues, costs and schedule, and/or performance and mission objectives impact (see app. C). Because of these factors, the NSTS adopted the philosophy that the reliability of first stage ascent must be assured through conservative design, testing, and certification to preclude time critical failures that prohibit the continuation of flight through SRB burnout. On the other hand, Orbiter avionics software changes were aggressively pursued to enhance survivability for cases beyond the accepted program risk level of Fail-Safe. Many of these proposed software changes were incorporated because of the low cost-to-benefit ratio.

During the Space Shuttle development period, the question of first stage abort provisions was revisited many times by all levels of NASA management from 1973 to 1983 with no change in the philosophy that reliable first stage ascent must be assured. The options available to the program today to enhance crew escape capability from emergency situations appear to be identical to those considered early in the program, with the added complication that implementing major changes, such as escape pods, within the current Orbiter design would not be possible. Ejection seats limit the crew size and, thereby, the utility of the Space Shuttle. Furthermore, they provide very limited increase in survivability for the total range of potential first stage failures, Bailout options offer an escape path for the crew in the contingency abort cases that result in water ditching, but utilization in first stage contingency situations is impossible.

First stage intact Orbiter abort options require major changes in the Space Shuttle system and would result in major performance impacts. Also, these options would not recover the Orbiter for all failures throughout the first stage. An escape pod can offer an opportunity for crew escape at all altitudes during first stage contingency situations if the pod is not damaged to the point that it cannot function. The implications of implementation are a significant redesign of the Orbiter and major loss of payload capacity. An escape pod with termination of SRB thrust theoretically offers the widest range of crew escape options. However, the implications of full implementation are development of SRB thrust termination, redesign of the forward SRBET attach fittings, design and certification of a technique for quick shutdown of the SSMFs, significant redesign of the Orbiter, and major loss of payload capability. All of the possible first stage crew escape enhancements would require a method to detect the impending failure in time to take successful action, a requirement that currently has no practical solutions for all the possible scenarios.

In summary, the NSTS must maintain and be successful with its previous first stage design philosophy of ensuring first stage reliability through design and certification to preclude failures. However, the program should evaluate the options and utility of providing crew escape systems and augmenting Orbiter abort modes for failures such as loss of two SSME's.

c. KSC Landing Considerations

Perhaps no other question in the entire NSTS commands more emotional discussion than the issue of KSC end-of-mission (EOM) landings.

The primary reasons for landing at KSC are: avoiding the time required to transport the Orbiter from EAFB, avoiding Orbiter exposure to risks associated with handling and transporting from EAFB to KSC, maintaining efficient utilization of Orbiter processing personnel during the turnaround operations and avoiding up to a SIM cost for each EAFB turnaround operation. On the other hand, EAFB provides additional margins for remote failures and adverse weather conditions that makes it an attractive landing base. Significant findings discussed in appendix B are: at the time of the STS 51-L launch, KSC landings did not constitute an unreasonable safety of flight risk based on known, credible failures; however, program need for KSC landings and related system performance criteria should be reevaluated. Routine KSC landings should continue only after such reevaluation is complete and resultant criteria are satisfied. The STS Program must have multiple landing sites available for EOM landings to protect against weather violations at the planned landing site; KSC should continue to be supported as one of the alternate EOM landing locations. Current landing and deceleration systems have not demonstrated an adequate margin for routine KSC and TAL abort operations.

For a detailed discussion of findings on KSC landing considerations, refer to appendix B.

6. Astronaut Involvement in the Space Shuttle Program

An area of interest since the Challenger accident has been the level of astronaut involvement in the Space Shuttle Program. This subject was discussed at a public hearing of the Presidential Commission on the Space Shuttle Challenger Accident. Review of the subject has shown that astronauts are involved in a variety of [J33] program activities that include assignment to KSC to support test and checkout of the spacecraft and payloads, to the Shuttle Avionics Integration Laboratory where software development and verification testing is accomplished, and to various engineering design and development simulations. They participate in mission development activities and serve as CAPCOM's in the Mission Control Center. In addition, the flightcrew is represented at all the various boards and groups that provide input to the Space Shuttle Program Management. The Astronaut Office plays a significant roll in all activities associated with development, flight preparation, and flight execution, and they, or their management, are members of all major decision-making boards and panels. For a more comprehensive discussion of this subject, see appendix F.

7. Findings

1. The operations capability demonstrated to date is satisfactory, although it falls short of the mature operations goals previously established.

2. The flight support process at JSC in January 1986, was one of reduced capability in terms of qualified personnel, trying to deal with an increasing flight rate, a conversion to a production oriented system, and a transition to an operations support contractor.

3. The existing program commitment in January 1986, precluded devoting adequate resources to developing the capability to support an increasing flight rate.

4. A high level of operations preparedness was demonstrated by repeated ability of the Mission Operations Team to conduct successful flights in spite of periodic major anomalies (STS-9, STS 41-C. STS 41-D, STS 51-F).

5. The most fundamental RSS issue remaining is the philosophical decision of whether to put a destruct system on a manned vehicle. This issue is out of the scope of this report and will be addressed by NASA/DOD in the future.

6. Both launch weather launch commit criteria and landing site weather criteria have been developed through an iterative process over the years and appear to be well-founded.

7. KSC weather is dynamic and subject to rapid changes; therefore, conservative weather decisions must continue to be made.

8. The program considered crew escape numerous times but, because of limited utility, technical complexity, cost, schedule, and performance impacts, no systems were implemented.

9. At the time of the STS 51-L launch, KSC landings did not constitute an unreasonable safety or flight risk based on known credible failures.

10. Statistical weather and forecasting uncertainties have resulted in several weather waveoffs and dictate a need for multiple landing sites for end of mission.

11. The current landing and deceleration systems have not demonstrated an adequate margin for routine KSC and TAL abort operations.

12. The Astronaut Office plays a significant role in all activities associated with development, flight preparation, and flight execution, and they or their management are members of all major decision-making boards and panels.

8. Conclusions

1. The NSTS Program should make a conscious effort to constrain the flight rate within the capacity of the NSTS Program while maintaining reserve resources to develop a fully operational capability.

2. Accurate, localized weather forecast capability is needed before the Mission Operations Team relies on anything but overly conservative weather decisions.

3. The NSTS must maintain and be successful with its previous first stage design philosophy of ensuring first stage reliability through design and certification to preclude failures.

4. The INSTS Program should evaluate the options and utility of providing crew escape systems and augmenting Orbiter abort modes for failures such as loss of two SSME's.

5. NSTS Program need for KSC landings and related system performance criteria should be reevaluated; routine KSC landings should continue only after such reevaluation is complete and resultant criteria are satisfied.

6. KSC should continue to be supported as one of the alternate EOM landing locations.

V.E. NSTS Flight Rate and Flight Scheduling

Introduction

This section of the report includes discussions of the National Space Transportation System (NSTS) manifesting process, flight preparation process, and major milestone history, and an assessment of the workload of Mission Operations Directorate (MCID) personnel involved in mission support.

1. The Manifesting Process

The manifesting process begins at NASA Headquarters with the issuance of two pieces of information: a candidate manifest and a set of groundrules (or priorities) (refer to fig. 1). Nearly all this information is transmitted by way of the Flight Assignment Working Group (FAWG) to the various organizations. The initial assessment performed at NASA's Johnson Space Center (JSC) is shown in the box entitled "Integrated Evaluation" and in the dotted feedback line to Headquarters. This JSC feedback is used by Headquarters in developing the manifest. Upon receipt of a preliminary manifest from Headquarters, the FAWG center performs an evaluation of the manifest and prepares recommendations for transmittal back to Headquarters.

The Space Shuttle Payload Flight Assignment document, hereafter referred to as "Headquarters manifest," is the instrument which shows NASA's planned Space Transportation System (STS) operations for the next several years. The JSC level II instrument directing the implementation of specific STS missions for the next 15 months is the Flight Definition and Requirements Directive (FDRD). Both of these documents typically include the following:

• Flight number
• Launch date
• Orbiter vehicle (OV)
• Major payloads
• Middeck payloads
• Altitude
• Inclination
• Crew size
• Flight duration

The FDRD is maintained by the NSTS Program Manager's Program Requirements Control Board (PRCB). The Headquarters manifest and the FDRD are kept in synchronization at the JSC Mission Integration Office by:

1. Providing a Chairman for the FAWG

2. Presenting manifest changes to the FDRD for the consideration of the NSTS Program Manager.

As soon as any divergence develops between the manifest and the FDRD, the JSC Mission Integration Office takes appropriate steps to resolve the differences.

The manifesting process is a continuous operation responding to factors that cause a need for change. The wide range of causative factors are discussed later in this report. In no case is manifesting a spontaneous action; some conditions change and set a remanifesting activity in motion. Briefly, the manifesting process consists of the following:

• Customers submit flight requests to NASA Headquarters.

---

• [J35] NASA Headquarters develops proposed cargo mixes and up dates the preliminary manifest.
• The FAWG continually evaluates the manifest and recommends changes as required.
• "Official manifests" are published and distributed, although not on a regular schedule.
• 15 months before launch, flights are baselined in the FDRD, which directs all STS hardware. software, training. and flight planning activities.
• Changes to the FDRD must be approved by the Program Requirements Control Board, chaired by the STS Program Manager.

The FAWG was created by NASA Headquarters in October 1977 to be "responsible for the development and maintenance of an STS Flight Assignment Baseline as a utilization and planning function for STS Operations." The membership of the FAWG has always consisted of representatives from the various NASA, centers and the Department of Defense (DOD). Figure 1 shows the current organizational representation on the FA\VG with a brief characterization of the organization's responsibility. Weekly telecons and scheduled meetings are the primary vehicles for manifesting coordination.

2. The Production Process

The production process for integration hardware (fig. 2), engineering crew timeline, flight design, and crew training begins 15 months before launch (L-15). At this time, a baseline cargo mix is established with the issuance of an FDRD. This directive also provides authority for the cargo compatibility analysis. NASA Headquarters and JSC management in agreement with inputs from other NASA centers initiate this first phase.

A Cargo Integration Review Dry Run (CIRD) is held at JSC 15 weeks later (L-10.9). This meeting is chaired by the STS Program Office and is supported by board members from other key center disciplines. This board baselines the Flight Requirements Document (FRD), which defines the National Space Transportation Systems Program Office (NSTSPO) authorized requirements and objectives for a specific mission. The board also provides a preliminary engineering assessment on interface compatibility. It further provides the authority to begin preparation of the final engineering and conceptual flight design to determine mission feasibility. A mission and crew activity operations assessment is also reviewed and approved. The engineering data are due for final review at the Cargo Integration Review (CIR) to be held 14 weeks later (L-7.7 months).

The CIR is a major NASA-customer review conducted at JSC and chaired by the STS Program Office. Board members of this review are representative of a specific flight's customers, NASA Headquarters, NASA Kennedy Space Center (KSC), JSC, and other involved NASA centers. The board reviews and approves for baselining the following areas and documents: customer requirements, cargo design, Cargo Engineering Data; flight design, Cycle 1; Preliminary Crew Activity Plan and Timelines. Areas reviewed include ground operations flow and payload safety status. As a result of this review, engineering data are approved for release to the launch site for operations support and to the customer for flight preparation.

At L-5.5 months, the final engineering data defining Orbiter/cargo configuration and installation instructions are provided to the customer and the launch site. The launch site then begins preparation of installation instructions.

The final internal Flight Planning and Stowage Review is held at JSC at L-5 months and chaired by the Program Office. The purpose of this review is to (1) finalize all requirements influencing crew activities, (2) update middeck configuration/stowage, and (3) finalize crew compartment configuration drawings.

At 3 months prior to launch (L-3), two major STS reviews are held at JSC and are chaired by the Program Office: the Launch Site Flow Review (LSFR) and the Flight Operation. Review (FOR). The LSFR board members consist of Headquarters, JSC, and other involved NASA centers. They are concerned with statusing engineering and hardware for STS and cargo processing at KSC. Customers, JSC, and involved NASA centers make up the FOR board which allows for customer formal review of final flight operations products.

a. Program Freeze Points

There are three major program freeze points in the production process. In theory, after each of these freeze points, non-mandatory changes (i.e., those for which alternatives exist) to the major design and engineering products or items are not allowed. The disciplines affected by these freeze points comprise integration hardware, engineering, crew timeline, flight design, and crew training (fig. 2).

The first major freeze point in the production process is at L-15 months, at which time the flight is baselined in the FDRD. The baselined items include the launch date, Orbiter to be used, and major payloads to be flown. Design and engineering conducted after the FDRD freeze point is based on this information.

At L-7.7 months, a CIR is held and is the second major freeze point in the production process. During the CIR, among the major design and engineering products that are frozen are the integration hardware design, the Orbiter vehicle configuration, flight design, and software requirements. Further design and engineering conducted after the CIR freeze point is based on these products.

The third major freeze point in the production process is the Flight Planning and Stowage Review and occurs at L-5 months. At this time, the crew activity timeline and the crew compartment configuration, which includes middeck payloads and payload specialist assignments, are frozen. Further design and engineering conducted after the L-5 review freeze point is based on these products.

b. Factors Causing Manifest Changes

Changes to the manifest are a reaction to some stimuli. The stimulus may come from any or all of the following categories:

• Hardware problems
• Customer requests
• Operational constraints
• External factors

When changes occur, the program must choose a response to the problem and accept the consequences of that response. The program has two choices: (1) optimize and facilitate the payload or response to customer needs; or (2) minimize the impact to STS operations and put the problem response outside the production template. If the first option is selected, the consequences will include short-term and/or long-term impacts to the STS. The following paragraphs discuss these consequences.

Hardware problems can cause significant impacts to manifesting. When they occur, usually little can be done except to implement a fix to the problem and to accommodate the system to the consequences. These consequences will often have a long-term rippling effect, as will be shown later.

Customer requests also can cause significant impact on manifesting. These requests, often for a later than scheduled launch date, are made as late as NASA will allow.

Operational constraints impose requirements on STS missions that require remanifesting. Cargo weight growth or Orbiter landing weight can cause an Orbiter assignment to be changed. With each reassignment, accompanying launch date changes to other cargos can occur, and the ripple effect continues.

External factors can cause manifesting impacts. These impacts frequently are associated with changes in the crew size and/or payload specialist assignments.

[J36] c. Major Manifest Revisions for 1985

Collection of the historical manifesting/remanifesting data required research into various documents and areas of responsibility. FDRD changes 14 through 130 were reviewed along with approximately 290 level II change requests from January 1983 through January 1986. The FDRD changes provided the manifest. launch date, and crew assignment data, and a listing of level II Program Requirements Control Board Directives (PRCBD's) authorizing the changes. The level II change requests were reviewed to determine reasons for changes. In many cases, the detailed reasons for changes were not given. In such cases, contact was made with Program Office manifesting personnel and, based on their records, a more definitive reason for change was pursued. Results of this effort provided the basis for the presentation material provided to the Presidential Commission investigation and also a collection of historical data which can be valuable in future manifest planning.

The following manifest changes in the general categories mentioned in section b occurred in 1985:

1. Hardware Problems

• TDRS (cancelled 51-E, added 61-M)
• Syncom (added to 61-C)
• Syncom (removed from 61-C)
• OV-102 late delivery from Palmdale (changed to 51-G. 51-L and 61-A)

2. Customer Requests

• HS-376 (removed from 51-1)
• G-Star (removed from 61-C)
• STC-DBS (removed from 61-E)
• Westar (removed from 61-C)
• STC-DBS (removed from 61-H)
• EOS (removed from 61-B)
• EOS (removed from 61-H)
• Space Telescope (swap with EOM)

3. Operational Constraints

• No launch window for Skynet/Insat combination (61-H)
• Unacceptable structural loads for TDRS/Insat (61-H)
• Landing weight above allowable limits (61-A)
• Landing weight above allowable limits (61-E)
• Landing weight above allowable limits (71-A)
• Landing weight above allowable limits (61-K)

4. External Factors

• Late addition of Senator Garn (51-D)
• Late addition of Congressman Nelson (61-C)
• Late addition of PVTOS experiment (51-1)

A detailed explanation of an example from each of these four categories of manifest changes to illustrate both the immediate impact of the change-cause as well as the downstream effects is given below.

(1) Manifest Changes Due to Hardware Problems

An example of how hardware problems can cause the manifest satellite to change is reflected by the tracking and data relay satellite (TDRS) battery problem experienced during the preparations for STS 51-E. TDRS-B and Telesat had been scheduled for a February 1985 launch on the 51-E mission, and the Orbiter and payloads were already at the launch pad when the battery problem was discovered. Because of the complexity of the problem, it was necessary to roll back from the pad and, in fact, the mission eventually was canceled. Syncom IV-3 and a long duration exposure facility (LDEF) retrieval were scheduled for the next flight. STS 51-D. In order to provide an early launch opportunity for Telesat, the 51-D cargo was changed to Syncom and Telesat, and the LDEF retrieval was deferred. This late change necessitated a minor slip in the 51-D launch date; however, the launch still occurred only 5 weeks after the changes officially were approved.

Once the battery problem was resolved, it was necessary to schedule another launch opportunity for TDRS. As there were !no available flights in the downstream manifest, numerous changes were needed in order to accommodate the new flight, :STS 61-M, in July 1986. First, the launch dates for missions in the last half of 1986 had to be slipped. Insat, which had been assigned to STS 61-1, was moved to 61-M (although it was later moved back for other reasons). Finally, the LDEF retrieve activity was added to STS 61-1.

Most of these changes are illustrated in figures 3 and 4, which are examples of how the manifest changed with time. The top line on each chart shows the last official manifest published before the start of 1985, the August 1984 baseline. The second line on the 1985 schedule shows the flights as they were actually flown. The second line on the 1986 schedule shows the flights planned for that year as they existed before the STS 51-L, mission. These examples illustrate how a single event, such as a hardware problem, can cause the need for a number of changes to the manifest, extending many months into the future.

(2) Manifest Changes Due to Customer Request

Customer requests have caused numerous manifest changes instituted over the last several years. Because off development problems, financial difficulties, or changing market conditions, Space Shuttle customers frequently have notified NASA Headquarters of a desire to change their scheduled launch dates. An example of how this kind of change can affect the manifest is the Westar satellite. Westar originally had been scheduled for STS 61-C in December 1985. Although no formal request was made, as it could have resulted in a penalty fee, it was indicated to NASA Headquarters that a slip to the March 1986 timeframe was desirable. Normally, NASA Headquarters tries to accommodate requests like this in order to maintain good customer relations. As a result, Westar was moved to STS 61-E, replacing a Get-Away Special (GAS) bridge assembly.

As a result of the departure of Westar from the STS 61-C manifest, HS-376 was moved from STS 51-L. The HS-376 is essentially a placeholder for one of the communications satellites returned to Earth on STS 51-A. The plan had been to refurbish one or both of these satellites, sell them to a new customer, and relaunch them on the Space Shuttle. Part of the incentive for a customer to buy these "used" spacecraft was a guaranteed early launch slot. Unfortunately, no customers were found during this time period. As a result, Headquarters delayed the HS-376 launch date. SPARTAN-Halley was moved from STS 61-D to fill the slot created on 51-L. STS 61-D, which included the SLS-l payload, was canceled because of other factors. SPARTA-Halley was designed to take observations of Halley's Comet and needed to fly in the January 1986 timeframe; therefore, the mission was scheduled for that month.

(3) Manifest Changes Due to Operational Constraints

An excellent example of the need to change the manifest because of operational constraints is reflected by the landing weight on STS 61-K. This mission, an Earth Observation Mission (EOM) Spacelab flight, first was planned for OV-102 because of the desire for a high-power, long-duration mission (i.e., only OV-102 has the capability to carry a fifth cryoset to provide extra power). As the payload definition matured, the payload configuration changed from only a long module to a long module plus a mission peculiar experiment support structure (MPESS). This new configuration resulted in a predicted end-of-mission landing weight of approximately 217,000 pounds, significantly above the.....

---

[J38] .....maximum allowable landing weight of 214,000 pounds. Since OV-104 weighs several thousand pounds less than OV-102, switching vehicles was a reasonable solution to this problem. As a result, STS 61-K was changed to OV-104, and STS 61-L was changed to OV-102. Because OV-102 is a heavier vehicle, its lift capability is also reduced; thus, the total payload weight for STS 61-L had to be decreased somewhat. By removing both the global positioning satellite (GPS) (moved to 71-A) and SPARTAN 2 (moved to 71-C), it was possible to add Syncom, which, because of another change, had been bumped from a previous flight.

(4) Manifest Changes Due to External Factors

External factors resulting from the change itself and its side effects have been the cause of a number of manifest changes. For example. Congressman Nelson was added to STS 61-C only 2 months before the scheduled launch. He operated the phase partitioning experiment (PPE), which also was added to that flight at L-2 months. Since seven crewmembers already had been assigned to the flight (five NASA astronauts, a Radio Corporation of America (RCA) payload specialist, and a Hughes payload specialist), one of the crewmembers had to be deleted. Headquarters decided that the Hughes payload specialist should be switched to STS 51-L in January 1986. In addition, the payload specialist's fluid dynamics experiment (FDE) also was moved from 61-C to 51-L. Finally, several middeck experiments already assigned to STS 51-L (ACES, MLR, and three student experiments, were removed to make room for the extra crewman.

d. Manifest Change Impacts

Having discussed the area of changes and their impact on the schedules and other flights, it is appropriate to consider the manner in which NASA copes with such impacts. Emphasis will be given to two major ways of coping that reflect the two major types of efforts involved in the response to the changes. Areas affected by changes are characterized by many "parallel" efforts or by several "serial" efforts.

(1) Parallel Efforts

In the area characterized by parallel efforts, any impacts can be managed by increasing the budget. Additionally, the amount of budget increase required to respond to any remanifests or changes depends heavily on the response time left in the 15-month template (fig. 5(a)). For early changes, those before the CIR, an impact will require a nominal increase in the budget. The effect of later changes, however, requires many more of the parallel efforts and, hence, a larger budget increase in order to achieve the same end result in the reduced response time prior to launch.

Logic dictates that if a change occurs, it will impact the budget. This conclusion leads to the question of whether such a probability is sufficiently high to require budgeting for anticipated changes. To aid in this consideration, a history of the changes that occur each month over a period of 2.5 years is shown in figure 5(b). There is a strong correlation between flight rate and change rate; i.e., more hardware does mean more hardware failures. Therefore, changes are certain, predictable, and can be scoped within a budget.

Further examination of the workload impact (fig. 6) reveals that process delays caused by these changes tend to stack several reviews on top of each other. Reviews, such as CIR's from several flights, which should have been staggered in time sometimes occur almost simultaneously. As these efforts require multiple steps to accomplish the necessary tasks, if too many occur simultaneously, the strain on facilities and personnel resources is tremendous. For short periods of 2 to 3 months in mid-1985 and early 1986, facilities and personnel were being required to perform at roughly twice the budgeted flight rate.

Change rates are tied to the frequency of flights (fig. 5(b)), and late changes make an impact on the STS Integrations and Operations Office's budget. The composite of major payload changes from mission 41-G to 51-L (fig. 7) clearly shows that, although 60 percent of the changes occur by the CIR timeframe, more than half the remaining changes do occur after L-5 months and cause a significant budget and manpower impact (fig. 8(a)).

Middeck and secondary payload changes have a minimal manpower and budget impact when compared to major payloads. However, when the aggregate number and the timeframe into which they are added in the integration process (fig. 8(b)) are considered, they constitute a major distraction from primary operations.

In considering the tasks which are characterized by parallel efforts, Engineering Flight Products generated for the CIR generally are found in this class (fig. 9). These products are generated under a contract that allows for increased budget expenditures as necessary to meet localized high workloads. However, even with this built-in flexibility, the requested changes occasionally come close enough to the reviews that the parallel effort transitions over to a serial effort as facilities and personnel resources are saturated. This impact occurred on 51-D's Delta CIR, 62-A's Delta CIR, and 61-C's CIR, when the products were shipped less than 10 days before the reviews.

(2)Serial Efforts

A serial effort, by contrast, is best exemplified by crew training in simulators, for this training cannot occur until software is available to drive the simulation computers. Yet the software cannot be programmed until the specific flight configuration that the software represents has been designed. This difficulty leads to a situation not only peripherally sensitive to budget constraints but primarily sensitive to time and schedule.

An examination of the standalone training schedules (fig. 10) shows that, in early January 1986, the late remanifesting and inability to meet milestone delivery requirements caused a serious problem in time available for crew training. During January 1986, this problem was getting progressively worse. The only options for recovery were to compress crew training or slip the launches.

Similarly, the addition of a payload specialist requires a serial effort. A payload specialist must be trained, and procedures must be developed and equipment stored for him in an interrelated and serial manner. Often, the activities have to be accomplished in an extremely short timeframe which leaves the crew feeling more time-constrained and less well-prepared than would have been the case had there been a mechanism for schedule relief.

The freeze point goal for the definition of the payload specialists for any given mission is L-5 months. Missions STS 41-G through STS 61-C were reviewed to define when payload specialists were assigned in relation to the freeze point (fig. 11). A total of 16 payload specialists were added to these flights ranging from no earlier than L-9 months to L-7 weeks. Seven of the 16 payload specialists were added after the L-5 freeze point, two additions being external in nature and the remaining five resulting from payload requirements.

e. KSC Orbiter Processing

The following only reflects the impact of manifest changes on KSC operations. The flight production template is designed for a start of Orbiter processing at launch minus 2 months. The impact of late changes on KSC Orbiter processing is a function of the type change and when prior to launch the changes are made. In general, changes made prior to Cargo Integration Review (CIR) are transparent and result in little additional work.

Between CIR and Launch Site Flow Review (LSFR) the impact of changes varies depending on the type payload. For example:

1. Primary payload changes involve significant impact. A delta review is required for engineering hardware. The time available to develop and review documentation is greatly reduced, and the....

---

---

---

---

[J43] ....amount of overtime is increased. They also force other tasks to be reprioritized.

2. Secondary payload (mounted in the payload bay) changes can generally be accommodated with minor impacts.

3. Middeck payload changes result in no impact.

After LSFR, the impact of changes becomes more acute as follows:

1. Primary payload changes can be made only if a like payload is substituted for an existing payload. Other changes would result in a launch delay or heary overtime and a very short preparation cycle.

2. Secondary payload changes can be done for certain predefined gas containers or predefined payloads requiring only structural interfaces.

3. Middeck payload changes can be done for prepacked payloads. Some reflight payloads might be possible while first flight payloads are very questionable.

Since the KSC processing is at the "end of the line" for implementing changes, difficulties usually occur late in the process (L-5 month timeframe and during actual hardware processing). The prevailing "can do" response results in impacts to budgets and manpower planning. Late changes usually result in high overtime for some KSC personnel, some of which are already supporting a 7-day/week schedule. Another significant impact is the shortening of the review cycle for the work authorization paperwork for hands on personnel.

An additional source of problems in KSC Orbiter processing is longer. Non-standard processing flows that do not fit the standard template for Orbiter processing (normally starts at L-2 months) and payload processing. This causes KSC to absorb the extra work created when products are delivered according to the standard template. Non-standard flows included DOD, Spacelab, and Centaur missions. Another source is the requirement to absorb the workload bow-wave from launch delays of one or more missions to preserve a fixed launch date for an upcoming mission; i.e., Halley's Comet rendezvous, STS 61-E.

3. Flight Preparation Major Milestone History

a. Overview of the Reconfiguration Process

The mission operations reconfiguration process is the means by which the JSC MOD builds the products required for support of a particular flight. The products of significance include a flight-unique Mission Control Center release ("MCC"), a flight-unique Shuttle Mission Simulator release ("SMS"), a flight-unique Orbiter flight software release ("MMU"), a flight-unique crew activity plan, and flight-unique crew training. (Refer to figure 12.)

The previously described products are built from requirements identified by the user community, which includes both the STS and the payload (customer). These requirements are provided through standardized processes which will not be addressed here. It should be noted, however, that the reconfiguration process is heavily dependent on receipt of these requirements in mature form at the specified need dates to enable production of the end products on time. One of the most significant requirements with which the reconfiguration process must deal is the manifesting of the major payloads in the cargo bay.

The mission operations reconfiguration process is performed through several subelements (or "workstations"). Each workstation has distinct functions to perform leading to the major end products discussed previously. Although the process is serial to a large degree, considerable interaction and coordination among all workstations is necessary throughout the process to ensure that all areas are working to the same baseline and schedules.

The overall schedules to which all workstations must work are determined through the use of standardized templates. These templates model the process from start to finish, including the time required for each workstation to perform its task as well as when each task, must start and finish to deliver the end products on time. The template (figure 12) has undergone some changes in the last several years, but the major reduction in time allocated to complete the reconfiguration process for a given flight had not been implemented as of STS 51-L. The first flight for which the "reduced" template was to be used was STS 61-M. Therefore, the full effect of the reduced template on the reconfiguration process had not been felt at the time of the accident.

The reduction in the allocated time was one consequence of the reconfiguration process evolution over several years. The evolution was the result of several factors, including the maturity of the STS, which permitted standardization of some products: a programmatic desire to minimize long lead times in flight preparation; new reconfiguration tools, and the consolidation of the reconfiguration process responsibility into one directorate.

b. The Reconfiguration Process Workstations

(1) Reconfiguration Requirements

The reconfiguration requirements ("Recon") workstation translates requirements from the user community in the areas of telemetry, command, and display into flight-unique reconfiguration formats which are usable , by the STS. The products from this workstation include the definition of all Orbiter cathode-ray tube displays to be used for a particular flight, and the definition and format of all downlinked data and uplinked commands.

(2) Flight Design

The flight design workstation translates user community trajectory requirements such as 1aunch/landing/payload deploy window constraints into a comprehensive flight-unique trajectory definition. This definition must accommodate all requirements, vehicle performance constraints, and basic mass properties for the entire vehicle. The products from this workstation include the ascent, orbit, and entry design parameters which are incorporated into the Orbiter flight software and used for onboard navigation and guidance, and the Mission Control Center (MCC) trajectory display requirements which are incorporated into the flight-unique MCC release and used by the flight controllers for monitoring the vehicle trajectory in real time.

(3) Crew Activity Planning

The crew activity planning workstation combines all on-orbit activity requirements from the user community into a cohesive and detailed plan of all activities while the Orbiter is on orbit. Included in this plan is a detailed plan of all Orbiter attitude maneuvers and time of nominal occurrence.

(4) Measurement and Stimulus

The measurement and stimulus workstation ("MAST") receives the requirements from the flight design and Recon workstations, integrates them with a standard data base, and delivers flight-unique data tapes to various users.

(5) Flight Software

The flight software workstation incorporates the MAST data tapes and other flight-unique inputs into a standard Orbiter flight software base load and produces a flight-unique Orbiter flight software release ("MMIU").

(6) Mission Control Center

The Mission Control Center ("MCC") must configure to support each flight (and simulation) using a flight-unique release. To do this, the MCC incorporates the flight-unique MAST data tapes, the flight design trajectory definition, the Orbiter flight software, and user ground display requirements into a base MCC.....

[J45].....release. This flight-unique MCC release is used for crew/flight controller integrated simulation training as well as for actual flight support.

(7) Shuttle Mission Simulator

The Shuttle Mission Simulator (SMS) incorporates the payload flight-unique model requirements, the flight software, and the MAST data tapes into a base SMS load and produces a flight-unique release. This SMS release is used for both crew and flight controller training. Crew-only training is known as "standalone," whereas training in which the crew in the simulator is linked to the flight controllers in the MCC is known as "integrated."

It should be noted that the delivery of standalone training capability is one key measure of the success of the reconfiguration process, since it is at the end of the process and is essential for a successful flight.

c. Discussion of the Milestone History Data

To effectively analyze the relative success of the reconfiguration process, delivery of products must be put in the context of the schedule being worked to at the time of delivery. This procedure is particularly necessary given the continual schedule slips induced by launch date slips. The performance of individual workstations within the reconfiguration process, as well as the overall reconfiguration process, can be measured using the technique of normalization, which adjusts data for the schedule being worked to at the time of product delivery.

d. Individual Workstation Performance

Several representative workstations will be discussed. It should be noted that the data used for this report are the combined best inputs from the individual workstations and the Mission Requirements Management System (MRMS) data base. The reconstructed data have some limitations, in that the process of recording the data for the purpose of providing historical perspective was just being introduced. Nevertheless, it is felt that the information has been made as reliable and correct as possible.

(1) Crew Activity Planning

The delivery of the basic version of the Crew Activity Plan relative to the actual launch date from STS-5 through STS 51-L was on time or early. The early deliveries can largely be attributed to launch date slips. Similarly, the final version of the Crew Activity Plan was generally delivered on or before the actual due date. and revisions were made as close to launch as required.

(2) Flight Design

The delivery of the end product of the cycle 1 (first iteration of two total) flight design process was generally close to the date required for flights through STS 51-L.

(3) Flight Software

The initial release of the Orbiter flight software compared to the template objective of delivery at L-140 days is somewhat later than desired. Research into the causes shows that most slips were due to inputs to the flight software workstation that were not on time, or to programmatically induced delays that were recognized and agreed to at the time. Flights 61-C and 51-L are good examples of the latter, as those delays were induced by a program decision to incorporate nosewheel steering software changes into the first delivery of software for those two flights, and to accept a delay as a result. Historical analysis has shown that the flight software deliveries are a good barometer of the performance of the workstations upstream of it, so it is fair to say that late outputs from flight software reflect late outputs from flight design, MAST, or Recon. The delivery of the final flight software load was generally on time or early.

The workstations described are selected representative samples of the overall reconfiguration process milestone history. These samples, combined with the following training analysis, adequately depict the process status since STS-5.

e. Training

The standalone training data (fig. 1, sec. VC) identify a clear trend downward in the amount of available training for each flight relative to the desired 77-day baseline. Figure 10 shows the forecast trend for 1986 as it was known in January 1986. (This chart represents the actual forecast slips as they were known in January.) This forecast clearly shows a serious problem in time available for crew training. The only options for recovery were to compress crew training or slip the launches.

f. As-Flown History

In November 1985, the Schedules and Flow Management Office within MOD began closely tracking and documenting all problems and directives which affected the reconfiguration process schedules. In the period from November to the time of the accident, 89 problems/directives were encountered. Of those, 41 were induced by the program as flight manifest changes, late/incorrect inputs from the customer, or other directives such as the late nosewheel steering software change. Of the remainder, 36 were internally induced through such things as manual data entry errors. The other 12 were the result of problems with the reconfiguration tools - not delivered according to the understood requirements, for example.

4. Workload Assessment of MOD Personnel Who Influence the Quality of Real-Time Support

The data source is the Manpower Utilization Records (MUR) data system used for resource management within MOD. The MUR data consist of a compilation of the time allocated by each employee to each assigned task. The MUR identifies, for example, the flight which is being worked on, whether the work is flight specific, and the type of task, such as real-time flight support in the Mission Control Center.

a. Approach

The approach used in performing an assessment of the workload was to compile the data over the last 2 years (1984 and 1985) and build plots which might show trends. The plots which were developed were composites of the entire work force (i.e., no distinction was made between the civil servants, contractors, and military personnel). Data were used only for 1985 for the Mission Control Center and Shuttle Mission Simulator facility maintenance and operations personnel. These data were acquired from the contractor financial reporting records.

Four specific parameters were used as measures of the workload:

1. Total of all work performed

2. Flight-specific work performed

3. Overtime required

4. Leave taken

b. Background

The focus of this review is on the various elements of the Mission Operations Directorate responsible for the planning and execution of the real-time flight support in 1984 and 1985. Those areas are as follows:

1. Training (DG) - Provides crew and flight controller training.

2. Systems (DF) - Provides real-time support for Space Shuttle systems monitoring and anomaly resolution; also provides preflight procedures development associated with Space Shuttle systems operations.

[J46] 3. Crew Activity Planning (DH) - Provides timeline of crew activities while on orbit, as well as integrated procedures development and overall onboard Flight Data File (all onboard reference documentation) management.

4. Payload Support (DH) - Provides the payload customer operations integration and real-time systems support.

5. Flight Dynamics/Guidance (DM) - Provides the real-time trajectory monitoring and navigation state maintenance functions.

The above workforce is composed of approximately 600 people. Additionally, the Mission Control Center and SMS Facility Maintenance and Operations personnel are composed of an additional 660 people.

The management approach to distributing the workload is as follows. Predefined teams for real-time support are established, with a known rotation scheme and long-term projections of manning schedules. The goals are to give personnel knowledge of future assignments to allow for personal planning, to minimize the number of people that work consecutive flights, to control the maximum number of hours a person spends in the console environment, and to develop as many people as possible with equivalent skills to allow substitutions when required. Real-time support work is done on an around-the-clock shift basis, with any given shift limited, in general, to 9 hours. Such work also extends through weekends and holidays during flights.

c. Summary of the Data - Workload

Figure 13 is a plot of the total manpower (EP's dedicated to support of each specific flight. This support includes both preflight planning and real-time activities. The trend appears to be toward a steady state in the range of 250 to 400 EP's. The reasons for the variations within this range were not examined: however, it is known that differences in mission complexity and time available for preparation are significant factors. It is clear from the figure that most people took leave over the 1984-1985 Christmas holiday season.

Figure 14 illustrates that roughly 40 percent of the total work performed was associated with a specific mission. This percentage includes both real-time and preflight work.

The time spent per week in the Mission Control Center participating in simulations of flights with the crews ("integrated simulations") is shown in table 1. This training can be either flight-specific or generic in nature. The times shown apply only to the time spent during which the training actively occurred and does not account for "down" time (i.e., time when the simulator is inactive). Note that the data are broken down according to teams and that there were only three weekends in 1985 in which integrated simulations occurred. Time spent at work during missions is not covered in this chart, however.

The amount of time spent in real-time support of a specific flight was on the average of 8 to 10 percent of the total time worked.

For the amount of overtime spent as a percentage of the total hours worked, a band of 4 to 8 percent seems to represent the norm (fig 15). No reason for the variation within this band is known. Each work area was also plotted, and the overtime varied from as low as I percent to as high as 14 percent in particular cases, with 4 to 8 percent the average.

The percentage of hours of leave taken to the total hours worked fluctuates from 5 to 12 percent (fig. 16). The higher percentages at Christmas and summer vacation are as expected.

The overtime spent by the contractor personnel in the Mission Control Center facility operations area averaged 4.3 percent in 1985.

Overtime for the contractor personnel in the Shuttle Mission Simulator facility operations areas averaged 6.2 percent in 1985.

5. Findings

1. The manifesting process is one that receives inputs from several areas including NASA Headquarters, JSC. KSC, and NASA Marshall Space Flight Center (MSFC). As candidate manifests are being considered, each of the centers and their disciplines assess not only the manifest but also their ability to support the new manifest and production cycle. All primary payload manifest changes have been agreed to by all parties.

2. In general, the manifesting was found to be a structured and extremely active process. The major reasons for this high activity are hardware problems, customer requests, operational constraints, external factors and their accommodation. When more payloads were flown because of the higher flight rate, there were more problems causing manifest changes that ripple through many flights. The later these changes occur in the flight production process, the larger the impact on budget and schedule. The 1985 schedule impacts were accommodated by using the time gaps left over from canceled flights.

3. To minimize impacts, customer requirements for payload specialists should be finalized at least 5 months prior to launch and before the L-5 review program freeze point to least impact the production process. External factors cannot be ignored, but the goal should be to identify requirements at the beginning of the production process to support the schedule template.

4. Late manifest changes that add middeck or secondary payloads or payload specialists with their experiments can draw attention and resources away from the primary flight operations.

5. The trends indicated that the milestones required to support preparation for the 1986 flight schedule were not being met. The several flights following STS 51-L would have had less than the optimum amount of flight-unique training without additional launch slips.

6. Historically, flight launch date slips have provided needed relief to reconfiguration process schedules.

7. Externally generated (program level) inputs to the reconfiguration process are a significant source of impact to schedules.

8. The organizations reviewed here are not systematically or regularly overworked.

9. As a work force, they are not required to work weekends on a regular basis except as real-time mission support warrants and in supporting facilities where it is planned.

10. Personnel are able to take leave and generally can do so at traditional holiday periods.

11. Management recognizes the flight rate influence on workload and strives to project and plan for distribution of that workload

6. Conclusions

1. Early in the Space Shuttle Program, when launches were scheduled several months apart, delays in milestone start times had little or no impact on future program schedules. Rigid manifesting criteria do not currently exist. Optimization and facilitating payloads appears to be the plan. However, in a medium to high flight rate operational program, the major critical milestones of CIR, FOR, start of crew training, start of integrated training, and Flight Readiness Review (FRR) must be met to accommodate the flight rate. Since hardware and other unforeseen problems will occur and cause delays to the schedule, an adequate flight preparation criterion must be established that forces the slip of a launch when major milestones cannot be met. Consequently, manifest opportunities should be added to the schedule to serve as a schedule catchup point for all manifesting Problems.

2. Unworkable flights (flights having negative ascent performance margins, over-limits landing weights, incompatible launch windows, etc.), once identified, should not be carried in the manifest.

---

[J51] 3. The production process should continue to be developed and methods of continually monitoring the production process should be devised. To support a flexible manifesting program, an integrated production process tool to forecast schedules, manpower, and budget requirements needs to be implemented. Additionally, the Operations Organization should develop methods to handle reasonable changes in a simple manner.

VI. Major Findings and Conclusions

This section contains a collection of the major findings, and conclusions drawn from these findings, as a result of the activities of the Mission Planning and Operations Team (MPOT). These findings and conclusions are presented in summary form in this section. Additional findings and conclusions and supporting data for these findings and conclusions can be found in the appropriate sections and appendices of this report.

a. Major Findings

1. STS 51-L manifesting, Mission Operations, flight crew preparations, prelaunch, and launch were typical and satisfactory and had no effect on the accident.

2. There was no action possible that could have resulted in the survival of the STS 51-L crew.

3. The Range Safety System (RSS) did not contribute to the accident. The actions of the Range Safety Officer (RSO) were appropriate. A joint NASA Department of Defense (DOD) review of the RSS is appropriate and planned.

4. 1985 Mission Operations were successful in spite of significant remanifesting and perturbations. However, the trends indicated that the milestones required to support preparation for the 1986 flight schedule were not being met.

5. The current program commitments preclude devoting adequate resources to developing a capability to support an increased flight rate.

6. The operational Maintenance and Inspection Program is immature and does not yet provide Level II with adequate closed loop oversight. It lacks a comprehensive system to track and audit compliance with established requirements.

7. At the time of the STS 51-L launch. KSC landings did not constitute an unreasonable safety of flight risk based on known failures.

8. Statistical weather and forecasting uncertainties have resulted in several weather waveoffs and dictate a need for multiple landing sites for end of mission.

9. The current landing and deceleration systems have not demonstrated an adequate margin for routine KSC and TAL abort operations.

10. The program considered crew escape numerous times but, because of limited utility, technical complexity, cost, schedule, and performance impacts, no systems were implemented.

11. The Astronaut Office plays a significant role in all activities associated with development, flight preparation, and flight execution, and they or their management are members of all major decision-making boards and panels.

b. Major Conclusions

1. The NSTS Program should develop a bottoms-up strategy for expanding the flight rate. As a start, rigid manifesting criteria need to be established and enforced.

2. An inspection and maintenance program should be implemented that will ensure flawless performance of critical Space Shuttle hardware into the 21st century.

3. The NSTS Program should focus attention on defining and providing an adequate margin for end-of-mission and intact abort landings. This includes both ground facilities and flight hardware.

4. The NSTS Program should evaluate the options and utility of providing crew escape systems and augmenting Orbiter abort modes.

VII. References

1. "National Space Transportation System Ascent Performance Objectives and Capability Evaluation." NASA-JSC TE-86-059. April 1986.

2. "Report of Working Group on Expansion of the Entry Flight Envelope." NASA-JSC DM5-86-24. April 1986.

3. "Logistics and Program Overview." NASA-JSC VP3-86-M037. April 1986

4. "SOPC SMS Loading - Response to SOPC Support Questions." March 6, 1986,

5. "Flight Crew Operations Directorate POP 83-2 - 4th STA Requirement." June 17, 1983; "STA Presentation to NASA Headquarters." August 1983.

6. "STS Flight Software Review." April 21, 1986.