NASA Document SP-287: What Made Apollo A Success

1. INTRODUCTION

By George M. Low - Manned Spacecraft Center

On July 20, 1969, man first set foot on another planet. This "giant leap for mankind" represented one of the greatest engineering achievements of all time. This article and the others in this document describe and discuss some of the varied tasks behind this achievement.

We will limit ourselves to those tasks that were the direct responsibility of the NASA Manned Spacecraft Center: spacecraft development, mission design and mission planning, flight crew operations, and flight operations.

We will describe spacecraft design principles, the all-important spacecraft test activities, and the discipline that evolved in the control of spacecraft changes and the closeout of spacecraft anomalies; and we will discuss how we determined the best series of flights to lead to a lunar landing at the earliest possible time, how these flights were planned in detail, the techniques used in establishing flight procedures and carrying out flight operations, and, finally, crew training and simulation activities — the activities that led to a perfect flight execution by the astronauts.

In short, we will describe three of the basic ingredients of the success of Apollo: spacecraft hardware that is most reliable, flight missions that are extremely well planned and executed, and flight crews that are superbly trained and skilled.

(We will not discuss two equally important aspects of Apollo — the launch vehicles and launch operations. These elements, the responsibility of the NASA Marshall Space Flight Center and the NASA Kennedy Space Center, go beyond the scope of this series of articles.)

SPACECRAFT DEVELOPMENT

Four aspects of spacecraft development stand out: design, test, control of changes, and interpretation of discrepancies. We can begin with them.

Spacecraft Design

The principles of manned spacecraft design involve a combination of aircraft-design practice and elements of missile-design technology: Build it simple and then double up on many components or systems so that if one fails the other will take over.

Examples are ablative thrust chambers that do not require regenerative cooling; hypergolic propellants that do not require an ignition source; three fuel cells, where one alone could bring the spacecraft back from the moon; series/parallel redundancy in valves, regulators, capacitors, and diodes so that neither an "open" nor a "closed" failure will be catastrophic.

Another important design rule, which we have not discussed as often as we should, reads: Minimize functional interfaces between complex pieces of hardware. In this way, two organizations can work on their own hardware relatively independently.

Examples in Apollo include the interfaces between the spacecraft and launch vehicle and between the command module and the lunar module. Only some 100 wires link the Saturn launch vehicle and the Apollo spacecraft, and most of these have to do with the emergency detection system.

The reason that this number could not be even smaller is two-fold: Redundant circuits are employed, and the electrical power always comes from the module or stage where a function is to be performed.

For example, the closing of relays in the launch vehicle could, in an automatic abort mode, fire the spacecraft escape motor. But the electrical power to do this, by design, originates in the spacecraft batteries.

The main point is that a single man can fully understand this interface and can cope with all the effects of a change on either side of the interface. If there had been 10 times as many wires, it probably would have taken a hundred (or a thousand?) times as many people to handle the interface.

Another design question for manned flight concerns the use of man himself. Here again, we find no simple rule as to how man should interface with his machine. Generally, tedious, repetitive tasks are best performed automatically; and selection of the best data source to use, selection of control modes, and switching between redundant systems are tasks best performed by the pilot.

In Apollo, the trend has been to rely more and more on automatic modes as systems experience has been gained. For example, computer programs for rendezvous were reworked to require far less operator input than had originally been planned, but the entire rendezvous sequence was designed so that the pilot could always monitor the automatic system's performance and apply a backup solution if deviations were noted.

A tremendous amount of time and effort was spent to determine how the crew could best decide which data source to use and which of many redundant systems to rely on. This was always a basic mission-design consideration.

The concept of inflight maintenance was discarded entirely as being impractical for flights with the specific purpose and duration of Apollo. In its place, more telemetry was added and full advantage was taken of the ground's ability to assess system performance, predict trends, and compare data with preflight test experience.

Apollo Test Activities

The single most important factor leading to the high degree of reliability of the Apollo spacecraft was the tremendous depth and breadth of the test activity.

There are two general categories of tests: (1) those made on a single prototype device (or on a few devices) to demonstrate that the design is proper and will perform properly in all environments and (2) those made on each flight item to assure that there are no manufacturing errors and that the item will function as intended.

Both categories apply to individual parts, components, subsystems, systems, and entire spacecraft. The first category includes development testing early in the design cycle and the very formal certification or qualification tests performed on test articles identical to the flight system. The second category covers acceptance testing.

Instead of reviewing the entire development and qualification test program, we can focus on only those tests involving complete spacecraft or boilerplates, as listed in table 1-I. Each of these tests taught us more about our spacecraft — their strengths and weaknesses.

As a result of the thermal vacuum tests, the spacecraft withstood the translunar and lunar environments without a single thermal problem. Passive thermal-control modes were developed that required minimum crew inputs and gave a perfect thermal balance.

The land-impact tests demonstrated that the command module could survive an emergency land landing if wind velocity stayed within certain limits. These tests also led to the design of a new impact-attenuation strut for the astronaut couch. The strut allowed us to increase the permissible launch wind speed and thereby gave us more flexibility in an otherwise constrained launch window. Other tests brought equally significant results.

TABLE 1-I

DEVELOPMENT AND QUALIFICATION TESTS

Full-scale spacecraft testing

Control of Changes

If the design has been verified and if a thorough test program has been completed, it should not be necessary to make any changes. Of course, this idealized situation does not exist in any program like Apollo where design, test, and flight often overlap and must be carried out at the same time.

Changes may be required as a result of test failures, or another look at the design may identify a situation that could lead to a failure or to the inability to react to failure. Sometimes a more detailed definition of flight missions or operational use of the hardware itself leads to a requirement for change.

Since it is not possible to eliminate all changes, we have to start with the premise that any change will be undesirable. That is, a change will void all previous test and flight experience and, no matter how simple, may have ramifications far beyond those identified by the initial engineering analysis.

Because changes must be made nevertheless, it becomes important to understand and to control them, no matter how small. In Apollo, we handled all changes through a series of Configuration Control Panels and a Configuration Control Board. The panels considered minor hardware changes early in the development cycle, as well as crew procedures and all computer programs.

The Board considered more significant hardware changes, all hardware changes after spacecraft delivery, and procedures or software changes that could affect schedules or missions.

The Apollo Spacecraft Configuration Control Board met 90 times between June 1967 and July 1969, considered 1697 changes, approved 1341, and rejected 356.

We had a low rejection rate because proposed changes were reviewed before they came to the Board, and only those deemed mandatory for flight safety were brought before it. The Board is chaired by the Program Manager, who also makes the final decision on all changes. The Board includes the directors of all major technical elements of the NASA Manned Spacecraft Center and the contractors' program managers.

We considered changes large and small. An example of a large change is the new spacecraft hatch that was incorporated after the fire. However, we reviewed in equal technical detail a relatively small change, such as a small piece of plastic to go inside the astronaut's ballpoint pen.

The Board was established to discipline the control of changes; but it was found to serve a much larger purpose: It constituted a decisionmaking forum for spacecraft developer and user. In reaching our decisions, we had the combined inputs of key people representing hardware development, flight operations, flight crews, safety, medicine, and science.

I have recently reviewed the results of the 90 Board meetings that preceded Apollo 11. Even with hindsight, I find few, if any, Board decisions that I would make differently today.

Closeout of Failures

Throughout Apollo, many discrepancies or failures occurred daily. The relationship may have been a close one (i.e., failures actually took place during testing of the next spacecraft to fly) or it might have been remote (i. e., a component identical to one used on Apollo failed on another program).

In either instance the result was the same: The failure had to be understood and, if applicable, some corrective action taken. This might involve design change, reinspection, or perhaps procedural change.

I will confine my remarks to anomalies that occurred during the first five manned Apollo flights. The number of anomalies for each mission are given in table 1-III.

Note that, even though each of the flights was completely successful and met all its objectives, the number of anomalies went quite high. Perhaps this is the best proof of the validity of the Apollo design concept: The spacecraft were designed for mission success.

TABLE 1-III. - APOLLO FLIGHT ANOMALIES

FLIGHT MISSIONS

It is difficult to describe, to those not directly involved in the Apollo Program, just how much work went into operational activities.

First, we had to decide the kinds of mission to be flown: What would be the best series of missions to achieve a successful manned lunar landing at the earliest time?

Then these missions had to be planned in detail: How should each mission be designed to meet the largest number of operational and hardware objectives, even in the event of unplanned events?

(Operational objectives are concerned with guidance, navigation, trajectory control, rendezvous, etc.; hardware objectives are concerned with the verification of each system or subsystem in the flight environment.)

Finally, plans had to be made for the execution of the mission: Detailed rules were evolved for every imaginable contingency; the proper flight-control displays were defined to permit instantaneous reaction to emergencies, and countless hours were spent in simulations of every conceivable situation.

Mission Definition

Early in 1967 the situation was as follows. Many development flights had taken place to test the launch-escape system under extreme conditions, to test the command module heat-protection system at speeds halfway between earth-orbital and lunar-reentry velocities, and to put the guidance and propulsion systems through their preliminary paces.

However, Saturn V had not yet been flown, reentry at lunar-return speeds had not yet been made, the lunar module had not yet been flown, and man had not yet been in space in Apollo hardware.

The flight-test program shown in figure 1-7 was then evolved through an iterative and flexible process that was changed as time went on to take the best advantage of knowledge about mission operations and hardware availability at any given time.

The basic principle in planning these flights was to gain the maximum new experience (toward the goal of a lunar landing) on each flight without stretching either the equipment or the people beyond their ability to absorb the next step.

Mission Planning and Execution

Once basic missions had been defined, each flight had to be planned in detail. The mission planner tries to fit into each flight the maximum number of tests of the hardware and the widest variety of operations.

For example, he will develop a rendezvous profile for a single earth-orbital flight that involves all of the normal and abnormal rendezvous conditions which might be encountered around the moon — rendezvous from above, rendezvous from below, rendezvous with the lunar module active, rendezvous with the command and service module active, and rendezvous with varying lighting conditions.

At the same time, the mission planner will try to exercise all of the propulsion systems and all of the navigation systems on both spacecraft.

After mission plans come the mission techniques (by another name, data priority). Given two or three data sources (for trajectory control), which of the sources should be believed and which discarded?

Limits for each system had to be determined, and logic flows for every conceivable situation had to be developed.

Finally, the flight controllers take over. They had participated, of course, in the mission-planning and mission-technique activities; but now they had to work out each step of the flight and anticipate every emergency situation that might arise.

What is the proper action when one fuel cell fails? What if two fail? The answers to thousands of questions like these had to be derived in terms of the specific mission phase. A rendezvous radar failure before command and service module-lunar module separation dictates that the two vehicles should not be separated.

The same failure after separation allows the mission to be continued because the risk of rendezvous without radar has already been incurred and will not increase in subsequent mission sequences. Each of these events was documented as a mission rule long before the flight, and mission rules were placed under "configuration control, '' as was every other aspect of the Apollo system.

Flight controllers also worked out the best formats for their real-time displays. During the Apollo 11 descent to the surface of the moon, the flight controllers could watch, with a delay of only 6 to 10 seconds, the functioning of nearly every onboard system. They saw the rise in chamber pressure as the descent engine was throttled up to full thrust, and they could determine that the throttle-down occurred at the proper time.

The flight controllers could also compare the descent trajectory from three data sources — two onboard guidance systems and the ground tracking system. With this information, a flight controller on the ground could tell the crew, nearly 250 000 miles away, to ignore the alarms from the onboard computer during the most critical portion of the descent, because the system was guiding the spacecraft correctly.

Many of the techniques used during the flight were developed during countless hours of simulations. Simulation is a game of 'what-if's.'' What if the computer fails? What if the engine does not ignite? What if...?

The game is played over and over again. The flight controllers do not know what situation they will face on the next simulation.

By the time of flight, they will have done simulations so often and they will have worked together as a team so long, that they can cope with any situation that arises.

Because the Apollo equipment has worked so well and because there have been so few contingency situations, one could conclude that much of the planning, many of the mission techniques, and much of the training were done in vain.

But this is an incorrect conclusion.

As a minimum, the state of readiness that evolved from these efforts gave us the courage and the confidence to press on from one mission to the next.

Also, there were situations — the computer alarms during the descent of Apollo 11 and the lightning discharge during the launch of Apollo 12 — that might have led to an abort if the team had been less well prepared and less ready to cope with the unexpected.

FLIGHT CREW TRAINING

The first six Apollo manned flights carried 18 astronauts — all professional pilots, skilled and superbly trained. Altogether, they had flown on 18 flights in Mercury and Gemini before they flew in an Apollo spacecraft.

Five had flown twice before, eight had flown once before, and five flew for the first time in Apollo.

Training for Apollo is not easy. Two highly sophisticated machines are involved, each far more complex than those in Gemini. The astronauts had to become expert in the workings of both spacecraft.

They became computer programers and computer operators, space navigators, guidance experts, propulsion engineers, fuel-cell-power managers, environmental-control-system experts — to mention but a few areas of expertise.

Of course, they had to learn how to control and fly two spacecraft with vastly different handling qualities under conditions of launch, translunar flight, lunar-orbit flight, lunar landing, lunar launch, rendezvous, docking, transearth flight, and reentry.

The astronauts used a variety of training devices — high-performance airplanes to stay alert and sharp; a special dynamic launch simulator to practice manual take-over and abort modes; mission simulators to duplicate here on earth every spacecraft function and display under all possible conditions; partial-gravity simulations under water, in airplanes, and on a special servo-controlled device on the ground; a docking trainer; and a flying lunar-landing training vehicle that has a jet engine to take out five-sixths the gravity of earth so that the vehicle has the same flying characteristics as the lunar module has on the moon.

The astronauts also needed plans and procedures.

Flight plans spelled out each step of the mission. Detailed "time lines'' were developed for every function that had to be performed, minute by minute. Crew procedures and checklists were an adjunct to the flight plan.

The step-by-step sequence for each spacecraft activity, each maneuver, each propulsive burn was worked out well in advance and was used again and again during practice and simulation.

Configuration control was as important in the astronaut training as in every other category. Simulators had to look just like the spacecraft to be useful, and last-minute spacecraft changes had to be incorporated in the simulators as well.

Crew procedures that had worked well on one flight could not be changed, through "crew preference," for the following flight.

Pete Conrad said that landing his Apollo 12 lunar module, after dust obscured the landing point, was the most difficult task he had ever performed.

It took all of his 20 years of experience as a professional aviator, his previous work on two Gemini flights, his training for Apollo, and his knowledge and confidence in the Apollo spacecraft systems to make that landing a success.

CONCLUDING REMARKS

Spacecraft development, mission operations, and flight crew activities — in reviewing these areas of Apollo, I see one overriding consideration that stands out above all the others: Attention to detail.

Painstaking attention to detail, coupled with a dedication to get the job done well, by all people, at all levels, on every element of Apollo led to the success of what must be one of the greatest engineering achievements of all time — man's first landing on the moon.

The reports which follow amplify this observation.

2. DESIGN PRINCIPLES STRESSING SIMPLICITY

By Kenneth S. Kleinknecht - Manned Spacecraft Center

The shaping of reliable, safe Apollo spacecraft owes its success to specific principles stressing the simplicity, both in originating and evaluating hardware designs.

The primary consideration governing the design of the Apollo system was that, if it could be made so, no single failure should cause the loss of any crewmember, prevent the successful continuation of the mission, or, in the event of a second failure in the same area, prevent a successful abort of the mission.

DESIGN PRINCIPLES

To implement this policy, the following specific principles were established to guide Apollo engineers when they originated and evaluated hardware designs.

DESIGN FEATURES

Apollo gains a measure of simplicity from features simple both in design and operation, complex in design but simple to operate, or simple by being passive in function. The concept of simple design and simple operation is best illustrated by the Apollo rocket-propulsion systems (fig. 2-2).

The pressure feeding and redundant valving guarantee the arrival of the propellant in the combustion chamber, where hypergolic reaction assures ignition. Ablative materials for chamber walls assure chamber integrity while simplifying design greatly.

CONCLUDING REMARKS

The Apollo design philosophy has resulted in a highly reliable spacecraft capable of placing man on the moon and returning him to earth safely. Simple design practice, coupled with stringent technical and administrative discipline, has achieved this end.

The spacecraft (the command and service module and the lunar module), embodying millions of functional parts, miles of wiring, and thousands of welded joints, has evolved into a truly operational space transportation system.

3. TESTING TO ENSURE MISSION SUCCESS

By Scott H. Simpkinson - Manned Spacecraft Center

All programs, once the overall objectives are fixed, must meet well-defined design goals, or management fails. However, this hard fact does not prevail in the world of test. Theoretically, one no longer needs to test hardware or software, after developing a new concept, except occasionally to gather empirical data needed to operate the equipment.

Unfortunately, designs are not perfect, materials and processes often do not work as the designers expect, manufacturing techniques sometimes inadvertently alter the design, assembly procedures leave room for mistakes, engineering and development tests do not necessarily provide all the required data, and, finally, substandard workmanship and human error creep in.

All of these factors require attention at the outset of a program. Some factors, such as human error, demand vigilance until delivery of the last item. Experience has shown that only a well-balanced test program can instill confidence in the delivered hardware and software for a space vehicle.

At the beginning of the Apollo Program, high priority went to setting up a program for one-time qualification of a component or system design and to manufacturer execution of the program. All contracts contained specific clauses relating to qualification tests.

These tests provided a reasonable margin of safety, taking into account the expected environments the pieces would pass through during storage, transportation and handling, ground-test duty cycles, and two-mission duty cycles. After the early unmanned flight-test program had started, actual measurements of the launch environment led to adjustments in the qualification vibration levels. Equipment already tested at too low an amplitude had to pass an additional (or delta) qualification test program. Rigorous monitoring and careful failure reporting allowed correction of design and process failures.

Even with this exacting qualification program, a number of experienced engineers believed each flight item should have to pass some environmental testing before NASA accepted it for installation and flight. Thus, nearly all functional components and systems underwent acceptance testing. However, the detailed test plans were left in the hands of the individual designers and system engineers.

During the early stages of the Apollo Program, most components and systems were limited to a complete functional bench test at room temperature and pressure and a survival test after a brief exposure to random vibration in the axis suspected of being the most sensitive and at the expected flight-power spectral density.

A few vendors, who were experienced on other critical military and NASA programs and who were supplying electronic components for the lunar module (LM), also performed temperature-limit tests at their own discretion during buildup or during the final acceptance tests (or, in some cases, during both).

Unfortunately, the expected flight vibration levels were so low in many cases that these early environmental acceptance tests did not reveal errors of workmanship and manufacturing processes. Many system manufacturing and processing errors came to light late in the cycle, delaying the program and wasting manpower.

After the spacecraft fire, NASA launched an extensive review of the Apollo acceptance test practices. Subcontractors and vendors for 33 Apollo spacecraft assemblies, representing a cross section of electrical, electronic, and electromechanical equipment throughout the spacecraft, received 79 detailed questions concerning their individual acceptance test plans and objectives. This survey revealed the inadequacy of environmental acceptance tests or, in many cases, the nonexistence of acceptance tests.

Soon, both the command and service module (CSM) and the LM would carry men for the first time. The decision was made by NASA to review completely all Apollo spacecraft acceptance, checkout, and prelaunch test plans and procedures.

In general, the review found factory checkout and prelaunch tests at the launch site adequate and, in many cases, with overly tight tolerances. Between installation and launch, the equipment passed the same tests a number of times.

The revised overall testing ground rules, which came out of the review, resulted in a more efficient test plan from pre-delivery acceptance tests to launch. However, the results of the environmental acceptance test review carry much more significance for those who will make the decisions for future programs.

TODOO: FIX ² text in next paragraph

The prime contractor for the LM required nearly all subcontractors and vendors to subject their equipment to 1 minute of random vibration in each of three mutually perpendicular axes. However, most of the vibration levels were very low, as table 3-I shows.

A decision early in the Apollo Program had set acceptance vibration test levels 6 decibels below those for qualification, or at 0.005 g²/Hz, whichever was greater. (On the average random vibration table, one cannot practically set up a vibration level lower than 0. 005 g²/Hz. ) Many of the components did not have to function or pass continuity checks during vibration tests, only before and after.

To determine proper acceptance vibration tests, a study reviewed 20 major aerospace programs under nine different prime contractors. Bearing in mind the true purpose of acceptance testing — to prevent the installation and flight of substandard equipment — NASA combined the results with an understanding of the nature of the failures encountered after acceptance testing. The resulting program fashioned Apollo vibration tests after those for Gemini.

A component would have to withstand the vibration levels shown in figure 3-1 in each of three mutually perpendicular axes for a minimum of 1 minute and a maximum of 5 minutes. In addition, a firm ground rule pegged the minimum qualification vibration test level at 1.66 times the acceptance test level at all frequencies. In addition, testers had to monitor all pilot-safety functions and continuously check all electrical paths for continuity and short circuits during each of the three vibration cycles.

The testers also had to monitor all mission-success functions, if at all feasible, within schedule and cost constraints. Of the original acceptance vibration test plans for approximately 150 deliverable LM items, 80 plans were changed significantly.

TABLE 3-I - LUNAR MODULE ACCEPTANCE VIBRATION TEST IN 1967

TABLE 3-II - COMMAND AND SERVICE MODULE ACCEPTANCE VIBRATION TEST IN 1967

TABLE 3-III - CRITERIA FOR LUNAR MODULE QUALIFICATION AND ACCEPTANCE THERMAL TESTING IN 1967

4. APOLLO CREW PROCEDURES, SIMULATION, AND FLIGHT PLANNING

By Warren J. North and C. H. Woodling - Manned Spacecraft Center

The formative stages of Project Mercury saw various opinions as to the degree of crew control that should be permitted. To most space planners, Mercury seemed a logical extension of high-performance aircraft flight, in which brief periods of highaltitude zero-g activity had been experienced with no adverse effects. However, there were skeptics who felt that space flight would require radically new procedures and crew operational constraints.

As it developed, Mercury and Gemini attitude control, systems monitoring, and longitudinal translation maneuvers evolved very similar procedurally to aircraft practice. Consequently, the basic concepts for Apollo crew procedures reflect techniques proved in aircraft, Mercury, and Gemini operations.

Over the past decade, space-vehicle designs have incorporated increased astronaut participation to improve vehicle reliability. Mercury used automatically guided military boosters, which were originally designed without consideration for manual monitoring and control. Therefore, it seemed expedient to accept a passive role for the crew. This was done at the expense of developing an elaborate automatic abortsensing system to protect the pilot in the event of booster failure. The pilot did get a backup abort handle for slow-drift guidance failures that could not be sensed by the automatic system.

In Gemini, the complex automatic escape system was eliminated in favor of manual launch-vehicle monitoring procedures and aircraft ejection seats that could be manually triggered if the launch vehicle malfunctioned or if the spacecraft parachute failed during descent.

The enormous TNT equivalency of a "worst case" Saturn booster explosion placed a Mercury-like escape rocket on the Apollo spacecraft. Then concern fora growing control-system failure, coupled with maximum aerodynamic pressure, prompted inclusion of an automatic abort system.

Two minutes after lift-off, this automatic system is manually disabled, and the booster firing is terminated manually in the event of a malfunction. Crew displays include the status of launch-vehicle engines and tank pressures. The launch vehicle can be controlled manually if the Saturn inertial platform fails; this ability did not exist in Mercury or Gemini, but was introduced after several years of research and analysis.

Apollo rendezvous, formation flight, and docking maneuvers resemble closely those developed in Gemini. (This, of course, was a major reason for Gemini.) Another significant Gemini carry-over is the backup rendezvous procedure, which can be used if the onboard radar, inertial platform, or computer should fail.

Placement of rendezvous maneuvers for optimum orbital lighting took advantage of Gemini experience.

Gemini extravehicular activity revealed an anomaly in simulation, which was corrected for Apollo. Short-duration zero-g aircraft parabolas did not reveal the fatiguing effect of long-term tasks in a Gemini pressure suit. For the later Gemini flights, water-immersed simulations (fig. 4-1) provided realistic long-term zero-g workloads. This type of simulation enabled the development of Apollo contingency extravehicular activity (EVA) transfer procedures. An Apollo contingency transfer is required if the lunar module (LM) cannot be docked to the command module (CM) after lunar-orbit rendezvous.

TODO: INSERT - Figure 4-1.- Astronaut trains underwater in simulated zero-g condition in waterimmersion facility. Astronaut wears weights on shoulders, wrists, and ankles. Total ballast is about 180 pounds.

Although the spacecraft guidance system normally specifies the proper reentry roll angle that is required to maneuver down range or cross range to the target, Gemini and Apollo employ basically the same backup techniques for using the earth horizon to monitor manually and achieve proper reentry roll angles for ranging.

PROCEDURES APOLLO INTRODUCED

Apollo of course encompassed the lunar landing. Although helicopter experience indicated that low-speed maneuvering and vertical descents were straightforward, the lunar landing involved a much higher approach velocity and descent rate, potential visibility problems, and a 1/6g maneuvering environment. Because of the difficulty in training for manual landings in this environment, there were suggestions that we should accept automatic landings and the attendant probability of abort, if the automatic system targeted the spacecraft to a boulder or crater.

The obvious desire to land rather than to abort triggered a major effort to build a freeflight training vehicle (fig. 4-2) which would fly in the atmosphere of the earth and would simulate the 1/6g handling characteristic of the LM. Early flights with this vehicle impressed the pilots with the unusually large pitch and roll angles required to achieve and null translational velocities.

The flights also indicated that from altitudes of approximately 500 feet, the vehicle could be maneuvered to avoid obstructions after several familiarization flights.

Lunar-surface EVA likewise had no analogy in previous programs. Improved mobility of the Apollo suit, on the other hand, encouraged rapid development of lunar-surface EVA procedures. Three techniques were used to investigate the effects of 1/6g:

The KC-135 aircraft (fig. 4-3), the overhead-supported gimbaled harness (fig. 4-4), and the waterimmersion facility.

Used in a complementary fashion, these simulation devices yielded results which indicated that 1/6g maneuvering stability was no particular problem; in fact, if one started to fall, it was easy to recover because of the low falling acceleration.

TODO: INSERT - Figure 4-2. - Lunar landing training vehicle trains crews for last 500 feet of altitude in critical moon landing phase.

TODO: INSERT - Figure 4-3.- Lunar module mockup in stalled in KC-135 aircraft. Support structure takes loads imposed in 2-1/2g pullup, after which zero g is achieved for 20 to 30 seconds ona parabolic flight path.

Another significant procedural difference between Gemini and Apolloconcerned the ability of the crew, in the event of a ground communications failure, to navigate with the onboard sextant/ computer and to calculate spacecraft maneuvers for safe return to the earth.

Critical Gemini maneuvers were made within the communications range of ground stations, but the Apollo lunar-orbit retrograde burn and the critical transearth burn occur behind the moon, where crew procedures cannot be monitored by the ground.

NAVIGATION, GUIDANCE AND CONTROL PROCEDURES

Some 40 percent of crew training involves becoming proficient in the use of the three spacecraft navigation systems (one in the CM and two in the LM) and the four guidance systems (two in the CM and two in the LM).

The crew interfaces chiefly with these systems through computer keyboards which are about half the size of a typewriter keyboard. Approximately 10 500 individual computer key strokes are required to complete the lunar mission.

The crew must activate individual programs within the computer to execute launch, midcourse navigation, spacecraft propulsion maneuvers, lunarlandmark tracking, lunar descent, lunar platform alinement, ascent, rendezvous, and reentry. Within each program, there are many routines or options. The computer display and keyboard includes three 5-digit registers through which the crew observes displays (such as total velocity, altitude, and altitude rate during the lunar descent).

TODO: INSERT - Figure 4-4.- Familiarization run on the mobile partial-gravity simulator used for lunar walk indoctrination.

The primary control systems in both the CM and the LM include digital autopilots which are adjusted through keyboard activity.

The crew selects optimum jet configuration, attitude deadband, and maneuver rates. Large variations in vehicle configuration throughout the mission require the crew to be very familiar with control characteristics and handling qualities, which range from sluggish to sporty over the interval from initial booster staging to docking of the lightweight LM.

Much of the crew preflight time goes into reviewing propulsion and guidance malfunction procedures. In this work, alternate system displays are compared to the primary display. If it appears that the primary system has failed, the crew manually makes a switchover.

As an example of system redundancy, the initial lunar-orbit insertion maneuver is made with the main service module (SM) engine under automatic control by the primary guidance system, but failure of the primary system can be backed up manually by using the stabilization and control system.

If the SM main engine fails during the burn, two crewmembers transfer to the LM, activate the systems, and ignite the descent-stage engine to place the two spacecraft on a return-to-earth trajectory.

If the LM descent-stage engine fails, the descent stage is jettisoned, and the LM ascent-stage engine is ignited.

The crew controls docked configuration from the LM manually by using the reaction-control system in a translation mode, rather than an efficient attitude-control mode (because of the shifted center of gravity of the docked configuration), A primary guidance system failure of the LM can be backed up by the abort guidance system; as an ultimate control-system backup, either vehicle can be controlled in a manual mode in which the LM pilot control inputs go directly to the reaction jets with no rate-damping feedback.

To provide the crew with this depth and ability to monitor, switch, and control may seem unduly redundant; however, this depth of capability has provided a verification of the adequacy of the primary procedures. Several changes to the primary rendezvous procedures were made, so that the maneuvers could be more easily monitored and remain consistent with the backup procedures.

During descent, the landing site comes into view at the bottom of the LM window at an altitude of 7000 feet, a range of 4 miles, a velocity of 450 fps, and a descent rate of 160 fps.

By observing through his window, the commander (in the left-hand crew station) determines if the guidance is targeted to the correct landing area. If not, he can incrementally change the spacecraft flight path 2° laterally and 0.5° up range or down range, by actuations of the right-hand attitude controller.

In the right-hand crew station, the LM pilot is closely monitoring the altitude, the altitude rate, the lateral velocities, and the remaining propellant and is updating the backup guidance system altitude. He calls out altitude and altitude rate to the commander, All of these parameters are compared to nominal and to the limits set as abort criteria.

The commander normally takes control in a manual atitude-hold mode at an altitude of approximately 500 feet. At this point, horizontal velocity has dropped to 70 fps and the vertical velocity to 17 fps. The rate of descent is controlled at this time by making discrete inputs to the guidance system at a rate of 1 fps per switch cycle.

Normally some 2 to 4 percent of the descent propellant remains after the landing. Aircraft fuel reserves at landing are considerably greater. Clearly, a critical Apollo crew procedure is propellant monitoring.

The percentage of descent propellant remaining is computed and displayed on digital read-outs. With 2 minutes of propellant remaining, a tank-level sensor is uncovered and a warning light is displayed. The LM descends at a rate of approximately 3 fps.

After touchdown and engine shutoff, the crew immediately checks the status of all systems in preparation for an emergency lift-off.

If all propulsion, environmental, and guidance systems are satisfactory, preparations are made for powering down the spacecraft and for lunar surface exploration, The subsequent ascent from the lunar surface involves spacecraft power-up, inertial-platform alinement, and a long series of checklist procedures which terminate with descent-stage separation and ascentengine ignition, During this phase of lunar activity, the two-man crew performs the functions of the entire launch complex and blockhouse crew at Cape Kennedy.

INFLIGHT PHOTOGRAPHY

Besides providing a documentary record of the flight, inflight photography has become a vital part of future mission planning. Television pictures taken several years ago by Orbiter spacecraft formed the base line for constructing the flight maps and the simulator relief model. However, because full coverage of high-resolution pictures does not exist for all of the Apollo landing sites, it has been necessary to obtain additional 70-millimeter still photography of some future sites. (See fig. 4-5.)

Coordination of this photography requires careful planning to schedule the photography passes at the proper sun angle and to minimize usage of critical spacecraft attitude-control propellants.

TODO: INSERT - Figure 4-5.- Apollo 12 landing and ascent model of Surveyor and Snowman craters as seen from 1800 feet.

SIMULATION

The development of the Apollo simulation program and associated trainers closely paralleled the development of the Apollo flight hardware and the increasing mission complexity. As flight operations phased from Gemini to Apollo and as the Apollo flights progressed from single to dual spacecraft operations, from earth-orbital to lunarorbital activities, and finally to the lunar landing, the scope and capability of simulations matured to keep pace with the increasing complexity.

The Gemini Program provided an excellent beginning for Apollo training, because its progress in accurately simu lating and adequately training flight crews in the launch, rendezvous, and entry modes was directly applicable. In fact, the first Apollo part-task simulators were converted Gemini simulators.

The computer complex and infinity-optics system from the Gemini mission simulators were integrated with simulated crew stations for the CM procedures simulator (CMPS) and the LM procedures simulator shown in figure 4-6.

The simulated Agena target vehicle and Gemini spacecraft were replaced with the CM target mockup and the LM crew station on the translation and docking simulator, shown in figure 4-7. The dynamics crew procedures simulator, shown in figure 4-8, was converted to the CM crew station for launch and launchabort training, shown in figure 4-9.

TODO: INSERT - Figure 4-6.- Command module procedures simulator and lunar module procedures simulator.

The combined flight of two manned spacecraft during the Apollo 9 mission was a major step in all aspects of flight operations. A corresponding major accomplishment was the addition of the LM mission simulator (LMS), shown in figure 4-10, into the trainer complex and integration of the LMS with the CM mission simulator (CMS), shown in figure 4-11.

The tie-in between the mission simulators and the Mission Control Center at the NASA Manned Spacecraft Center (MSC) marked a significant step in realistically conducting space-flight dress rehearsals. The simulations required synchronization of 13 large digital computers, operating together in real time.

TODO: INSERT - Figure 4-7 - Translation and docking trainer simulates lunar module active docking over last 100 feet of separation distance.

TODO: INSERT - Figure 4-8 - Dynamics crew procedures simulator.

TODO: INSERT - Figure 4-9 - Simulated command module crew station for the dynamics crew procedures simulator

TODO: INSERT - Figure 4-10 - Lunar module mission simulator with crew station and Farrand optical systems for three windows.

TODO: INSERT - Figure 4-11 - Visual optics and instructor station for command module mission simulator.

The progression of Apollo 8 and 10 to the lunar sphere of influence and the integrated operation of the two spacecraft in lunar orbit required more simulation capabilities, such as additional trajectory equations, new simulator operating modes (fast time, step ahead, safe store) and a complete new set of out-the-window scenes for the crews,

Apollo 11, of course, introduced the final operational phase, landing on the lunar surface. To simulate the lunar landing, it was necessary to build a lunarterrain model (fig. 4-12) for precise training on the mission simulators of the final-approach and manual-touchdown phases. It was also necessary to use the lunar landing (1/6g) free-flight trainer.

The scope and complexity of the Apollo missions necessitated a comprehensive procedures-verification and crewfamiliarization program through a variety of part-task and mission simulations.

As mentioned previously, some of the Gemini procedures directly carried over to Apollo, but numerous new areas required further analysis and crew verification. Launch-abort monitoring and launch-vehicle control (Saturn V launch vehicle) were analyzed in detail at the NASA Ames Research Center and by contractor personnel in separate studies before the backup control of the launch vehicle from the spacecraft was developed.

The first flight incorporating this backup mode was on AS-505 with the Apollo 10 flight. The ability to provide pilot control from the spacecraft for the Saturn IVB stage during the translunar injection maneuvers was thoroughly checked out by engineers and pilots on the DCPS and CMS before the Apollo 10 mission.

TODO: INSERT - Figure 4-12.- Apollo 12 landing and ascent visual simulation system

Considerable revisions were made in the CM computer flight program after the Apollo 7 flight to improve the guidance and navigation logic during rendezvous. Some 1200 man-hours and 100 machine-hours were spent by the MSC engineers with the CMPS in working out the optimum crew displays, procedures, and tracking schedules for the new flight software.

Many more hours were spent with the flight crews on the CMPS and CMS familiarizing and training them for the Apollo 9 mission.

In lunar descent and landing, simulation and training emphasized the monitoring of the primary guidance system and the takeover by the commander for the final phase of manual control to touchdown. More than 220 landings were flown on the LMS by two astronauts (who subsequently flew the first and second actual lunar landings) solely to determine the best hand-controller authority for LM attitude-control system.

Development of the activation procedures of the passive LM in flight (the first such requirement in manned space flight) necessitated a comprehensive and detailed systems simulation provided only by the LMS. The LM integrated activation checklists were worked out and verified for the two navigation systems, two radar systems, and three propulsion systems.

The maintenance of a high degree of mission-simulator fidelity was emphasized. No part of the system was more critical in this respect than the simulated guidance and navigation system.

The use of an interpretive approach to simulate the Apollo guidance computer on both the CMS and the LMS provided not only exceptional fidelity but also the ability to accept late software changes and mission-peculiar tapes and to introduce these rapidly into the training.

Numerous full-dress rehearsals were executed with the flight crews in the mission simulators at Cape Kennedy and the flight control team in the Mission Control Center at MSC. This training used the latest possible operational trajectory and spacecraft data to ensure complete verification of both flight and ground programs and comprehensive familiarization by the entire flight operations team.

Many simulations were executed with trainers other than the spacecraft mission and part-task simulators. Zero-g simulation of EVA contingency transfer by using the water-immersion facility at MSC (fig. 4-1) was an extension of the experience and techniques derived during Gemini.

The partial-gravity simulator, which used a servoed, vertically mounted suspension system to take up five-sixths of the weight of the suited crewman, permitted long-duration 1/6g simulations. A truck-mounted device which used this same simulation technique allowed training at various traverse rates (fig. 4-4).

Many training hours went to one-g walk-throughs with mockups of spacecraft and equipment. Specific areas of training ranged from onboard stowage, photographic equipment handling, and docking-tunnel probe and drogue operations to full-blown lunar-surface EVA walk-throughs. The lunar-surface walk-throughs included special 1/6g mockups of the Apollo lunar-surface experiment package and the lunar-surface tools.

FLIGHT PLANNING

Apollo flight planning involves a much more complex procedures-integration task than did Mercury or Gemini, because of the large number of crew tasks associated with two manned spacecraft.

Four or five months before launch, the flight planner must take the list of mission objectives, the preliminary launch-vehicle trajectory, the preliminary operational trajectory, the crew work and sleep constraints, and network tracking constraints and must integrate the numerous systems procedures of the manyphased Apollo mission. Because of the requirement to minimize use of reaction control propellant, hydrogen, and oxygen, several iterations are required to establish the proper timing of maneuver rates and spacecraft power configurations during the mission,

Original time line estimates for the various mission phases derive from the mission simulators in which all spacecraft systems are dynamically simulated. Spacecraft housekeeping, EVA preparation, and post-EVA procedures are worked out in high-fidelity mockups. The spacecraft stowage list itemizes 445 pieces of equipment, each of which must be procedurally integrated into the flight plan.

Some 1300 copies of the flight plan are distributed to NASA and contractor personnel 3 months before the launch. If the flight plan is considered in a broad context to include all onboard paper including time lines, checklists, and graphics, the package weighs about 20 pounds. For each Apollo mission, hundreds of changes were made and verified on these data during the last 3 months before flight.

Many changes reflected differences in the final trajectory, procedural refinements derived from simulation experience, and correction of anomalies on the previous flight.

We set a rigorous procedures change discipline for 2 months before the flight. This controls suggested alternate techniques which may appear preferable for a particular subsystem, but must be considered in terms of the interrelated operational time line before acceptance.

We also establish a rapid procedures information loop during the final simulation phase, which also begins 2 months before the launch. This simulation activity involves flight planners, flight crews, mission simulators, flight controllers, and the tracking network. Normal and emergency procedures are thoroughly tested.

The Apollo flights speak for the value of this simulation effort in verifying late changes, validating procedures, and establishing crew readiness.

5. FLIGHT CONTROL IN THE APOLLO PROGRAM

By Eugene F. Kranz and James Otis Covington - Manned Spacecraft Center

Apollo 12 lifted off the pad at 11:22 a.m. e.s.t. on November 14, 1969. At 36.5 seconds after lift-off, lightning struck the command and service module (CSM), disconnecting all three fuel cells from the main buses and placing the main loads on two of the three batteries which ordinarily supply reentry power (fig. 5-1).

Fuel cell disconnect flags popped up, and caution and warning lights winked on to alert the crew. With the decrease in the main bus power, the primary signal conditioning equipment ceased operating as it is meant to do when main bus voltages drop to approximately 22 volts. The ground simultaneously lost telemetry lock.

At first, flight controllers thought the plume of ionized rocket-exhaust particles had blacked out the telemetry signal. However, they abandoned this theory when the crew reported the warning lights.

The primary signal conditioning equipment controls most electrical-power measurements; therefore, there was little information with which to diagnose the trouble.

At 52 seconds after lift-off, the crew reported losing the spacecraft platform.

At 60 seconds, the ground locked on to the telemetry signal again, and the CSM electrical and environmental systems engineer, John W. Aaron, asked the crew to switch to the secondary signal conditioning equipment to get additional insight into the electrical system. At 98 seconds, the crew made the switch, restoring all telemetry. Aaron then noted from his data display that three fuel cells were disconnected and requested the crew to reset them. Fuel cells 1 and 2 went back on the line at 144 seconds; fuel cell 3, at 171 seconds. Main bus voltages rose to approximately 30 volts, and all electrical parameters returned to normal.

Throughout the entire launch the Saturn launch vehicle performed normally. The spacecraft entered the proper orbit, and the crew and ground began preparing for translunar injection.

The quick response to the Apollo 12 outage came about not as a result of blind luck but of careful planning, training, and development of people, procedures, and data display techniques by those responsible for flight control.

The flight control organization devotes a majority of its time and resources to careful premission planning and detailed training. This premission preparation culminates in simulations of critical phases of the mission with the flight crew. These simulations prepare the flight controllers and the flight crew to respond properly to both normal and contingency situations.

TODO: INSERT - Figure 5-1 - Electrical power display when Apollo 12 was at an altitude of 6000 feet.

Following one of the basic Flight Control Division philosophies, operations personnel take part in planning a mission from its conception through its execution. They participate in two areas where their operational experience contributes greatly: (1) in the early stages of mission design and (2) in setting basic design requirements for various spacecraft systems. As a result, both spacecraft hardware and mission design have optimum operational qualities.

The true operational phases of the Flight Control Division begin after the spacecraft design reaches completion and NASA has committed itself to constructing flight vehicles and launch facilities. The development of mission operations starts after sufficient information about the detailed design of the space vehicles becomes available. The development takes 2 years and is divided into four phases, as shown in figure 5-2: mission development, detailed planning, testing and training, and real-time operational support of a flight.

6. ACTION ON MISSION EVALUATION AND FLIGHT ANOMALIES

By Donald D. Arabian - Manned Spacecraft Center

The aim of mission evaluation is to extract the maximum amount of information from each flight for use in managing and planning future missions and programs. Its products also go before the scientific community and the public.

It is not surprising that a complex vehicle, such as a spacecraft, experiences peculiarities and system problems that have not been considered previously. The prime task of the mission evaluation team during a mission, therefore, involves identifying and understanding these peculiarities and problems and determining what action should be taken.

After a mission, the evaluation team also has responsibility for (1) flight anomaly investigation and resolution and (2) preparation and publication of the mission report.

For the mission evaluation, the many engineering disciplines involved in Apollo are represented by groups of specialists, each managed by a NASA team leader. In general, the specialists have experience with a particular system from the initial design conception through development and testing of the hardware. Consequently, they have an intimate knowledge of the system operation and limitations.

The specialists are selected both from contractor and from NASA engineering organizations and work as an integrated team. Before a mission, the selected team participates in certain simulations with Mission Control Center personnel. This training serves to integrate the two organizations into a single operational unit.

The responsibility of each team leader includes coordination with other team leaders to ensure that any solution or recommended course of action for his system does not jeopardize other systems. The team leaders report to the evaluation team manager, who is responsible for the overall operation of the team.

The team manager is assisted by senior contractor engineering managers who have immediate access to the company facilities to provide any necessary support. All inputs and requests by the team leaders are integrated and reviewed by the team manager and by contractor engineering management. The team manager interfaces with the Flight Director through the Apollo Spacecraft Program Manager. During a mission, the team mans assigned positions in the mission evaluation room (fig. 6-1) around the clock.

To support the mission evaluation team effort at the NASA Manned Spacecraft Center (MSC), the prime contractors maintain similar teams of specialists at their facilities for analyses, tests, and related activities. These contractor teams are also under the direct management of the mission evaluation team at MSC.

A typical example of the activity associated with these supporting teams occurred when a lightning discharge on Apollo 12 caused the loss of inertial reference (tumbling) of the inertial platform. In this instance, the support team at the Massachusetts Figure 6-1.- Mission evaluation room with team leaders" table in the foreground and discussion of a system problem in the background.

TOOD: INSERT - Figure 6-1

Institute of Technology performed a test to simulate the conditions so that it could be understood how the potential discharge caused the platform to tumble. It was important to have rapid verification that the platform had not been damaged. A quick response was received by the evaluation team, and the mechanism that had caused the conditions in flight was determined.

Many other times during Apollo flights, the evaluation team has provided test information that was valuable in understanding a problem and determining the best course of corrective action. In carrying out its task, the team must be constantly aware of the total system performance as the mission progresses.

The team monitors data that are received by the tracking stations, transmitted to and processed by the Mission Control Center, and displayed in the Mission Evaluation Room on closed-circuit television. In addition, air-to-ground voice communications are monitored.

The frequency of the Apollo flights demands that anomalies be quickly identified and resolved so that prompt corrective action may be taken. Analysis of the data for problems and anomalies must be compressed, therefore, into a relatively short period. Also, within this time frame, the anomalies must be analyzed to the extent that the mechanism associated with the cause is clearly understood. Of course, anomalies which involve flight safety or which would compromise the mission require corrective action before the next flight.

The first problem is to identify the anomalies. Many anomalies are easily recognized because a component has failed to operate. The most difficult cases, however, appear when the data from the system are not sufficient for an understanding of all the normal operating characteristics. A typical example of this condition occurred during the Apollo 7 mission when the battery recharging characteristics fell below predicted levels throughout the flight.

Preflight tests had been conducted at the component level, but an integrated test of the entire system, as installed in the spacecraft, had not been included. Postflight tests, using the actual flight hardware, showed the same characteristics as those experienced in flight. A detailed analysis showed that the line resistance between components of the system greatly controlled the amount of energy returned to the battery. The corrective action for this anomaly was to require that integrated system tests be performed to establish overall system characteristics of each installation and thus ensure adequate battery recharging. In this case, if the total system operating characteristics had been established previously, there would have been no problem.

Sometimes, also, data will not support an accurate analysis of a problem. This situation occurs because of insufficient flight instrumentation or absence of recorded data. The mission evaluation team, in attempting to focus on the anomalous condition, must rely on the history compiled from previous missions and on the experience gained from tests and checkout and knowledge of the failure history.

After an anomaly is identified, the cause and the corrective action must be identified. The approach may be experimental or analytical or both.

The depth and the extent of the analysis vary considerably and depend on the significance of the problem. For example, on the Apollo 6 mission, a structural failure occurred in the adapter that holds the service module to the launch vehicle and also houses the lunar module during the ascent portion of the flight.

This adapter consists of the largest honeycomb structure designed and developed for any application. Longrange photographs show that the structure lost the outer face sheet from the honeycombsandwich panel by explosive separation. (See fig. 6-2.) Response to the effects was obtained from many measurements in the command and service module, lunar module, and launch vehicle.

In resolving this problem, four possible causes were investigated: structural dynamics of the launch vehicle, the dynamic loads of the lunar module, dynamic modes of the adapter shell itself, and quality of manufacture.

The investigation first focused on an understanding of the coupled vibration modes and characteristics of the launch vehicle and spacecraft. Extensive vibration tests ruled out vibration as a cause.

Further tests and analyses indicated that the internal pressure of the sandwich panels could have caused the failure. If a large unbonded area existed between the honeycomb and the face sheets, then aerodynamic heating of the air and moisture entrapped in the panel could have caused a pressure buildup in the honeycomb, separating the face sheets in an explosive manner.

The most probable cause of this condition was traced to the manufacturing process (the possibility of unbonded face sheets remaining undetected).

To circumvent the problem in the future, the inspection procedures for the structure were changed. Also, cork was placed on the outer surface of the adapter to reduce aerodynamic heating, and small vent holes were drilled through the inner face sheet into the honeycomb to reduce internal pressure.

Analysis of this anomaly involved testing full-size equipment under dynamic and static conditions, performing many experimental tests of smaller test articles, and conducting extensive structural analysis at the various NASA centers and at many contractor organizations.

This effort verified that the structural integrity of the adapter was satisfactory for subsequent missions and established that the failure was not caused by a design deficiency.

TODO: INSERT - Figure 6-2.- Long-range photography of adapter failure during the Apollo 6 mission.

The other extreme of treating a problem concerns anomalies for which no corrective action is taken because of the nature of the failure.

For example, on the Apollo 11 entry-monitor system, an electroluminescent segment of the velocity counter would not illuminate.

A generic or design problem was highly unlikely because of the number of satisfactory activations experienced up to that time. A circuit analysis produced a number of mechanisms that could cause this failure, but there was no failure history in any of these areas. This case is a typical example of a random failure.

The basic design concept of the spacecraft overrides such failures by providing alternate procedures or redundant equipment. Consequently, this type of failure does not demand corrective action.

Causes of anomalies involve quality, design, and procedures. The quality items include broken wires, improper solder joints, incorrect tolerances, improper manufacturing procedures, and so forth. The structural failure of the adapter on the Apollo 6 mission, previously discussed, illustrates such a quality problem.

System anomalies caused by design deficiencies can generally be traced to insufficient design criteria. Consequently, the deficiency can pass development and qualification testing without being detected, but will appear during flight under the actual operational environment.

A typical example of a design deficiency is the fogging of the Apollo 7 command module windows between the inner surfaces of the three window panes. A postflight examination showed the fogging to be a product of the outgassing of the room-temperature-cured sealing material used around the window. The design criteria did not require the sealing material to be cured; curing would have prevented outgassing in the operating temperature and pressure environment.

Procedural problems in operating various systems and equipment are ordinarily corrected simply. For example, an incorrect procedure was used to chlorinate the crew's drinking water. This resulted in an improper mixing of the chlorine and water, giving the water a strong chlorine taste. The procedure was revised, and the water no longer had an objectionable taste.

While a mission is in progress, the scope of a problem must be defined before action is taken; that is, the problem must be isolated to the extent of establishing possible effects on the spacecraft systems.

Every effort is concentrated on developing a procedure that permits the mission to continue despite the problem. Complete understanding and analysis of the problem frequently require postflight data analysis, crew debriefings, or testing of the spacecraft hardware.

When lunar module hardware exhibits a problem, it may be returned for postflight analysis and testing, provided the command module has stowage space available and the lunar module gear fits the space.

For example, the color television camera that failed on the lunar surface during the Apollo 12 mission was scheduled to be left on the lunar surface but was returned to earth for postflight testing.

When postflight testing cannot be done because the hardware cannot be returned to earth (e.g., the lunar module and service module hardware), every effort is made to perform inflight tests to understand and isolate the cause of the failure.

A typical case occurred during the Apollo 12 mission when the high-gain antenna, mounted on the service module, occasionally exhibited reduction in signal strength.

The evaluation team developed a test to isolate the anomaly to specific areas and components of the high-gain-antenna system. The test, conducted later in the mission, produced data which, combined with analysis, isolated the cause.

An additional search for anomalies is conducted when the command module is returned to the contractor's facility for a general inspection.

Those systems and components identified as having a problem or failure are removed from the vehicle and tested to establish the cause, or tests are performed with the affected equipment in position in the command module. In general, these postflight tests are limited to those required for an understanding of flight problems.

The concerted effort on anomalies during the flight continues after the mission until each problem is resolved and corrective action is taken. This activity requires close coordination and cooperation between the various Government and contractor groups. Emphasis is placed on prompt and exact analysis for the understanding and timely solution of each problem.

To accomplish this task, a problem list is maintained during and after each flight. This list contains a discussion of each problem, the action being taken to resolve it, the engineer or contractor responsible for completing the action, and the anticipated closure date.

After the flight, the most significant anomalies are published in the 30-Day Anomaly and Failure Listing Report. This report identifies the anomaly, discusses the analysis, and identifies the corrective action to be taken.

The Mission Report, which is published approximately 60 days after a flight, includes a section which discusses all significant anomalies and corrective actions. The less significant problems are discussed in the appropriate sections of the Mission Report. A separate report covers anomalies not resolved before publication of the Mission Report.

The Mission Report serves as an historical record of the pertinent events of the mission and includes discussions of systems performance, crew activities, flight anomalies, and scientific experiments. Supplements to the Mission Report are published to present detailed analysis of the engineering systems, medical aspects, and scientific aspects of the mission.

The techniques used in Apollo for assessing systems performance reflect significant advancements over those used in previous manned programs. The method of handling flight anomalies, including the depth and extent of analysis, has been sufficient for the time and economy constraints imposed by the program.

The Apollo concept has proved to be very effective in organizing many contractors and federal organizations into one central team for the real-time support and postflight evaluation of each mission.

These concepts enabled the Apollo Program to advance at the rate required to achieve the national goal of landing man on the moon before 1970.

7. TECHNIQUES OF CONTROLLING THE TRAJECTORY

By Howard W. Tindall, Jr. Manned Spacecraft Center

Someone not associated with the Apollo Program cannot imagine how much planning precedes each mission. Planning is truly an immense task, which takes many different forms.

Basically, this is another report about mission planning. It is not about the selection of launch windows, trajectories to be flown, landing sites, or how to make the lighting conditions right. Neither does this report specifically involve preplanning the crew time line; defining when pieces of equipment should be turned on, when the crew should sleep, eat, work, perform on TV; and so forth.

The planning this report is concerned with does interact intimately with these, but it is planning of an entirely different type.

Generally speaking, it is the planning required to define how the trajectory is controlled once the mission objectives, trajectory plan, and crew time line have been established: to figure out exactly how the various components of the guidance, navigation, and control (GNC) systems and, to some extent, the engines are to be used during all phases of each of the manned Apollo missions.

Unquestionably, activities associated with trajectory control constitute by far the largest piece of operational overhead in any Apollo mission.

That is, in the process of achieving the real objectives of a lunar-landing mission (such as placing experiments on the lunar surface, picking up rocks, and taking pictures) you will find no other inflight activity that approaches trajectory control in its capacity to absorb planning and training energy.

Usually, when conflicts arise, the trajectory-control activity takes priority over everything else, such as systems management, crew work and rest'cycles, and experiments (including the lunar-surface work).

Since trajectory-control activities make up such a large part of every Apollo mission, the manner of conducting them has an impact on almost every other facet of the mission, even on aspects that seem remote, such as electrical-power management, thermal control, and consumable budgeting. As a result, it is necessary to consider all of these things in the development of the overall trajectory-control procedures, which we call mission techniques.

Also, it is important that almost everyone in the Apollo world knows how we intend to do these things, since we often impact their plans.

One basic characteristic in the design of the overall Apollo guidance and navigation (G&N) system must be recognized before I proceed. Namely, the ground-based tracking, computation, and control-center facilities not only form an integral part of the G&N system — being the prime source of essential data to the spacecraft systems — but in some instances, the ground will be the only source of data.

Specifically, with the exception of rendezvous and inertial sensing during maneuvers, all trajectory determination is done on the ground. This is the task of determining the position and velocity of the spacecraft and its relation to where we are trying to go — braking into lunar orbit, trying to land at a specific site on the moon, hitting the earth atmospheric-entry corridor, or whatever.

Also, with the exception of the rendezvous, the ground is the only source of maneuver targeting. By maneuver targeting, I mean the task of figuring out the exact magnitude and direction and the time at which each maneuver must be executed in order to perform the mission.

The two essential functions, orbit determination and targeting, cannot be performed on board the spacecraft. The reason I am making sucha big point about this is probably obvious. Putting together mission techniques with a G&N system like that is much more complicated that if the whole job could be done on board the spacecraft without external assistance. A tremendous amount of data must be relayed back and forth between the spacecraft and the ground, and the content and format of these data have to be complete and precisely compatible.

Also, instead of only the three crewmembers being involved in the operation — that is, understanding and carrying it out — we must involve the entire flight-control complex. This makes the inflight job, of course, more complicated — but, believe me, it makes the planning job something else, too. Many diverse opinions about the planning task are expressed without hesitation or inhibition.

There is an important point I would like to make regarding operational philosophy, since it influences the mission techniques so much. It must-be obvious from the way the missions have gone so far that the spacecraft equipment is really put together right. A tremendous amount of attention has been devoted to design and testing to make sure that everything will work as it is supposed to.

On top of that, in order to provide even more confidence that the mission may be conducted successfully and safely, all of the critical systems are backed up by other systems. (In the GNC area, the backup systems, without exception, are of an entirely different design than the primary systems. Thus, they are operated entirely differently, which almost doubles the planning. )

Accordingly, you might think that the mission techniques for a spacecraft like Apollo would be based on the assumption that the equipment will work. The fact is, however — right or wrong — that our operational planning on all manned space flights so far has been based on a philosophy of cross-checking and monitoring every critical system and operation to make sure that the systems are performing properly.

Operations must all be planned out before a mission — just what will be done if the primary or backup system (or both) fails or is degraded. Also, we must plan what can be done with whatever components of these systems might still be working, with the data shipped from the ground and from charts and simple mathematical techniques developed for the crew, and with any other data sources not ordinarily used, such as the view out the windows.

On the other hand, when you consider that we deploy two sophisticated spacecraft, each of which has extensive capabilities, the imagination explodes with the possible ways things could be done as various components fail.

Also, when you multiply this multitude of choices by the number of uniquely different phases in a lunar-landing mission, you find that the task of developing the techniques could expand indefinitely.

Obviously, if unconstrained, this whole business could get out of hand.

Not only could it cause an inexcusable waste of resources, but it could also introduce a myriad of complicated procedures — tier upon tier of alternate modes of operation which would go beyond the ability of the crew and flight controllers to understand, train with, and use.

These two rules bound the problem:

Be prepared to recognize and react under any condition to save the crew and the mission, but do not carry this business to the point of actually reducing reliability by introducing confusion or the incomprehensible into the system.

If I were to look back and judge how we actually did on Apollo, I would say we went a little too far — not much, but some. And, of course, it is easier to look back.

The Mission-Technique Development Task: How do you decide how to fly an Apollo mission?

If the inertial reference system is drifting a little, what do you do about it?

If it drifts a lot, what do you do about that?

What is the switchover point between a little” and a "lot"?

Let us say you are in the middle of a rendezvous with a maneuver coming up and you have three sources of data each telling you what the maneuver should be.

Also, your friend in the other spacecraft has a solution, as do the people on the ground.

How do you choose among these solutions, if they differ? It is specific questions like these — and there are literally hundreds of them — that the mission-technique development process was set up to answer to everyone's satisfaction. Let me describe the development process and its products.

First of all, the task involves pinning down precisely how well the systems must work or if they are even needed to achieve mission success or to assure crew safety. This can become a tough job.

Certainly, we do not want to abort a mission if it is safe to continue, but we must be sure it is safe, even if something else fails. To some extent, the decisions depend on where you are in the mission.

For example, we had as an Apollo ll mission rule that we would not separate the lunar module (LM) from the command and service module (CSM) in lunar orbit if the rendezvous radar was not working.

We felt that our lunar-orbit experience and LM systems maturity were not adequate at that time to start intentionally a rendezvous situation without the rendezvous radar.

On the other hand, after the two spacecraft had been separated and descent had started, there was no reason to terminate the mission because of a rendezvous-radar failure. By that time, we would already be committed ourselves to performing the rendezvous without it and so might as well press on.

Thus, some mission techniques can be chosen by applying common sense to the situation.

Table 7-I illustrates one of the mission-technique products dealing with this kind of situation by listing which pieces of equipment must be working to continue at several go/no-go points in lunar orbit.

If a piece of equipment is obviously broken, it is easy to apply the mission rules agreed to before flight, such as those given in table 7-I. However, if it is just not working up to par, then what? In this case, the go/no-go decision must reflect system requirements in terms of the mission phase.

A good example of this was the preparation for the LM descent to the lunar surface on Apollo 11.

Although all three gyroscopes in the primary guidance system inertial platform have identical design, the performance required of each was markedly different. Analysis showed that a misalinement about the pitch axis as large as 1° does not degrade the descent guidance unacceptably as long as the landing radar is working, but that just a 0.5° misalinement renders the guidance system incapable of performing a safe abort from the descent trajectory.

So we established safe-abort ability as the criterion for computing the limiting pitch-axis gyroscope performance.

Specifically, since the system is alined approximately an hour and a half before powered descent, we were able to fix 0.33 deg/hr as the maximum acceptable gyroscope pitch rate (the 30 Apollo gyroscope performance is 0.1 deg/hr).

TABLE 7-I - MANDATORY GUIDANCE, NAVIGATION, AND CONTROL SYSTEMS

(a) Lunar module systems

TABLE 7-1 - MANDATORY GUIDANCE, NAVIGATION, AND CONTROL SYSTEMS - Concluded

(b) Command and service module systems

8. FLEXIBLE YET DISCIPLINED MISSION PLANNING

By C. C. Kraft, Jr., J. P. Mayer, C. R. Huss, and R. P. Parten - Manned Spacecraft Center

Apollo mission planning extended over a period of approximately 8 years and encompassed many technical disciplines. It progressed from the early design-reference lunar mission in 1962 through the detailed operational planning of specific missions which began in 1964.

A pattern of mission-planning procedures, techniques, and management processes evolved that brought order to the many (and sometimes diverse) elements of the mission-planning team.

This report examines the Apollo mission-planning process, the important considerations that influenced the mission planners, and the evolution of the Apollo development flight schedule. The report concludes with a brief description of the more important panels, meetings, and working groups that helped to coordinate the mission-planning activities.

The planning and design of a mission, like the development of spacecraft hardware, proceeds from previously specified objectives and becomes constrained by system characteristics and operational considerations. Fundamentally, the process consists of a series of iterative cycles (fig. 8-1) in which a design is defined to increasingly finer levels of detail as the program progresses and as the flight hardware and operational considerations become better known.

Initially, mission design has the purpose of transforming broad objectives into a standard profile and sequence of events against which the space-vehicle systems can be designed.

Usually, incompatibilities arise immediately between system design and mission design, and these necessitate trade-off studies to arrive at a compromise.

Later, as hardware design solidifies, the emphasis of mission design becomes more operationally oriented, as the mission planners attempt to constrain their design to the operating capabilities of the space vehicles, ground-support facilities, and flight software.

The final planning phase, which occurs during the year before a launch, involves development of the detailed procedures, techniques, and mission rules which are used by the flight crew and ground control team for both nominal and contingency missions.

MAJOR CONSIDERATIONS

The considerations important to Apollo mission planners depended somewhat on the type of mission: manned or unmanned, development or operational.

For manned missions, the prime consideration was crew safety, whereas unmanned missions stressed mission success. For development missions, the prime consideration was to maximize the number of test objectives that could be met successfully, as opposed to operational missions, in which the number of final mission objectives was maximized.

The need for early decisions made the Apollo mission planners the driving force in stating the requirements for collecting and documenting all constraints. This need existed particularly during the development phase of the program. After the constraints were obtained, the development of mission techniques that would achieve the required test or mission objectives within them was necessary.

This development proved to be an iterative process which involved constraints, techniques, and objectives. It usually was carried to the time of final mission rules and flight plans. The iteration process and the consideration of possible failures or contingency situations entailed much alternate mission and contingency mission planning.

This type of planning activity reached a peak during the manned development missions.

Because of involvement early in the planning stage of a mission, the mission planners have been able to affect materially the development of both onboard and ground software.

In many cases, the software had to be tailored to a specific mission, although every effort was made to use the final program software wherever possible.

The software development schedule and costs can (and did) influence the design of some missions. In the early days of Apollo, separate programs were being developed for the unmanned Saturn IB and Saturn V test missions, because of distinct differences in the test requirements for the missions.

Later, it became apparent that the development of several different spacecraft and ground-software programs was not feasible, considering the schedule and costs for delivering the lunar-landing- mission program.

Because of this, the Saturn V mission test objectives were reexamined and were modified to accept the software used for the Saturn IB missions.

OPERATIONAL PLANNING CYCLE

Usually, the Apollo operational planning cycle began between 36 and 18 months before a launch, depending on the extent of mission complexity.

Because several organizations within NASA and throughout industry were participating in the analysis and design of the Apollo development and lunar missions, a need was identified for coordinating the efforts of all mission-planning elements.

In late 1964, an Apollo Mission Trajectory Documentation Plan was prepared, which defined the principal documents and information flow in the areas of mission planning and trajectory analysis. This plan became a major vehicle for coordinating the more significant mission-planning milestones throughout the Apollo Program.

The operational mission design was divided into three separate phases: mission definition, mission design, and flight preparation.

Schedules for the beginning and termination of each phase were established specifically to dovetail with the major hardware development, airborne- and ground-software development, and crew-training milestones.

Although each phase sometimes specified as many as 20 major milestones (documents), the nucleus of the plan involved only four basic milestones for each phase: a mission requirements document, an operational data book, a trajectory plan, and of course a flight plan.

The remainder of the milestones concerned abort and contingency planning, dispersion analyses, consumables analyses, and other special requirements, such as range-safety plans, orbital-debris studies, onboard-data-file information, and crew-simulator data.

Early in the Apollo Program, considerable difficulty was experienced in the exchange, standardization, and dissemination of critical data required both by and from the mission planners.

In view of the interdependency of most mission-planning milestone documents, the need for coordination and tight control in disseminating these data became acute.

As a result, the Apollo Spacecraft Program Office in conjunction with the hardware contractors and operational elements exercised strict controls and procedures in governing mission-planning data. As a part of this program, most organizations appointed key personnel on a full-time basis to support the data- management network.

In retrospect, this action must be regarded as vital in consolidating and strengthening the Apollo mission-planning process.

The next step in the Apollo operational planning cycle involves what came to be known as mission techniques, which were developed in the form of logic flows that detail each decision point, threshold value, and ground rule for each phase of both nominal and contingency missions. Section 7 discusses mission techniques in some detail.

In Apollo, as any other complex space mission, it is virtually impossible to develop premission plans for every contingency that could arise during flight.

Although specific plans are developed for all abort potentialities that involve crew safety, most alternate missions are developed on a class basis by using the alternate test and mission objectives.

However, the real-time mission planner is given a powerful assortment of mission-planning computer programs that enhance his ability to manage any contingency.

By the proper use of these on-line computer programs, alternate mission plans can be developed in real time and can thereby augment the premission planning activities.

DEVELOPMENT FLIGHT SCHEDULE

To understand the complexity of the task of mission planning for the Apollo Program, the evolvement of the development flight schedule may be reviewed. From the beginning of the Apollo Program, it was recognized that the flight tests for verifying hardware design, hardware performance, and operational techniques would be extensive.

At the same time, it was recognized that the cost and scheduling of such flights must be controlled and limited to keep development costs for the program at a minimum,

Test requirements for the major hardware elements (launch-escape system, command module aerodynamics, spacecraft structural verification, thermal-protection system, Separation systems, communications systems, propulsive systems, landing systems, etc.) were recognized early as tests that could be made by unmanned flight vehicles.

This realization resulted in the series of Little Joe II test flights (launched at the NASA White Sands Test Facility) and in three Saturn IB and two Saturn V test flights (launched at the NASA John F. Kennedy Space Center), which can be noted in table 8-I.

TABLE 8-1 - APOLLO SPACECRAFT FLIGHT HISTORY

MISSION-PLANNING COORDINATION

Because the development of the Apollo mission plans involved close cooperation of three widely separated NASA centers, inter-center panels were organized to coordinate all activities in which an interface occurred between the launch vehicle and the spacecraft.

For example, early in the program both the launch vehicle and the spacecraft had development objectives which had to be met with as few flights as possible.

The development of missions which supported adequately the mission objectives of both launch vehicles and spacecraft took considerable planning effort among the centers.

At the NASA Manned Spacecraft Center (MSC), a series of flight operations INSERT FIGURE 8-2 plans meetings was conducted to develop the basic mission plan after the issuance of requirements.

These meetings brought together the various experts in spacecraft systems, trajectory analysis, and guidance and control and the flight controllers, crew, and flight plan developers from contractors and MSC organizations. (See fig. 8-2.) The chief importance of these meetings was to set constraints on the mission.

CONCLUDING REMARKS

In planning the Apollo missions, much emphasis was placed on the demand for flexibility in the development program and responsiveness to changing needs.

The dynamic conditions present in Apollo strongly influenced the mission planners in providing comprehensive alternate mission capability and flexibility in the ground and airborne flight software.

Probably of more importance, however, was the capacity of the mission-planning team to react to major program readjustments, as evidenced typically by the Apollo 8 success.

The effectiveness of this team, by using the process described here, is measured by the Apollo record.