I

N A S A TECHNICAL NOTE NASA TN D-7112

i
U
'
v,
z
u CASE F I L E
COPY

APOLLO EXPERIENCE REPORT -

SIMULATION OF MANNED SPACE FLIGHT
FOR CREW TRAINING

!y
t C. H. WodGPzg, Studey Faber, John J. Vun Buckel,
Cbades C. Olasky, Wayae K. Williums, J u h Le C. Mire,
and Jumes R. Homer
Munazed Spucecrafi Center
Hozcstoiz, Texas 77058 ? _d

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION WASHIN6TU#, 0. C. MARCH 1973

I . R e m No. I 2. Government Accession No. I 3. Recipient's Catalog No.
NASA TN D-7112 I
APOLLO EXPERIENCE REPORT March 1973
SIMULATION O F MANNED SPACE FLIGHT FOR CReW 6. Performing Organization Code
TRAINING
7. Authorls) 8. Performing Organization Report No.
C. H. Woodling, Stanley Faber, John J. Van Bockel, Charles C.
Olasky, Wayne K. Williams, John L. C. M i r e , and James R. MSC S-346
10. Work Unit No.
Homer, MSC
3. Performing Organization Name and Address
076-00-00-00-72
11. Contract or Grant No.
Manned Spacecraft Center
Houston, Texas 77058
13. Type of Report and Period Covered
2. Sponsoring Agency Name and Address Technical Note
National Aeronautics and Space Administration
Washington, D. C. 20546
5. Supplementary Notes
r
I
14. Sponsoring Agency code

The MSC Director waived the use of the International System of Units (SI) for this Apollo Experi-
ence Report, because, in his judgment, the use of SI Units would impair the usefulness of the
report o r result in excessive cost.
6. Abstract

Through space-flight experience and the development of simulators to meet the associated training
requirements, several factors have been established as fundamental for providing adequate flight
simulators for crew training. The development of flight simulators from Project Mercury througk
the Apollo 15 mission is described in this report. The functional uses, characteristics, and de-
velopment problems of the various simulators are discussed f o r the benefit of future programs.

17. Key Words (Suggested by AuthorW) 18. Distribution Statement

' Project Mercury

- Gemini Program
* Apollo Program
- Crew Training Simulators
19. Security Classif. (of this report) 20. Security Claaif. (of this page) 21. No. of Pages 22. Price
None None 60 $3.00
 CONTENTS

Section page
SUMMARY ..................................... 1
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
CREW-STATION FIDELITY . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Controls and Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Stowage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Lighting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Aural Cues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Markings and Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Space Suit and Cabin Environment Requirement . . . . . . . . . . . . . . . 13
Crew Couches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Crew-Station Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
VISUAL DISPLAY SIMULATION . . . . . . . . . . . . . . . . . . . . . . . . . 14
Display System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Celestial Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
FarBodies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Target Vehicle f o r Rendezvous . . . . . . . . . . . . . . . . . . . . . . . . 19
Target Vehicle f o r Stationkeeping and Docking . . . . . . . . . . . . . . . . 20
Near-Body Scenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Landing Scenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

iii
Section Page

Concluding Remarks .............................. 29

MOVING-BASE SIMULATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Application of Moving-Base Simulators . . . . . . . . . . . . . . . . . . . . 31

Simulation Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

SIMULATOR CONFIGURATION MANAGEMENT . . . . . . . . . . . . . . . . . 36

Configuration Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Configuration Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Configuration Accountability . . . . . . . . . . . . . . . . . . . . . . . . . 43

Concluding Re marks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

REFERENCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

APPENDIX-SIMULATORDESCRIPTION ................... 47

iv
 TABLES

Table Page
I FLIGHT CREW SIMULATORS. ..................... 3

II SIMULATOR TRAINING SUMMARY. . . . . . . . . . . . . . . . . . . 4

111 SIMULATOR USE FOR FLIGHT CREW TRAINING . . . . . . . . . . . 4

rv SIMULATED NETWORK SIMULATIONS

(a) Gemini P r o g r a m .......................... 8

(b) Apollo P r o g r a m ........................... 8

FIGURES

Figure Page

Mercury procedures simulator ..................... 5

Gemini mission simulator . . . . . . . . . . . . . . . . . . . . . . . . 5

Command module simulator . . . . . . . . . . . . . . . . . . . . . . . 5

Lunar module s i m u l a t o r . . . . . . . . . . . . . . . . . . . . . . . . . 5

5 Lunar landing training vehicle . . . . . . . . . . . . . . . . . . . . . 6

6 Command module procedures simulator . . . . . . . . . . . . . . . . 9

7 Lunar module procedures simulator . . . . . . . . . . . . . . . . . . 9

8 Translation and docking simulator (Apollo) . . . . . . . . . . . . . . . 10

9 Dynamic crew procedures simulator (Apollo) ............. 10

10 Typical reflective infinity display system ............... 15

11 Docking model of CSM in lunar docking simulator ........... 21

12 Air-lubricated free-attitude trainer . . . . . . . . . . . . . . . . . . 23

13 Lunar-surface model (scale 1:2000) of lunar module simulator . . . . 28

14 Partial-gravity simulator . . . . . . . . . . . . . . . . . . . . . . . . 30

15 Mobile partial-gravity simulator . . . . . . . . . . . . . . . . . . . . . 30

V
Figure Page

16 .......
Lunar landing r e s e a r c h facility (Langley Research Center) 31

17 Multiple-axis spin test inertial facility (Lewis Research Center) . . . . 31

18 Centrifuge (Naval Air Development Center. Johnsville.
Pennsylvania) .............................. 31

19 Rendezvous and docking simulator (Langley Research Center) . . . . . 33

20 Translation and docking simulator (Gemini) . . . . . . . . . . . . . . . .33

21 Dynamic crew procedures simulator (Gemini) . . . . . . . . . . . . . . 34

22 Lunar landing training vehicle simulator . . . . . . . . . . . . . . . . . 34

23 Simulator modification flow . . . . . . . . . . . . . . . . . . . . . . . . 41

24 Mercury part-task trainer . . . . . . . . . . . . . . . . . . . . . . . . 48

25 Centrifuge (Manned Spacecraft Center) . . . . . . . . . . . . . . . . . . 51

vi
 ACRONYMS

ALFA air-lubricated free-attitude

CCA contract change authorization

CCB Configuration Control Board

CCP Configuration Control Panel

CFE contractor -f urnished equipment

CM command module

CMPS command module procedures simulator

CMS command module simulator

CRT cathode-ray tube

CSM command and service module

DCPS dynamic crew procedures simulator

ECP engineering change proposal

EIG electronic image generator

EO engineering order

FOV field of view

GFE Government-furnished equipment

GMS Gemini mission simulator

KSC Kennedy Space Center

I L&A landing and ascent
t
LCR lunar module change request

LLRF lunar landing r e s e a r c h facility

LLTV lunar landing training vehicle

LM lunar module
,
t LMPS lunar module procedures simulator
I
vii
LMS lunar module simulator

MCC Mission Control Center

MCR manufacturing change request

ME P mission effects projector

MPS Mercury procedures simulator

MR modification request

MSC Manned Spacecraft Center

PDR preliminary design review

RDS rendezvous docking simulator

RECP request f o r engineering change proposal

SCP Simulator Control Panel

SCR software change request

TDS translation and docking simulator

TV television

3 -D three dimensional

viii
 APOLLO EXPERIENCE REPORT
SIMULATION OF MANNED SPACE FLIGHT FOR C R W TRAINING
By C. H. Woodling, Stanley Faber, John J. Van Bockel,
Charles C. Olasky, Wayne K. Williams,
John L. C. Mire, and James R. Homer
Manned Spacecraft Center
SUMMARY

From the ear'ly phases of Project Mercury through the Gemini and Apollo Pro-
grams, flight simulators have been the key elements in the astronaut training programs.
As the missions progressed in complexity, the sophistication, number, and variety of
simulators employed f o r astronaut training were increased correspondingly. Through
space-flight experience and evolution of the simulators to meet associated training re-
quirements, several factors have been established as critical and basic f o r providing
adequate flight simulators f o r crew training. Included in these factors are high-fidelity
crew stations, especially in the area of controls and displays; accurate simulation of
the spacecraft systems, including the guidance computer and navigation system; com-
plete visual display systems for simulated out-the-window scenes; and certain moving-
base simulators for high-fidelity training in particular portions of the missions. The
significance of these factors f o r new programs will depend to a large degree on the mis-
sion objectives and requirements. Nevertheless, flight simulators incorporating some
of these items i n their design and operation will be vital in future astronaut training
programs.

INTRODUCTION

In this report, "simulation" refers to the operation of t r a i n e r s f o r instructing

flight crews in the various control and monitoring procedures of manned spacecraft.
The purpose of simulation for crew training is high-fidelity duplication of a wide range
of inflight conditions and variables t o obtain precise flight crew response to sophisti-
cated and critical mission events. Repeated simulation exposure allows the crew to
become proficient in interfacing with the flight hardware and ground-support elements,
thus enhancing mission success and safety. In this context, a simulator is defined as
a complex set of hardware (including computers, visual display systems, and simulated
crew stations) that presents, with a high degree of accuracy, the total flight character-
istics of the actual spacecraft and mission. Excluded f r o m this classification are train-
ers that are full-scale spacecraft mockups designed primarily to refine crew tasks
related t o the handling of equipment in performing such activities as stowage, ingress
and e g r e s s , maneuvering in zero-g and 1/6-g (lunar surface) conditions, handling
photographic equipment, and general housekeeping within the constraints imposed by
flight hardware and the space-flight environment. Although the remainder of this paper
is concerned primarily with simulators, it is only proper to give recognition t o these
mockups that played such a significant and necessary role in complementing the simu-
lator training for all major mission phases. A typical example was the extensive train-
ing program carried out for the Apollo lunar landing mission using full-scale mockups
of the lunar module (LM) f o r lunar-surface training and of the command and service
module (CSM) for ingress and e g r e s s and scientific instrument module training.

The topics of this report include some of the more significant aspects of space-
flight simulation: crew-station fidelity, visual display requirements, moving-base s i m -
ulations, and configuration management. The various topics relate primarily the
experience gained in these a r e a s of simulation since the beginning of manned space
flight. It is hoped that future programs might benefit through discussion of this
experience.

Credit for the separate sections of this report is given t o those who, through their
direct involvement with manned-space-flight simulation and training, were able t o re-
port firsthand the data contained herein. These individuals and their respective sections
are as follows: C. H. Woodling and John J. Van Bockel, background and discussion;
J a m e s R. Homer and John L. C. Mire, crew-station fidelity; Stanley Faber, visual
display requirements; Wayne K. Williams, moving-base simulations; Charles C. Olasky ,
simulator configuration management; and C. H. Woodling, overall compilation and
editing.

BACKGROUND

It is pertinent to preface these discussions with a listing of the crew simulators

employed in support of manned space flight, to note the simulator use for training during
each of the flight programs, and to discuss briefly the history of simulators from the
beginning of Project Mercury.

The crew-training simulators used f o r Project Mercury and f o r the Gemini and
Apollo Programs a r e listed in table I. These simulators a r e described in the appendix.
The crew-training use of the various simulators throughout the flight program is pre-
sented in tables 11 and III. During Project Mercury and the Gemini and Apollo P r o -
g r a m s , each crewman (on an average) spent one-third o r more of the total training
program t i m e in simulations (table 11). The crews of the lunar landing missions (Apollo
missions 11 to 15) spent slightly more than 50 percent of their total training time in
simulator training. In addition to the actual time spent in the various simulators, other
training activities were accomplished in support of the simulator training. For ex-
ample, the Apollo crews averaged more than 150 hours of systems briefings as a pre-
requisite to simulator training.

A breakdown of the simulator use by program and simulation facility is presented

in table III. Progressing from Project Mercury through the Gemini Program t o the
Apollo Program, the number and complexity of the simulators increased. Also, it is
interesting to note the increased emphasis on the mission simulators. The 708 hours
spent by the crews in the Project Mercury procedures t r a i n e r s represent

2
approximately 53 percent of the total simulation time of 1330 hours. In the Gemini
Program, the hours logged in the mission simulators are 67 percent of the total; and,
in the Apollo Program, the command module simulator (CMS)and lunar module simu-
lator (LMS) hours combined are 80 percent of the total of 29 967 hours spent in all
Apollo simulations.

TABLE I. - FTJGHT CREW SDIULA'KIIIS

Mercury procedures simulator (3) P r i m spacecraft Ird miseaon ~imulator

Centrifuge (Naval Am Development Center, Movurg-bPae airnulator f o r launch, launch abort.
J c h ~ v l U e ,Pa.) and entry with pssocioted acceleration
environment

Air-lubricated free-attitude trainer Moving-base simulator f o r multiplr-axis pilot

control tanka such as on-orbit attitude control,
r e t r d i r e , and entry

&mini mission simulator (2) Primary spacecraft a d m l s s i m simulator

Dynamic crew procedures simulator Moving-bpse simulator for launch. launch aimrt,
and =*
Translation ud docking simulator
1 Moving-bpse simulator f o r formatim flying a d

Centrifuge (Naval Air Development Center,

JohnsviUe. Pa.)
I
Apollo
Movin!g-baBe simulator for launch, launch abort.
a d entry with associated leceleratim
eovirOllment

Command module simulator (3) Primary CSM mission simulator

Lunv module simulator (2) Primary Lu m i s s i m simulator

Command module procedures simulator P u t - t a s k procedures simulator for CSM

readarms

Lunar module procedures simulator hrt-task procedures simulator for LM lunar

descent and a m e n t iacludlllg rendezvous

Dynamic c r e w procedures simulator Moving-base simulator for launch, launch Pborts,

a d entry
Translation and docldng simulator Moving-base simulator for LM-active formation
fWiw docking

Centrifuge (NASA Manned Spacecraft Center) Moving-base simulator f o r launch, laun:h abort,
a d em with associated acceleration
envimnment

I*my larding trrirri vehicle (LLTV) Free-flight trpining vehicle for final phase of lunu
Mint?
Lunar larding training vehicle simulatw W m i l i a r i u t i m with LLTV myatems

hagley lunar lading research facility Dynamic simulator (tetbered) f o r final phpac d
l W hnding
Dynamic simulator f o r W i n g in tk V6-g lunar-
surface environment

3
 TABLE n.- SIMULATOR TRAINING SUMMARY

Simulator Simulator time Simulator portio]

Program Number of Total training of total training
time, hr per crewman
crewmen program time, hr program time,
(a) (average), hr
percent
I
Mercury

Gemini 17 991

Apollo (through 29 967 69 248

mission 15)

Total 38 261 91 277

aExclusive of simulator prebriefings and postbriefings.

TABLE nI.- SIMULATOR USE FOR FLIGHT CREW TRAINING

1 Simulator
~~
Time per program, hr
~

Apollo
Total
t i n e , hr
Mercury Gemini (through
mission 15)
Mercury procedures simulator (2) -- 708

Air-lubricated free-attitude trainer _- 82

Multiple-axis spin test inertial facility -- 27

Part-task trainer (2) -- 175

Centrduge 58 496

Gemini mission simulator (2) -- 4 682

Dynamic crew procedures simulator 557 985

Translation and docking simulator 64 340

Part-task trainer -- 61

Rendezvous simulator __ 1417

Command module simulator (3) 14 584 14 584

Lunar module simulator (2) 10 672 10 672

Command module procedures simulator 1 008 1 008

Lunar module procedures simulator 753 153

Lunar landing training vehicle and 949 949

simulator, lunar landing research
facilitya

Manned Spacecralt Center mission 146 146

evaluators

Translation and docking simulator 87 87

(Langley Research Center)

Contractor mission evaluators 859 859

Massachusetts Institute of Technology 56 56

evaluators (2)

Full-mission engineering simulator 174 174

Simulator prebriefing and postbriefing b703 b l 343

Partial-gravity simulator, mobile b27 b t 20
partial-gravity simulator
Total 29 967 38 261

aTime computed on the basis of 2 hours logged for each LLTV flight.
bNot included in total simulator hours.

4
 C I assi fi cation
Simulators can be grouped into several classifications. For the purpose of this
report, the following definitions will apply.

Full-mission simulator. - A full-mission simulator is a device in which all crew-

related phases of the mission are consolidated into one complex. Included in this cate-
gorv are the Mercury procedures simulator (MPS)(fig. l), the Gemini mission
V I

simulator (GMS) (fig. 2), the CMS (fig. 3), and the L M S (fig. 4).

Figure 1. - Mercury procedures Figure 2. - Gemini mission simulator.

simulator.

Figure 3. - Command module simulator. Figure 4. - Lunar module simulator.

5
 Part-task simulator. - A part-task simulator is a device in which only a portion
of the mission o r several major crew t a s k s are simulated. Fidelity in these t a s k s may
be greater than that achieved with the mission simulator.

Moving-base simulator. - A moving-base simulator is a device in which the crew

station o r crewmember (or both) is subjected to some physical motion. This physical
motion could be intended to give the pilot realistic cues of acceleration,velocity, o r
position o r could be an undesirable artifact of the simulation technique. One example
of a part-task and moving-base simulator is the LLTV (fig. 5), which provides a high-
fidelity, six-degree-of-freedom duplication of the final lunar descent f r o m an altitude
of approximately 500 feet to touchdown.

Fixed-base simulator. - A fixed-base

simulator is a device in which no physical
motion is transmitted either to the crew sta-
tion o r to the pilot. All the dynamics of the
simulation are provided through displays on
the crew-station panels and by movement of
out-the-window scenes.

D i scussion
The value of high-fidelity simulation
A
L was well known through aircraft flight ex-
perience before Project Mercury. The de-
pendence on simulation for space mission
success and crew safety generally is g r e a t e r
than the dependence on simulation for air-
craft testing because of the natures of the
two flight programs. Space-flight crews
are fully committed at lift-off to an entire
mission, in which a broad envelope of opera-
tional variables is exercised. Aircraft t e s t
r e s e a r c h usually allows for a more gradual
exercising of the total flight envelope
through a series of "buildup" flights.
Whereas the a i r c r a f t test pilot can obtain
much of his training coincident with actual
Figure 5. - Lunar landing training flight testing, the crews f o r space missions
vehicle. must receive all their training and be highly
proficient in all flight tasks before the mis-
sion. Primarily f o r this reason, the space-
flight simulators require the highest degree of fidelity of spacecraft and mission
simulation. Aircraft experience was used extensively in the development and operation
of the first space-flight simulator, the MPS. For the follow-on space programs,
Gemini and Apollo, the major developmental impetus f o r the simulators was derived
from space program experience,

Early in Project Mercury, the effect of space -flight environmental factors upon
crew performance caused considerable concern. Consequently, training emphasized

6
crew exposure t o such conditions as high acceleration forces, zero-g conditions, heat,
noise, and spacecraft tumbling motion. The Mercury astronauts received many train-
ing exercises in an attempt to duplicate these environmental conditions. Particular
concern was expressed about crew capability t o manually control the spacecraft during
the high acceleration loads imposed during launch and entry. As a result, the Mercury
astronauts participated in four centrifuge programs at the Naval Air Development Cen-
ter, Johnsville, Pennsylvania. Project Mercury flight results verified that the condi-
tions of space flight had no adverse effects on crew performance for missions as long
as 22 hours in duration. Consequently, crew-training programs for the Gemini and
Apollo missions deemphasized such considerations and concentrated t o a great extent
on the many and complex operational considerations. Project Mercury experience did
point out the importance of simulating out-the-window scenes, which became even more
important f o r the Gemini and Apollo missions. The Mercury simulators did not have
adequate out-the-window displays, and a major effort to remedy this situation f o r the
Gemini simulators was begun.

The value of high-fidelity simulators was verified throughout Project Mercury,

thus establishing for the Gemini and Apollo Programs the requirement for a full-
mission-simulator inventory both at the NASA Manned Spacecraft Center (MSC) and at
the NASA John F. Kennedy Space Center (KSC) launch site. Operation of simulators at
KSC was deemed necessary primarily because of crew participation in specific checkout
tests of the spacecraft and launch vehicle at the launch site.
For each Mercury flight, f u l l d r e s s rehearsals (referred t o as simulated network
simulations) of the most significant flight phases integrating the crew, the flight plan,
and the ground-support elements were accomplished as part of the preflight prepara-
tions. These simulations proved to be extremely valuable for the flight and ground
crews and, consequently, were further developed and expanded f o r the .Gemini and
Apollo Programs. A simulated network simulation for the Apollo lunar landing mission
involving the LMS and CMS tied in with the Mission Control Center (MCC) in Houston,
Texas, required the precise coordination and synchronization of 10 large-scale digital
computers. The magnitude of this phase of the simulation training program is indicated
in table IV in t e r m s of the number of days spent running full-mission simulations during
the Gemini and Apollo Programs.

The Gemini Program required more sophisticated simulators than did Project
Mercury, principally because of the Gemini rendezvous mission objective. Crew capa-
bility to effect the rendezvous by using primarily out-the-window information was essen-
tial to the mission and dictated that an elaborate visual system be incorporated into the
Gemini mission simulators. The development and use of a n advanced state-of-the-art
infinity optical display system added considerably to the realism and value of simulator
training for the Gemini crews.

Results of the Gemini Program indicated quite clearly that a well-defined and ef-
fective configuration management system was needed t o maintain the simulators in a
configuration that corresponded closely with the continuously changing spacecraft.
Basically, this meant a quick-response systemoperated by personnel cognizant of all
spacecraft changes and capable of deciding on and contracting f o r the necessary modi-
fications and incorporating these into the various simulators. A configuration control
panel committee, with ancillary working groups, was formed for the Gemini and Apollo
P r o g r a m s with good results.

7
 TABLE IV. - SIMULATED NETWORK SIMULATIONS~

(a) Gemini Program

~~ ~

Mission Simulation sessions, days

I11 4
IV 7
V 7
VI 13
VII/VI 9
VI11 9
Ix - 9
X 7
XI 6
XI1 7

(b) Apollo Program

Simulation sessions, days

Miss ion
CMS/MCC LMS/MCC CMS/LMS/MCC Total
~~

7 18 0 18
8 14 0 14
9 10 8 20
10 11 7 18
11 7 7 18
12 10 12 25
13 13 9 27
14 15 13 35
15 19 7 31

a
This summary includes only the mission simulations involving the use of mis-
sion simulators with flight crews and does not include the many more additional days
of "math model" simulations (without the mission simulators) for flight controller
training.

Forecasts of the simulator training requirements for the Apollo Program showed
that a large inventory of various types (full mission, part task, moving base) of stra-
tegically located simulators would be needed. The Apollo Program imposed severe
schedule and simulator-complexity constraints; a requirement was dictated to train a
large number of three-man crews within a relatively short time in sophisticated and

8
 critical mission simulators (three command module simulators and two lunar module
simulators) with complete visual systems. The capability for integral operation of the
simulators with each other and with the MCC in Houston a l s o was required. The greater
number of command module simulators was needed to accommodate the greater number
of command-module-only flights that comprised e a r l y program concepts. In addition,
certain special-purpose part-task simulators were considered necessary to provide
supplementary training, to afford overall training flexibility, and to support the crew
procedures development effort (an integral part of crew training). Among these special-
purpose simulators were the command module procedures simulator (CMPS) (fig. 6),
the lunar module procedures simulator (LMPS) (fig. 71, the Apollo translation and dock-
ing simulator (TDS)(fig. 8), and the Apollo dynamic crew procedures simulator (DCPS)
(fig. 9). Perhaps the most notable special-purpose simulator was the LLTV. Because
of the limitations of accurately simulating this critical phase of the lunar mission on
ground-based simulators, the free-flying LLTV was employed to provide an extremely
realistic dynamic simulation of the lunar approach and touchdown.
Concerning the simulators themselves, s e v e r a l basic decisions were made t o
satisfy the fidelity requirements. One of these decisions was that all spacecraft suh-
s y s t e m s would be simulated by the com-
puters; that is, no actual (hardware) space-
, craft subsystems would be used. One area
handled in a special way was simulation of
the Apollo onboard guidance and navigation
computer. The simulation successfully
used was based on an "interpreter" concept

Figure 6. - Command module procedures Figure 7. - Lunar module procedures

simulator. simulator.

9
 Figure 8. - Translation and docking
simulator (Apollo) .
in which a general-purpose digital com-
puter was programed to accept the same
program as the flight computer and to re-
spond to spacecraft systems precisely as
the flight computer would. The interpre-
ter superseded a barely adequate, costly,
and always late functional approach for Figure 9. - Dynamic crew procedures
simulation of the onboard computer. simulator (Apollo) .
Another area that required considerable updating and redesign was the difficult
visual simulation of the lunar landing. As will be discussed in the section on visual
display simulation, the initial concept of the LMS fell short of the realism required.
An intensive development effort was undertaken to improve the visual simulation for the
lunar landing and at the same time to permit timely use of the LMS f o r the early orbital
training. This effort was successfully concluded t o provide high-fidelity landing and
ascent training for the first lunar landing and subsequent flights.

Although the remainder of this report is oriented toward the difficulties and ex-
perience gained through the operation of the simulator hardware, it by no means implies
a lesser importance of the software systems. Indeed, a large percentage of the overall
simulation effort throughout all flight programs was associated with the simulation soft-
ware. For example, the Apollo lunar landing mission simulation for the CMS consisted
of 750 000 words of memory residing in four large digital computers. Simiiarly, the
LM simulation in the LMS required 600 000 words in three digital computers. At the
peak of preparation f o r the first lunar landing mission, approximately 175 support con-
t r a c t o r personnel were assigned to the development and control of the software systems
of three command module simulators and two lunar module simulators. Another
200 contractor personnel were assigned to the hardware operations and maintenance.
Simulator changes required t o keep pace with the changing spacecraft and mission num-
bered more than 30 p e r month in this same time f r a m e . Configuration management of
these hardware and software s y s t e m s is discussed in the section entitled "Simulator
Configuration Management. 'I

10
 CREW-STATION FIDELITY

Various considerations for the design of the simulator crew station are described
in this section. The Mercury, Gemini, and Apollo simulator crew stations, particu-
larly those for the mission simulators, were designed and constructed with a high de-
g r e e of fidelity to simulate closely both spacecraft performance and interior appearance.

Controls and Displays

The controls and display panels provide the necessary interface between the crew
and the spacecraft. Only through the medium of properly designed panels and functional
integration with simulated systems software can the training be performed efficiently
and adequately. The controls are used to provide intelligence to the supporting com-
puters in the form of analog voltage or discrete signal inputs. To meet crew-training
requirements, it becomes necessary to simulate all known characteristics of a control
switch, such as lock and spring-loaded positions, as well as the forces required to
change positions. Commercial switches that look and operate like flight units usually
can be procured at a fraction of the cost of the spacecraft hardware. Valves to control
the flow of fluids in the actual spacecraft usually a r e not required in an electrically sen-
sitive simulator. Basically, two types of valve operations require simulation. The
type of valve required f o r adjusting the flow of a fluid is referred to as a proportional-
flow valve, and the discrete detent-hold operation u s e s a shifting-port type of valve.
The function of the proportional-flow valve is simulated by the attachment of a potentiom-
eter t o the control shaft for position sensing. Switch activation by cam and detents is
used t o simulate shifting-port valve action. The torque force profile can be simulated
accurately by placing a frictional, adjustable sleeve around the shaft being turned.

When crew training requires a close duplication of hardware operating character-

istics, the use of flight-configured hardware has provided the best results. Such com-
ponents as hand controllers must duplicate as nearly as possible force profiles, dead
bands, feel of multiple detents (soft stops), handle free-return characteristics, mechan-
ical damping, and signal generation for both discrete and proportional displacement.

A wide range of commercial variable controls (such as potentiometers) that have

characteristics acceptable for use without modification are available to simulate equiv-
alent flight hardware. However, specialized assemblies consisting of a transformer
element and a potentiometer or a rheostat (both of which may have certain characteris-
tic profiles to interface delicately with an instrument or system in a balanced relation-
ship) would be difficult to obtain unless procured f r o m the manufacturer of the flight
article. Such units usually are procured for the simulators without the flight qualifica-
tion test necessary f o r spacecraft hardware, thereby reducing the cost of the units and
shortening procurement time. Circuit breakers also require some special considera-
tion. In simulating wiring malfunctions (resulting i n high current flows) that t r i p re-
spective circuit breakers, it is not practical to use spacecraft hardware that t r i p s at
relatively high currents (e. g. , 100 amperes). Instead, a standardized low current
(0.01 ampere on a 26-volt dc system) circuit breaker has been used throughout the
simulators.

11
 Stowage
Since the early Mercury flights, the proper location of onboard data and loose
equipment has been a necessary inflight task and, therefore, a training requirement.
The need for assigning every item a specific stowage location and the procedure for
handling loose items could not be neglected. Ideally, flight-type equipment f o r stowage
training is preferred. However, because of the disadvantages of the high cost of the
equipment and the frequent handling under one-g conditions, actual flight equipment is
seldom used for simulator stowage. For training purposes, a nonflight item s e r v e s as
well if it functionally fulfills the intended use.

Lighting
Lighting of the crew compartment was not considered critical in t e r m s of intensi-
ties and spectrum composition. Experience has shown that light levels sufficient for
general illumination are satisfactory as long as the simulated intensity does not deviate
appreciably (+20 percent) from the actual.

Because of the use of optical eyepieces (telescope and sextant) for navigational
sighting in the Apollo spacecraft, the floodlight intensity settings were usually low,
which caused some difficulty in reading the meters. As a consequence, all simulator
I m e t e r s were lighted integrally, and panel nomenclature was blacklighted with electro-
luminescent elements, as in the spacecraft.

Aural Cues
Audible cues are simulated and presented to the flight crews whenever applicable
during the training exercise. On the Apollo mission simulators (CMS and LMS), such
cues as booster thrust, cabin decompression, and the firing of pyrotechnic devices and
~

attitude-control jets are simulated. Noise levels in the communication channels as well
as ambient noise are simulated and transmitted to the flight crews through headsets and
I
through concealed loudspeakers within the crew stations.

Aural cues are generated by various means, such as a low-frequency reverbera-

tion that feeds into a summing amplifier. The signal output (simulated aural cue) of the
summing amplifier then is fed through a voltage-controlled attenuator to a summing a m -
plifier and then to the loudspeaker in the mission simulator cockpit. The instructor at
his station is included in this loop t o enable him to control the amplitude of the sound
manually with a decibel-control potentiometer.

Markings and Nomenclature

All controls and displays, stowage areas, and other hardware must be properly
marked with the same nomenclature used in the flight spacecraft. Nomenclature is
I especially important during the early phases of crew training to aid in system opera-
tions. However, in time, the crewmembers rarely r e s o r t to reading nomenclature be-
cause they become s o familiar with the location and function of each control o r display
that reading is unnecessary.

12
 Space Suit and Cabin Environment Requirement
In the various simulators, suited operation throughout all phases of flight, yet
with the capability for the crew to train unsuited for comfort, has been emphasized.
The crew- station environment is maintained at ambient p r e s s u r e with circulated,
temperature-regulated air. All the controls f o r the crew-station environment are man-
ual, and the systems are purely simulator oriented. The crew-station-environment
parameters of temperature, humidity, and noise level are electrically monitored at the
instructor-operator station. The crew-station cabin-temperature and cabin-pressure
m e t e r s display simulated values in accordance with the flight profile; that i s , while on
the launch pad, the simulated cabin pressure is 14.5 psi and decreases proportionately
during launch, settling at 5.0 psi for orbit conditions.

A realistic simulation of suited conditions is provided. The use of fully pressur-

ized suits provides the proper constraints for controlling the simulator with rigid-suit
conditions. Great c a r e always has been taken t o prevent the possibility of a rapid p r e s -
s u r e buildup in the simulator suit loops. The CMS suit loop has a motor-driven pres-
sure control that varies the airflow at a fixed r a t e of 2 psi/min, reaching 3.75 psig for
hard-suit and 0.25 psig for soft-suit conditions with constant airflows under either man-
ual o r automatic (computer) control.

Crew Couches
Exact replicas of the crew couches have been used in the simulators to provide
proper body restraint, correct reach patterns, and accurate couch-manipulation
capability.

Crew-Station Hardware
Simulator crew-station hardware is discussed in two categories : contractor-
furnished equipment (CFE) and Government-furnished equipment (GFE).

Contractor-furnished equipment. - The contractor in this case usually was the

prime spacecraft contractor. The spacecraft contractor has several avenues open to
provide hardware for the simulators. If it is not practicable t o simulate the spacecraft
components, actual spacecraft hardware is supplied. Such components as attitude con-
t r o l l e r assemblies, thrust and translation controller assemblies, attitude indicators,
and polycarbonate cover assemblies are examples of actual spacecraft items procured
directly from the prime contractor. Much of the CFE f o r the simulators is manufac-
tured on the production line at the same time the spacecraft p a r t s are fabricated. Sim-
ulator parts made in this manner are identical to spacecraft hardware.

In many cases, simulator parts do not require the sophisticated design o r the
rigid tolerances demanded for the spacecraft. The frequent use of rejected spacecraft
p a r t s on the simulators results in cost savings. During the Apollo Program, the space-
craft contractor maintained another manufacturing capability commonly referred to as
the "model" shop. The personnel in t h i s shop usually work from engineering design
sketches to fabricate prototype units f o r spacecraft qualification tests. The model shop
is often used to fabricate simulator hardware. Components made in this shop f o r the

13
simulators do not have to meet the stringent spacecraft specifications. Occasionally,
hardware f o r the simulators is made from initial design sketches to meet the desired
leadtime necessary to support crew-training exercises. Various other contractor
.sources of simulator hardware are available, including the simulator manufacturer.

Government-furnished equipment. - Simulator p a r t s can be made at MSC. This

source of fabricated hardware is generally the preferred route, on a cost basis. Fed-
eral stock provides a prime source f o r standard off -the-shelf items f o r installation and
maintenance work.

A substantial amount of loose hardware is provided to the spacecraft simulator as

GFE. Optical sights, s u i t hoses, backpacks, and most of the stowed items are pro-
vided by the supplying organization at MSC. Some units are included in the simulators
on a permanent basis, but other units are furnished by the suppliers as required for the
training exercises. Other hardware, such as hand controllers and attitude indicators,
is provided f o r the simulators by the contractors who supply these items f o r the
spacecraft.

Concluding Remarks
A high degree of crew-station fidelity, particularly in the full-mission simulators,
is necessary for accurate simulation of spacecraft performance and mission character-
istics. In addition to a complete simulation of the spacecraft controls and displays,
such items as stowage provisions, lighting, aural cues, and crew hardware are ex-
tremely important in providing this required fidelity.

VISUAL DISPLAY SIMULATION

Early in the evolution of manned space flight, the requirement f o r a window in the
spacecraft w a s identified. Although the window served several purposes, the most im-
portant was as a backup attitude reference. Experience in aircraft control t a s k s and
during early space flight had established that training was necessary t o enable the crew-
member to correlate his out-the-window references with his instruments. The various
techniques used to produce the simulated out-the-window scenes throughout Project
Mercury and the Gemini and Apollo Programs are described in this section.

Display System
The first element of a visual simulation system is the display system, the element
into which an image is projected for viewing by the crew. The determining factors of
this element are the apparent distance t o the image being viewed and the field of view
(FOV) of the window. A general requirement is that all images appear at infinity as
they do in reality. For docking, the simulation requirement was that the image appear
t o approach the crewmember as in the actual situation. Field-of -view requirements
were based on the particular spacecraft window being simulated, with some allowance
f o r pilot eye o r head movement. The Mercury spacecraft requirement was a 60" FOV,
although that of the Apollo LM (the largest requirement) was a 110" FOV as measured
at the eye.

14
 All mission simulators used an infinity display system. Figure 10 is a schematic
of a typical window system using reflective optics techniques. To satisfy the docking
display requirement, the display or output tube was moved from its infinity position.
Approximately 4 inches of movement of the display tube made the image appear to move
f r o m infinity to 8 feet from the viewer.
The infinity image system has the
desirable characteristic that, as the crew-
man moves his head, the item being viewed
appears to move correctly. Conversely,
because of parallax, viewer head motion
grossly affects what is seen with direct-
view, screen-type systems; therefore, the
viewer must hold his head relatively still
the source of the ob-

Spherical Specifications f o r the FOV could not

minu
eyepi- have been met without some design com-
promises. In the Mercury and Gemini sim-
ulators, the FOV requirements (60" and
88", respectively) for completely filled win-
&asplitters
dow scenes were met as long as the pilot
Windm
maintained his eyes within an area defined
as the exit pupil. This was not a s e v e r e
constraint in these simulators, because of
qt positim the relatively limited head freedom. In the
CMS, location of the exit pupil at the window
allowed unlimited viewing-except as con-
Fi@re lo.- micd strained by the physical characteristics
display system. of the spacecraft. The design FOV was 90".
The exit pupil f o r the side windows was not
quite as large as the windows; however, the small dark bands outside the exit pupil
were hardly noticeable and were not a serious problem.

In the LMS, the large FOV, coupled with a large window (17 by 22 inches to ex-
t r e m e apexes) and almost total freedom of the crewman to position his head, required
the greatest compromise. The first compromise was to place the exit pupil in the area
of the crewman's design eyepoint (i. e. , the normal eye position). From this design
eyepoint, the crewman could move approximately 4 inches in any direction with no loss
of display. The second compromise was to point the axis of the forward-window display
down to feature the landing scene at the expense of the upward scene. In the actual
spacecraft, the crewman can look up approximately 20" from the design eyepoint, and
even more by hunching down. In the simulator, the crewman was limited to less than
10". Even with this compromise, the bottom apex of the LM window was blank as
viewed from forward eyepoints. Because these adjustments were chosen very carefully
against anticipated use of the window, the limitations have had no adverse effect on
training.

15
 The infinity display systems used with the mission simulators produced the de-
sired effects as long as proper consideration was given to mission simulation require-
ments. These systems did have some drawbacks. Relatively high cost (30 t o 40 percent
of total mission simulator cost), large physical sizes, ghost images, extremely low
light transmission, and backlight scatter were the most significant. Since the initial
application of the infinity optics technique to simulation, additional development has re-
sulted in reductions of cost and size. These new systems are of both refractive and
reflective types. The refractive types tend t o be brighter, although with some loss in
image quality, than the reflective types.

Celestial Simulation
Simulation of the stars was predicted on both navigational and attitude-reference
requirements. In orbital flight, these requirements are intermixed because the pilot
must know h i s location to use the stars as an attitude reference. In simulation of the
star field, consideration was given to the number and relative brightness of the stars
selected and t o the static and dynamic accuracies required. The number of stars chosen
for all projects to date is approximately 1000, consisting of all those brighter than a
+5 magnitude. The logic of selecting this number was that the navigation stars and the
constellations used for identifying them are all brighter than the fifth magnitude. One
other factor in this selection was that fifth magnitude stars are the dimmest generally
visible t o the unaided eye from the ground.

In training crews for constellation recognition, variations in brightness, at least

t o the whole magnitude, must be simulated. The specifications required at least seven
discrete levels (+5 to - l ) , with c o r r e c t relative brightness between levels desirable but
not mandatory. The specifications also required that t h i s variation be in the t r u e
brightness of the star, not as produced by merely increasing light-source sizes.

Static positional accuracy specifications were dictated by the need t o identify con-
stellations. It w a s determined that the appearance of constellations changes signifi-
cantly with even minor positional e r r o r s . Furthermore, if the s t a r s were to be used
in a navigational task, an instrument such as a sextant would be necessary and an accu-
racy compatible with the instrument was required. To reduce cost, star positional re-
quirements were moderated to 1 milliradian (approximately 0.06") f o r all navigation
stars and 0.5" for all other stars. Specifications also required that if the constellation
appeared incorrect with a 0.5" e r r o r in a given star location, the positional accuracy
f o r that star must be tightened to that of the navigation star.

The specified dynamic positional accuracy also required compromise, as the re-
quirement was complicated by the large range of vehicle angular motions possible in a
spacecraft. Pilot-controlled rates range up t o 20 deg/sec, with uncontrolled vehicle
angular rates of 50 t o 60 deg/sec possible. Although a perfectly stationary spacecraft
is not possible, rates can be as low as 0.1 deg/min f o r small spacecraft motions.
From h i s stable and vibrationless viewing position, the crewman could detect such small
motion. The final specifications derived for all spacecraft simulation programs re-
quired as smooth a low-speed drive as could be produced and permitted lags in position
at angular rates above 1 5 deg/sec. Stepping motions that were detectable by the crew-
members were deemed unacceptable.

16
 In all simulators, the same basic technique was used to produce the star displays.
Approximately 1000 individual stars were simulated by small, highly reflective steel
balls set into the surface of a (celestial) sphere. When the highly polished balls were
illuminated by a point source of light, they reflected the point of light, the relative
brightness being a function of the size and coating of the balls. Balls as small as
0.1 inch and as large as 0.8 inch in diameter have been used. Mirror surfaces concen-
t r i c with the celestial sphere were used t o keep the individual balls in focus over the
FOV of the window. This technique produced excellent representations of the star
field. The only anomaly noted on the display was a halo created by some of the coated
balls. Unfortunately, in the LMS the halo stars were all navigation stars, and the halo
made recognition relatively easy. Therefore, the use of coatings to simulate various
magnitudes is not recommended.

A chronic difficulty in the simulation of stars was in the dynamic drives of the
celestial spheres. Smooth, stepless servomechanism drives that hold positional cali-
brations have not been obtainable, and only continuous maintenance and adjustment have
produced acceptable operation. This problem has not been limited to the servos and
torque motors but has been noted in the entire chain, from the equations of motion,
through the digital conversion equipment, to the spheres. The problem has become
more acute with each new program, because the range of dynamic motion produced by
crew action and under crew control has increased from approximately 10 deg/sec for
the Mercury spacecraft to approximately 20 deg/sec f o r the LM. Although, in the past,
continual maintenance and frequent calibration have tended to minimize the impact of
the servomechanism problems, additional research in product improvement as well as
improved mathematical and computational techniques should be continued.

In addition to the window and the unity-power telescope, the command module (CM)
required simulation of a 28-power, 2" FOV sextant. This optical instrument directly
interfaced with the onboard guidance computer f o r navigational procedures. The r e -
quirement f o r the sextant simulation w a s to produce the Apollo navigation stars (56 in
number) with c o r r e c t background stars, as well as to provide earth o r moon limb at
various altitudes. Static accuracies were the same as specified f o r the spacecraft,
that i s , 10 arc seconds. The dynamic accuracy requirements of the sextant simulation
were not high, because all tracking and marking t a s k s were performed at very low scene
dynamic rates. The sextant simulation was produced by using a single extremely accu-
rately positioned navigation star in one optical leg and a selection of as many as
90 slides of star fields, limbs, and landmarks in a second leg. A pattern generator
and filters were used to produce the background fields f o r the navigation star. Pairs
of rhombic p r i s m s were used t o produce the motions in both legs. The two legs were
combined into a single image by a beamsplitter assembly. For most Apollo training,
five slides covering the most-used navigation s t a r s were used in the second leg. In
operation, if either leg were more than 1" off the intended line of sight, the sextant
simulation was turned off.

Difficulties encountered in the sextant simulation were s i m i l a r to those with the

celestial sphere. That is, producing smooth motion at the extremely low rate used in
taking navigation marks was not always obtainable in the simulator operation. Another
difficulty was encountered with the initial simulator design requirement for updating the
background field. Various changes in the Apollo navigation stars occurred since the
beginning of the program. The method of generation of background stars made it too
expensive to update to new background star fields, and the background-star generator

17
was not used. As a result, it was not possible for the crewmember t o identify the par-
ticular navigation star in the sextant. Fortunately, this turned out to be only a minor
limitation. The accuracy and stability of the actual spacecraft guidance, navigation,
and stabilization systems were quite good, and the inflight procedures were developed
t o make most effective use of this spacecraft capability. That is, the spacecraft crew-
member was not required to identify a navigation star with the sextant, because his on-
board guidance computer programs ensured that the navigation star was always within
0.5 of predicted value.
O

Far Bodies
F o r the purpose of this discussion, far bodies are identified as the distant moon,
earth, sun, and planets, that i s , all those bodies in the s o l a r system that subtend an
angle of approximately 0.5" from the viewpoint. These far bodies were simulated for
navigational reference and for added realism. In the Apollo simulation program, they
were deemed important enough t o be included. F o r the sun, the specifications were f o r
position, size, and high relative brightness in the windows when the individual window
was pointed toward the sun. The requirements for distant e a r t h and moon were f o r po-
sition, brightness compatible with star simulation, and apparent size change as a func-
tion of range t o each body. In addition, simulation of the sun terminator on the far body
was desirable. The tolerances on these requirements were not tight. Simulation of the
larger planets, although desirable f o r navigational reference, was not mandatory.

As noted previously, these effects were not included in the Mercury and Gemini
simulators. In the Gemini simulator, the sun in the window o r , r a t h e r , the total wash-
out of the scene caused by the sun in the window was simulated by video flooding the
television (TV) cathode-ray tube (CRT).

The sun simulation in the CMS used a r c lamps to produce a 0.5" spot of light in
each of the windows. Although these lamps did not duplicate the exact sun brightness,
the simulation was sufficient to wash out the stars and other dim images and served to
remind the crew to maneuver t o some other attitude if they desired t o perform any out-
the -window visual tasks.

With the LMS, a high level of sun brightness was not required, and the sun was
simulated by a s m a l l disk attached to the celestial sphere. By this means, the desired
effect was provided at much s m a l l e r computation and hardware cost than in the CMS.
Sun lighting (or sun shafting) in the crew station was not provided in either the CMS o r
the LMS. Although this omission in the simulation has resulted in the crews' using
spacecraft lights in the simulators that are not normally required in flight, the problem
has not been a major one.

The simulation of the distant moon and earth in the Apollo mission simulators also
fell short of the original specifications. In the CMS, a direct-view film system with
28 discrete phases of the distant moon w a s defined. Because these images were too
small t o be reproduced on film, the technique has been abandoned. For most CM simu-
lation work, the sun simulator was used t o represent the distant body. In the LMS, a
technique similar to the LMS sun simulation was used, but the disk was somewhat less
reflective than the solar disk. By shaping the disk, the phases of the moon o r e a r t h
also were presented. The distant e a r t h and distant moon were moved o r manually

18
adjusted to provide for movement of the distant body relative to the stars, changes in
sun terminator on the body, and changes in relative size with variation in distance.
In summary, the far-body simulation requirements have been modified to be con-
sistent with crew-training needs and state-of -the-& hardware. The requirements for
far-body simulation from the eyepoint are summarized as follows:

1. Position tolerance - Tolerance should be 17" for general realism, 4 " f o r

navigational reference.

2. Size tolerance - Tolerance should be *O. 25".

3. Brightness -Order of relative brightness should be sun, moon, and earth;

all should appear brighter than the brightest stars.

4. Phase (solar terminator) - Phase is desirable, but not mandatory.

5. Dynamics - Far body should have no apparent motion relative to the star for
spacecraft-attitude motion simulation. Far body should move with respect t o the stars
for long-term emphemeris effects; however, step changes are acceptable.

6. Washout and sun shafting -Washout and sun shafting are desirable.

The CM sextant (previously described) contained a set of slides of the distant

e a r t h and of the distant moon. These slides reproduced the effect of the terminator on
the moon for all 28 days of the lunar month and on the earth f o r those days the CM would
be in lunar orbit. This slide technique proved acceptable.

Target Vehicle for Rendezvous

The target-vehicle simulation was split into two parts: long distance, where the
target-vehicle attitude is not important (e. g., rendezvous); and short distance, where
the vehicle attitude in addition to the range becomes important (e. g. , stationkeeping).
The switchover point was defined as 2 miles, or where the target vehicle would subtend
an angle less than 0.2".

The target vehicle f o r distant rendezvous does not require attitude information.
The two requirements are position in the window and relative brightness with range.
F o r tracking in darkness, the spot of light was required to blink to simulate a flashing
beacon. For daylight tracking, the spot should be steady t o simulate reflected sunlight.
Other factors a r e an accuracy of 4 " on position, minimum brightness equivalent to a
fifth-magnitude star, and a maximum range of 250 miles for the unaided eye. Maximum
brightness was not specified; however, the intent was to make the minimum-range tar-
get as bright as possible. The spot of light should be small enough that it does not
stand out against the background stars unrealistically.

In all simulators with rendezvous capability, the window simulation was produced
by electronic techniques on a CRT. This technique met the requirements. The major
problem was in positional stability of the display. In the early simulations, frequent
alinements were required; however, over the span of the Gemini and Apollo Programs,
improved electronic circuit design has reduced this problem t o a minimum.

19
 In the Apollo CM, the unity-power telescope and a 28-power sextant were used
during rendezvous. The simulation requirements for these instruments are similar
to that of the basic window except f o r positional accuracy. The telescope was used to
point the sextant t o a specified accuracy of 0.5" relative to the sextant line of sight.
For compatibility with navigational requirements, the sextant accuracy was specified
as 30 arc seconds.
The telescope simulation f o r distant bodies was a later addition to the original
simulator. Because of space constraints and the stability problem discussed previously,
a CRT display w a s not practical. Instead, the point of light representing the target ve-
hicle was produced by a simple light bulb. Displacements in the FOV and size were
produced by mechanical means.

The CM sextant simulation also was added to the original simulator design. The
requirement of the distant target was satisfied by using the sextant navigation star s i m -
ulation (described in the paragraphs on celestial simulation) t o represent the target-
vehicle position. The resultant positional accuracy was much better than 30 arc
seconds. There were two limitations with this sextant simulation. First, with
28-power magnification, the size, shape, and attitude of the target vehicle were appar-
ent f o r relatively long ranges. Second, the omission behind the LM of a lunar back-
ground made spotting the LM much easier in the simulator than in flight. Of the two
limitations, the lack of a lunar background was considered more critical. To fully
simulate the actual situation, a moving scene beneath the CM and behind the LM would
be required. However, a full simulation is not mandatory. A static scene of the lunar
disk, o r of the lunar limb and terminator, fulfills the minimum requirements.

Target Vehicle for Stationkeeping and Docking

At ranges up to 2 miles o r when the target vehicle subtends an angle greater than
0.2", simulation of the target-vehicle attitude, shape, size, and external features is
mandatory. The target vehicle should be in proper orientation relative t o the active
spacecraft and should be illuminated in accordance with the relative position of the sun,
earth, moon, and any lighting source on the active spacecraft. The angular accuracy
of these vehicle features should be +2" at ranges beyond 40 feet and 4 " at ranges within
40 feet. Linear parameters such as size should be accurate to within +4 percent. Tol-
erances on lighting functions are large, approximately rt30 percent. All dynamic mo-
tions should be smooth, with no obvious stepping actions. Additional specifications are
a proper background behind the target vehicle, with no apparent bleedthrough of stars,
earth, o r moon terrain.

Two general techniques have been used for target-vehicle simuiation: a direct
analog system of closed-circuit T V and models, and an electronically generated (drawn)
image. In both systems, the input to the display system was through a CRT in the in-
finity optics systems. The electronic image generator (EIG) was used successfully in
one of the Gemini mission simulators, in the Gemini part-task t r a i n e r , and in the
LMPS. In the EIG system, the target vehicle was drawn on the face of the CRT. The
outline o r envelope of the target was drawn at a 60-hertz rate; however, the surface
was filled in at a 15.75-kilohertz rate. The image generation contained nine degrees
of freedom and produced such phenomena as line -of -sight blanking, illumination

20
shadowing, and perspective distortion. Simple target shapes (cylinders, cones, and
others) as well as combinations of these shapes were readily simulated with simple
surface markings and details.

In the more conventional system such as that used on the Apollo mission simula-
t o r s , a scale model of the target was viewed by means of a closed-circuit TV system.
The model was mounted in a three-gimbal system to reproduce target-vehicle rotations.
Generally, the innermost gimbals are in the model. The gimbal system should be off-
set relative t o the c a m e r a optical axis to avoid gimbal lock at docking attitude. The TV
c a m e r a s o r lens s y s t e m s attached t o the TV cameras also are gimbaled in this c a s e t o
represent the active-vehicle rotations. In the CMS, however, r a t h e r than c a m e r a rota-
tion, active-vehicle motion was introduced by displacement of the video raster on the
display CRT.
The relative range was introduced through a combination of techniques. In all TV
systems, a t r a c k and carriage assembly was used to move the c a m e r a away from the
model. Camera motion produced an apparent model-size reduction. For the Apollo
CMS and the Gemini mission simulators, this size reduction was supplemented by a
raster-shrink technique t o provide total changes in range. Raster shrink of 67 t o 1 was
successfully used in the CMS. The L M S used two models, a one-eightieth and a
one-twentieth scale. The total required range or apparent size change was obtained by
moving away from one model, then switching to the other and moving from it. An ex-
ample of the type of model used is shown in figure 11. This model, which is from the
LMS, contains the lighted docking t a r g e t in one of the CM docking windows. The dock-
ing probe and the CM conical portion were made of rubber to protect the probe and
c a m e r a s in the event of inadvertent collision.

All TV systems are black-and-white,

high-resolution (greater than 1000 TV lines)
systems. Each system represented the best
state of the art at the time of procurement.
Since that time, however, these systems
have been undergoing almost continuous r e -
work t o improve basic performance and
reliability.

Sun, earth, moon, spotlight, and other

lighting effects w e r e introduced in the
TV/model s y s t e m s by high-intensity lamps
surrounding the models. Both mechanically
controlled lamps and switched banks of
lamps w e r e used with reasonable success.

Both the TV/model and electronic-

Figure 11. - Docking model of CSM
in lunar docking simulator.
image techniques have produced satisfactory
displays f o r stationkeeping and docking. In
the EIG technique, complex shapes cannot
be drawn; therefore, r e a l i s m is significantly
less. Conversely, the EIG is a much
simpler system to maintain and operate.

21
.
With the TV/model technique, external features such as windows, antennas, and dock-
ing aids can be portrayed very accurately. These features are extremely important,
especially at the close-in docking distances. The picture fidelity obtainable with the
TV/model system must be weighed against the complexity of the electromechanical de-
vices required by this system. The TV/model technique has been animated s o success-
fully in the mission simulators that full-scale-vehicle simulation f o r docking is no
longer considered necessary, as it was in early Apollo training.

Near-Body Scenes
Scenes of the near body while in orbital flight cover the altitude range above the
e a r t h o r the moon from 8 to approximately 1000 nautical miles. At these altitudes, the
surface was assumed to be reasonably smooth, and t e r r a i n that appeared three dimen-
sional (3-D)was not required. Near-body s c e n e s were necessary f o r two purposes.
The first was as a general reference from which the pilot could evaluate his attitude
and estimate his position over the t e r r a i n . To meet these needs, horizon position,
groundtrack movement, and general continental features were required. The second
purpose was f o r landmark identification and tracking. To meet these requirements, a
more detailed terrain scene was necessary, and the spacecraft position relative t o the
scene had to be more exact. For the earth, color was a highly desirable feature in ter-
rain identification. For either function, several additional features were desirable,
such as a day -night terminator and the highlight brightness that would approximate the
out-the-window scene. Regarding the accuracies, the following p a r a m e t e r s are noted :

Scene

Position of the horizon nadir, o r other

reference in the field of view, deg

Groundtrack movement (azimuth angle),

deg ...................
...

Size of landmasses, percent . . . . . . .

Horizon curvature, percent . . . . . . . .

esolution - general, deg . . . . . . . .

Landmark areas, deg . . . . . . . . . .

a
a
+-j-Y
Attitude function

10

0.5
--
I
Landmark function

.5

.1

Landmark area was defined generally as a 10-mile-radius circle about the spe-
cific landmark. The transition from the accuracy of the landmark area to the general
scene should occur over a 100-mile radius.

22
For the attitude function, the allowable distortion should permit identification of gross
continental features. F o r the landmark function, the allowable distortion should permit
easy identification of landmass features, capes, bays, peninsulas, r i v e r basins, major
craters on the moon, and s o forth.
In Project Mercury, the view through the periscope and through the window was
simulated in what might be termed "moving-base devices." The periscope was simu-
lated i n the air-lubricated free-attitude (ALFA) trainer (fig. 12) by viewing a 12-foot-
diameter rear-projection screen. The nadir scene was projected on the screen from
a hand-painted strip film. Considering the large distortion of the spacecraft and t r a i n e r
periscopes, the basic requirements of attitude reference and recognition of g r o s s con-
tinental f e a t u r e s were met. The requirement for window simulation in Project Mercury
was uniquely tied to yaw-angle identification while i n retrofire attitude. This need arose
f r o m an inflight problem during one of the e a r l y Mercury flights. Before the following
flight, a yaw recognition device had been conceived and fabricated. The simulation con-
sisted of a 32-foot-diameter s c r e e n curved t o represent a portion of a globe 63 feet in
radius. The shape was obtained by inflating an airtight envelope consisting of one
translucent and one transparent Mylar sheet. A filmstrip depicting moving cloud cover
was projected onto the translucent screen. The crewmember standing at the center
and approximately 2 feet from the dome was at the proper scaled altitude. A simple,
hand-held box outlined his window. Using this simulation, the crewmember could ob-
serve any yaw angle and readily learn to
identify the yaw angles of interest while
looking toward the horizon.

During the Gemini Program, the near-

earth scenes were provided in the mission
simulators. Two different techniques, both
of which met the basic attitude-reference
requirement, were used. At the comple-
tion of the Gemini Program, the equipment
was updated and installed i n the CMPS and
the LMPS.

The CMPS system (from the MSC-

Figure 12. - Air-lubricated free-
attitude trainer.
based GMS) used a 6-foot-diameter globe,
an articulated probe, and a closed-circuit
T V system. Modifications f r o m the GMS
included a new e a r t h globe and a new sup-
port system for the globe and probe. The
probe exit pupil was positioned over the
globe as a function of altitude and latitude.
Rotation of the globe produced the proper
longitude. Spacecraft rotations were intro-
duced by motion of optical elements within
the probe. The updated globe was built to
accurate sphericity requirements and artis-
tically rendered with high detail in selected
landmark areas. The sphericity plus a
stable probe mount provided good horizon

23
positional accuracy and curvature up to a n altitude of 4000 nautical miles. An artifact
in the globe and probe system was the need t o nutate the probe in azimuth as a function
of latitude, an effect that complicated the probe drive equations.

The LMPS used a flying spot scanner system (from the KSC-based GMS) with film
as the data-storage element. Latitude and longitude were produced by film translation,
and spacecraft motions were introduced by electronic manipulation of the flying spot
scanner output. The scanner pattern w a s s p i r a l and centered at the nadir to produce
a clean, sharp horizon. To provide equal element spacing as measured from the view-
point in the spacecraft, the spiral scan spacing was nonlinear. The design resolution
w a s equivalent to the best high-resolution TV raster systems. In the GMS, two parallel
systems were used to produce a semblance of color. However, in the modification to
adapt this system t o the LMPS, this provision was eliminated.’ The modification also
allowed simulation of an altitude range f r o m 2500 feet to 100 miles by using zoom optics,
zoom electronics, and a series of various film scales. The remainder of the LMPS
modification was directed toward improving overall quality of the visual display by using
a l a r g e r f i l m format and improved electronics. Even with these improvements, the
LMPS system has not proved as stable and as flexible as the more conventional mechan-
ical and optical systems.

The LMS used a system s i m i l a r in certain aspects to both of the previously de-
scribed systems. In the LMS, a n articulated probe and closed-circuit T V viewed a
filmstrip of the near body. The LMS films and the LMPS films were actually the s a m e
image material printed at slightly different scales. The major difference in the s y s -
t e m s was that, in the LMS, four windows were active and four probes were required,
whereas, in the LMPS, the display was provided to one forward window and to the over-
head window. Furthermore, the LMS scene requirements included landmark identifica-
tion and tracking in addition to the vehicle attitude-reference task. In the LMS, a
common filmstrip was projected through zoom optics onto four screens. The altitude
range from near z e r o t o orbit was simulated by a combination of optical zoom and film
changes. The probes were mounted at a fixed distance above the s c r e e n s and articu-
lated with the ability to scan to any point on the screen. At the higher altitudes, spher-
ical distortion was introduced by moving additional optical elements into the projection
chain. The horizon was produced at the higher altitudes by illuminating an area smaller
than full-screen size. At altitudes below 100 000 feet, a servomechanism-operated
m i r r o r system surrounding the screen produced the horizon. The lunar scene films
used were, in chronological order, artistic rendition of the front side coupled with
artistic imagination for rendition of the back, artistic rendition updated with Lunar
Orbiter data, Lunar Orbiter photographs photomosaicked into a filmstrip, and Lunar
Orbiter photographs photomosaicked with lunar photographs from Apollo flights. Final
configuration of the film consisted of Lunar Orbiter s t r i p s f o r the high-altitude, full-
orbit scenes and Lunar Orbiter s t r i p s mosaicked with Apollo photographs for the low-
altitude scenes in the vicinity of the lunar landing site.

Several problems were associated with the system that materially reduced the
usefulness of the LMS. A problem resulted from the splitting of the film image to four
screens. The illumination on each vidicon was one-third t o one-half of the desired min-
imum. Another difficulty involved the zoom optics. The design required no movement
of the optical axis with zoom. The dynamic wander of the original hardware was such
that the usable zoom ratio was restricted t o 3 from the design ratio of 10. The wander
a l s o made registration difficult t o maintain when switching from one to a second film

24
 scale. A problem was also associated with the film graphics. It was not practical to
obtain continuous filmstrips with the information content desired. The Lunar Orbiter
s t r i p s with Apollo photographs were available only f o r small areas of the moon. Also,
framelet lines in the Lunar Orbiter s t r i p s were reproduced just as vividly as the craters
and rilles. Furthermore, in the Lunar Orbiter films, it was not possible to simulate
the effect of the sun elevation angle. Hand-painted films could have alleviated certain
of these problems; however, the cost in manpower and time was prohibitive.

The overall effect of these problems w a s a degradation in the LMS fidelity, which
necessitated use of other techniques and facilities to complement the LMS. F o r in-
stance, f o r the landmark identification and tracking task, detailed briefings and lunar
map reviews were held with the crew. The accuracy of the spacecraft navigation sys-
I tem also helped, because the crew rarely had t o search for a landmark during flighty.
I The desired target was usually where mission planning said it should be.
c
The CMS near-body simulation, from the outset, was mainly for the purpose of
: landmark tracking. The system consisted of direct view of color film projections of
near-body imagery. Only such a direct-view system could provide the resolution spec-
ified. This system, known as the mission effects projector (MEP), w a s used in the
four cabin windows and in the unity-power telescope. In the MEP, the image was pro-
jected through a series of optical devices onto a spherical screen. This screen served
as the input of the infinity image system. The optics were driven by servomechanisms
I to simulate spacecraft rotations, limited altitude effects, day-night terminator, and so
forth. Nadir position was introduced by driving the film, and large altitude changes
were provided by dissolving t o films with different scale factors. The MEP represented
an extremely complex electronic, mechanical, and optical device. For instance, each
,
I
MEP had over 30 computer-controlled servomotors and over 40 other computer-
generated signals. Some compromises were required in the final operating configura-
tion: the maximum detail scenic area, as measured from the spacecraft, was limited
to a 90" cone centered about the nadir; the minimum altitude simulated was 100 nautical
1 miles: and the film centerline was placed approximately along the groundtrack. The
first of these was the greatest limitation, but it was partially alleviated by using a cloud
1 cover that moved with the earth to f i l l the scene to the horizon.

The films covered relatively narrow strips centered on the groundtrack; and, be-
cause of retrogression of the orbit (westerly movement of the ascending node), 17 con-
tinuous s t r i p s were required to cover the Apollo earth-orbit mission. To resolve the
round-to-flat mapping problem and the orbit-to-orbit scene repeatability, an extremely
, accurate globe, used as the data source, was photographed by a special modified-slit
camera. The preparation of the filmstrip from this globe is described in reference 1.

The altitude variation for near-body orbits was specified as 100 to 1000 nautical
miles and was obtained by a combination of three film scales with a 2.15:l zoom capa-
bility. Over 250 feet of film stored in four film cassettes were required f o r each MEP
system.

The CMS MEP system, like the LMS, did not meet all the initial design objectives.
The complexity of the mechanical-optical device caused problems, and the number of
MEP systems required to f i l l the windows of the three mission simulators made i m -
provements extremely costly. The first of the difficulties concerned the illumination

25
system, in t e r m s of both the level of light and the uniformity of illumination a c r o s s the
full FOV. The relatively low level of illumination manifested itself in many other prob-
lem areas, The system design required an extremely high luminous f l u on the surface
of the f i l m . Even with this flux, the final brightness as measured from the window was
approximately one-fourth of the originally specified 4 . 5 ft-L and approximately
one -eighth of the desired illumination t o simulate a highlight brightness representative
of a t r u e out-the-window scene. With the high light flux, the film would be destroyed
almost immediately by infrared and ultraviolet radiation. To limit this damage, heat
absorption and rejection filters were used between the arc lamp and the film. Addi-
tional f i l m cooling was achieved by a very high, continuous airflow. This high airflow,
in turn, caused flutter and eventual destruction of the film. In the final mode of opera-
tion, a compromise was selected that accepted some film deterioration caused by the
heating and flutter and a scene illumination that required a relatively d a r k crew station.
In the simulator, the crew made use of the panel lighting and the s m a l l floodlights,
whereas in the spacecraft the sun illumination through the windows was generally
sufficient.

F o r other deficiencies in the system, practical solutions were never found, and,
as a result, procedural workarounds were developed to alleviate the impact on training.
One such deficiency involved the resolution of the imagery that was presented t o the
crewmember in the crew station. Although the inherent resolution of the direct-view
film system satisfied the specified requirements, copies of the film could not be prol-
duced consistently with the same high image quality. The processing of 100-foot lengths
of film does not produce results of the quality that can be achieved by copying individual
photographs. A 30-percent degradation was not uncommon. Another problem involved
the impossibility of maintaining the proper film positioning accuracy over the 80 feet of
film in each of the cassettes. Minor film stretching and warpage introduced e r r o r s of
significant magnitude. In addition, the drive system of the film did not have nearly as
tight a tolerance as required. Finally, a problem existed with the colors in the film.
While the films themselves contain very saturated colors, the projector tended t o mute
and mutilate the colors as displayed in windows - f o r instance, the blue oceans
appeared almost black in the windows.

In both the CMS and the LMS, a defect existed in that the star simulation would
bleed through the near-body scenes. The equipment, as originally designed, contained
hardware to occult the stars in a circular pattern of the s a m e diameter as the n e a r body
would subtend. This hardware proved difficult t o maintain, was nonlinear with position
and shape of the body in the FOV, and, as a result, did not successfully occult all the
stars. Finally, a shortcoming of all near-body simulations was the low scene bright-
ness. This condition required the crewmen t o d a r k adapt t o discern the necessary de-
tail out the window.

Significant funds have been spent in developing the near-body simulations f o r the
various space-flight vehicles. It is recommended that, in the future, the requirements
for out-the-window scenes be very carefully analyzed and that extreme c a r e be taken
to limit the simulator requirements to those obtainable with reasonably simple hard-
ware. For example, in the CMS, only the unity-power telescope in reality required
stringent tracking accuracies. The other four active windows could have been animated
with much less sophisticated hardware. Experience has also shown that window-scene
generators should be more integrated as in the LMS and the CMPS than the system-per-
window such as in the CMS. Such design considerations in future applications should
both reduce initial costs and result in lower maintenance effort and costs.

26
 Landing Scenes
Landing scene simulation was required only in the L M S for training in the lunar
approach and landing phases. The altitude range desired was from a high-gate o r
breakout altitude down to and including touchdown. The scene was required t o provide
the crewmember with attitude and altitude information plus pertinent surface-feature
details. In all other programs (for instance, during earth entry and landing), there was
a minimum of c r e w activity relative to the window displays; therefore, little or no ex-
ternal scene simulation was supplied. In the LMS, the requirement w a s defined as a
continuous scene from an altitude of approximately 1 5 000 feet to touchdown. The orig-
inal requirement at the time of simulator procurement was for a generalized lunar s u r -
face containing representative features of the moon. This requirement was expanded
subsequently t o include modeling of the actual landing sites. Three-dimensional s u r -
face detail was required when surface irregularities became visible to the crewman.
For the lunar landing simulation, the attitude at which surface features became impor-
tant w a s defined as 2000 feet. An additional requirement was the casting of shadows
such as would be caused by local surface irregularities when illuminated with collimated
sunlight.

The visual acuity requirement was to identify objects subtending approximately

0.5" at the pilot's eye. This angle represents an object the size of a 175-foot-diameter
crater observed f r o m 45" at an altitude of 10 000 feet, o r a rock approximately 1 foot
in diameter observed from 100 feet. The positional accuracy of the information in the
window was specified as 0.5" measured at the eye. In addition, the simulated space-
craft should be capable of landing; that is, the eyepoint should approach its scaled
height above the model surface at touchdown. The lunar-surface t e r r a i n should rep-
resent the broad features t o an accuracy of approximately 50 feet. In the landing area
(approximately 2 miles in diameter), this accuracy is increased to approximately
10 feet. The surface should be enhanced with rocks and small craters. The size, num-
ber, and distribution of these rocks and s m a l l c r a t e r s are based upon statistical lunar-
surface data. The size of rocks and c r a t e r s s h d d approach the lowest modeling limit
of 0.02 inch.

As initially delivered, the LMS w a s designed to meet the specified 15 000-foot-

altitude range capability with a combination of the closed-circuit TV/film technique de-
scribed previously for near-body scenes, and a relatively conventional closed-circuit
TV/3-D model system. This model system, known as the landing and ascent (L&A)
system, was used below 1200 feet. The model was 1:lOOO scale with three typical ter-
rain types arranged in 120" pie sections; one each f o r hummocks and small fissures,
boulders and large fissures, and c r a t e r s . The distribution of these features was such
that approximately 35 percent of the surface could be used for landing. Shadows were
simulated by painting the model. The solar elevation angle was assumed to be 45 O .

Overall, this system was determined to be inadequate for training. The major short-
coming was the lack of continuity from breakout to touchdown caused by the film system
problems mentioned in the discussion of near-body scenes. An additional shortcoming
was the lack of realism in the landing area model. An upgraded system, which used a
3-D model f r o m breakout altitude to touchdown, was developed for training of the first
lunar landing mission crews. Maximum altitude of the model simulation w a s increased
to approximately 12 000 feet, and the model scale was established at 1:2000. Two sig-
nificant features were added - an accurate model of the targeted landing area and a
collimated light source to illuminate the surface and produce lunar-terrain shadows.
Figure 13 is a photograph of the upgraded system. The model was viewed by an

27
 Figure 13. - Lunar-surface model (scale 1:2000) of lunar module simulator.

articulated probe with a 110" FOV. To produce the large depth of field required f o r
viewing the surface obliquely, the probe had remote focus capabilities and tilt c o r r e c -
tion. The rotations in yaw and r o l l were unlimited, but pitch rotation was limited to
-10" to +110". The probe was driven horizontally a c r o s s the surface in latitude and
longitude, while the surface moved vertically to simulate altitude. The landing area
simulated was approximately 5 by 8 nautical miles. The image was relayed from the
probe to one window of the LM display system by the high-resolution closed-circuit TV.
Switching was available to supply the image to either of the two LM front windows.
Several undesirable characteristics still existed with the upgraded L&A system.
The closed-circuit TV performed according to expectations only with continuous main-
tenance. The horizon simulation, which was generated by mechanical rings around the
model, exhibited e r r o r s of 3" to 5 " f o r off-nominal trajectories. Duplication of the re-
flectivity of the lunar environment required continuous testing with each new surface
installed. As the desired sun elevation angle increased above 12", the probe shadow
became very prominent and the actual touchdown a r e a was in the shadow at angles above
18". Various means of floodlighting this area alleviated the shadow but compromised
the sun collimation.

28
 Landing simulators used throughout the aircraft and airline industries for training
pilots are in some ways similar t o the L&A but are much less massive and, therefore,
have lower demands upon servosystems. New designs f o r spacecraft landing simulators
should take advantage of the design of these commercial systems. The use of colli-
mated light to illuminate model surfaces should be carefully analyzed. Continued ef-
f o r t s should be expended toward producing a brighter image on the TV screen. Tests
have been made with some degree of success on the use of black phosphors mixed with
bright phosphors t o provide a greater contrast ratio from less scattering of the light.
Other techniques should be studied. Although simulation of the lunar landing did not
require color (since the black-and-white system w a s very suitable), earth landing sys-
t e m s will probably require color; and the development of a tricolor high-resolution TV
system is desirable, particularly f o r night approach simulation.

Concluding Remarks
Beginning with a simple simulation requirement to provide an out-the-window
scene as a backup spacecraft-attitude reference in the Mercury flights, visual display
simulation s y s t e m s f o r the lunar landing mission have grown t o become a major but
necessary element of the Apollo mission simulators. For each visual task of the lunar
landing mission, a visual scene was simulated through an infinity optics system in the
mission simulator. Although the complexity and cost of these devices were significant,
their use in mission training was mandatory.

MOVING-BASE SIMULATIONS

Various moving-base Simulators have been used throughout manned space -flight
programs for crew training. The primary objective has been to familiarize flight c r e w s
with the dynamic environment and t o present them with visual realism of the operational
task. The use of moving-base simulators and the experience gained while developing
and operating such systems are described in this section.

A moving-base simulator is a device in which the major components have physical

motion. The crew station o r the crewmembers (or both) are subjected t o the physical
motion. The space-flight environments of earth launch, earth orbit, cislunar flight,
lunar orbit, lunar landing, lunar-surface activities, lunar launch, atmospheric entry,
and earth landing all contain elements of sight, sound, and touch that are not in man's
normal experience. In these new environmental conditions, man has been asked to
perform certain tasks, such as entry, docking, launch abort, and lunar landing. In
preparation f o r these tasks, moving-base simulators have been used successfully t o
familiarize the crewmember with the anticipated environment and t o confront him with
the operations he would be expected to perform. New environments have consisted of
launch acceleration profiles, reentry deceleration profiles, weightlessness, and the
lunar gravity. Human centrifuges have been used t o simulate the acceleration and de-
celeration profiles. The dynamic crew procedures simulator has been used t o simulate
the launch profile, including noise and vibration. Weightlessness has been simulated by
aircraft zero-g flights and by water-immersion facility sessions. (These two facilities
are not included in the category of moving-base simulators. ) Training for the lunar-
gravity environment has been accomplished through the use of the partial-gravity

29
simulator (fig. 14), the mobile partial-gravity simulator (fig. 15), the lunar landing
r e s e a r c h facility (fig. IS), and the LLTV (fig. 5).

Although training for tasks such as reentry, docking, launch abort, and lunar
landing has been accomplished on fixed-base simulators, crew proficiency f o r each
of these tasks has been improved with moving-base simulators. The moving-base de-
vices were used to add realism to the simulation by presenting realistic cues inherent
in body acceleration and binocular vision.

Figure 14. - Partial-gravity simulator.

Figure 15. - Mobile partial-gravity

simulator.

30

Figure 1 6 . - Lunar landing research
facility (Langley Research Center).
instrument displays. The t e s t s served mainly t o build confidence that, in the-event of
a g r o s s automatic control system failure, the crewmembers could regain control of the
vehicle and stop all tumbling.
Application of Moving-Base Si mulators
Several moving-base simulators have
been used f o r crew training in environmental
familiarization and development of task per-
fection. In preparation for the early space
flights of Project Mercury, when little o r
no experience existed in the new environ-
ments, several devices were used t o famil-
iarize the crewmembers with anticipated o r
possible dynamic situations. The multiple-
axis spin test inertial facility (fig. 17),
which was a simulator built by the NASA
Lewis Research Center, consisted of three
gimbals individually powered by compressed-
gas thrusters. Angular rates from near
z e r o to more than 60 rpm could be gener-
ated. The crewmembers were whirled to
rotational speeds at which disorientation oc -
curred t o familiarize them with this dis-
orientation and t o enable them t o practice
stopping the motions by use of the Mercury
spacecraft hand controller and angular rate

The human centrifuge (fig. 18) at the Naval Air Development Center, Johnsville,
Pennsylvania, was used f o r crew training in acceleration profiles and f o r engineering
evaluation of crew-station equipment. The gondola of the centrifuge was equipped with
the vehicle hardware required to support
the astronaut in launch and reentry phases

Figure 17. - Multiple-axis spin test Figure 18. - Centrifuge (Naval Air
inertial facility (Lewis Research Development Center, Johnsville,
Center). Pennsylvania).

31
of the mission. To further duplicate flight conditions, the gondola was evacuated to the
reduced cabin pressure of actual flight. Six-degree-of-freedom equations of motion
were used to animate the display panel and t o generate the acceleration profiles. In
the final training sessions for Project Mercury (August to September 196l), the crews,
equipment, and procedures were evaluated by simulation of the complete three-orbit
mission from preflight physical examination through countdown, launch, three orbits,
reentry, recovery, and postflight debriefings and physical examinations. Baseline
medical data for comparison with the flight data were derived from these sessions.
The ALFA t r a i n e r (fig. 12) was basically a pseudo-Mercury spacecraft mounted on a
spherical a i r bearing. This n e a r frictionless support, coupled with a combined
astronaut-plus-trainer center of gravity at the center of the ball, produced an accurate
simulation of spacecraft motion as far as attitude control was concerned. The struc-
t u r a l support systems and the effects of the one-g field on the t r a i n e r limited the yaw
and pitch motions t o *35 O. Roll was unlimited. All three attitude-reference systems
(periscope, panel instruments, and window) were available t o the crewmember. F o r
the periscope display, a 10-foot-diameter s c r e e n was viewed through optics simulating
the wide-angle view of the vehicle periscope. A moving earth scene of the orbital t r a c k
was back projected onto the screen. This display was relatively accurate f o r deviation
angles up to 25". For the panel displays, actual vehicle hardware was used to measure
the attitudes and rates and to display these values to the crewmember. F o r the view
through the window, a lighted horizon and a generalized s t a r field were provided. Mo-
tion of the trainer was controlled by the crewmembers' use of compressed-air jets.
Mercury spacecraft control systems were simulated. Disturbances that could be pro-
duced by misalinement of the retrorockets also were simulated by compressed-air jets.

As the manned space-flight program progressed and experience was gained in

space flight, crewmembers and engineers became more familiar with the dynamic en-
vironment. Crew performance in space was demonstrated, and many of the previous
unknowns were no longer a r e a s f o r concern. The performance of new t a s k s was neces-
s a r y t o achieve the goal of placing a man on the moon. Thus, the emphasis previously
placed on dynamic environment familiarization became secondary to training f o r per-
formance of special tasks. The tasks of docking, lunar landing, and traversing the
lunar surface were approaching, and crew experience was needed. To meet this re-
quirement, a new generation of moving-base simulators was developed f o r crew train-
ing. The Langley rendezvous and docking simulator (fig. 19) used a crew station
supported in a gimbal that was suspended from a bridge crane. The crew station had
six degrees of freedom and operated in conjunction with a stationary target vehicle.
P r i m a r y attention was given to crewman position, control assembly, control modes,
viewing window configuration, docking aids, and target-vehicle geometry. Development
work on docking procedures was accomplished as well as crew training and evaluation
of docking aids. This simulator was used f o r Gemini docking and for both Apollo dock-
ing configurations (CM and LM).

The MSC translation and docking simulator (figs. 20 and 8) was a six-degree-of-
freedom simulator used primarily f o r crew training. The hardware consisted of a crew
station mounted in a three-axis gimbal. The gimbal was supported by an air-bearing
carriage to permit lateral motion. The two remaining translations, longitudinal and
vertical, were simulated by target motion. These two motions were reversed t o give
the proper directional illusion of crew-station motion. P r i m a r y emphasis was placed
on vehicle configuration and visual environment. Various control system modes were

32
 Figure 20. - Translation and docking
simulator (Gemini).

simulated, and flight-type docking aids were

used. Simulator configuration included
Gemini docking, Apollo LM-active docking,
and a modified CSM-active docking, in which
CSM m a s s properties were programed into
the simulator with control from the LM
Figure 19. - Rendezvous and docking crew station.
simulator (Langley Research
Center). The dynamic crew procedures simu-
lator (fig. 21) consisted of a crew-station
gondola supported in a gimbal that was can-
tilevered into a spherical dome. The desi& of this simulator was based on the idea of
presenting the rotational acceleration to the crewmember while separating the velocity
cues into a visual presentation. The interior of the dome was used as a s c r e e n on which
an e a r t h image o r star field could be displayed. One of the primary features of the
simulator was that it could present the dynamic environment (noise and vibration) of
launch and reentry f o r crew familiarization. Procedure development and practice on
the simulator have included launch, launch abort, reentry, and rendezvous. The simu-
lator, which originally was designed and built in Gemini configuration, also has an
Apollo CSM configuration (fig. 9).

The lunar landing r e s e a r c h facility (fig. 16) was used for r e s e a r c h and f o r crew
training associated with the piloting of a vehicle in simulated lunar gravity. This out-
side facility consisted of a gimbal-mounted vehicle suspended from a traveling bridge
crane. The piloted vehicle, originally with the crewman seated and l a t e r modified to
a standup configuration, had an operating envelope of 180 feet vertically, 360 feet lon-
gitudinally, and 42 feet laterally. Two operational modes w e r e used. The first mode,
used primarily for pilot indoctrination and s y s t e m test, simulated the lunar-gravity en-
vironment and rocket-engine lift through the use of the translation drive systems. The
second (simulation) mode used the main rockets and onboard f u e l to develop lift while
the translational drives supported five-sixths of the vehicle weight to simulate lunar

33
 gravity. The simulation mode allowed ap-
proximately 2 minutes of operation whereas
the first mode afforded more than 20 min-
utes of continuous operation. Evaluations
of control system p a r a m e t e r s and piloting
techniques associated with lunar landing
touchdown were conducted. Operation with
various landing models allowed evaluation
in the area of obstacle avoidance and a
limited look at surface dust effects.

The LLTV (fig. 5) is afree-flight

vehicle consisting of a tubular f r a m e on
which a crew station, a jet engine, lift
rockets, attitude control rockets, control
electronics, and associated equipment are
Figure 21. - Dynamic crew procedures mounted. The jet engine, which was
simulator (Gemini). mounted vertically, provided main power
f o r takeoff and supported five-sixths of the
vehicle weight during simulation of the lunar environment. The vehicle was used t o
simulate the lunar landing from an altitude of 500 feet to touchdown. Operations were
conducted over an airport runway and consisted of s e v e r a l familiarization flights p r i o r
to the lunar simulation flights. A fixed-base LLTV simulator (fig. 22) was used to
familiarize the pilot with crew-compartment instruments and controls. Use of the
simulator allowed the pilot to practice LLTV procedures and to become familiar with
vehicle operations.

The partial-gravity simulator (fig. 14) consisted of a gimbal supported from a

pneumatic cylinder. The pneumatic cylinder provided lift t o support a proportional
amount of a crewman's weight. The simulator was used to familiarize crewmembers
with lunar-surface mobility. Use of lunar tools was practiced. A mobile partial-
gravity simulator (fig. 15) a l s o w a s used to familiarize the crewmembers with lunar-
surface mobility. The two simulators were of the same basic design except that the
mobile unit was suspended from a truck-mounted tower. This arrangement was used
to extend the operating range and to allow investigation and familiarization with running
under lunar-gravity conditions.

Simulation Experience
In general, the design, operation, and
modification requirements of moving-base
simulators are similar t o those of other
simulation hardware. However, in addition
to the g r e a t e r emphasis on crew safety re-
quired, some unique features must be con-
sidered in the design and operation of
moving-base simulators.
Figure 22. - Lunar landing training
vehicle simulator. Moving-base simulators usually are
designed f o r a special task o r s e t of tasks.

34
The design must concentrate on the simulation of those t a s k s while minimizing the un-
desirable side effects that are inherent in moving hardware. To overcome undesirable
side effects and to accomplish successful moving-base simulation, innovation and
unique approaches a r e needed, such as the separation of simulated acceleration cues
(seat of the pants) and velocity cues (visual), the use of airbearings to minimize other
motion cues such as rumble, special servosystem design to keep undesirable dynamic
cues outside the frequency and amplitude domain of sensory perception, rotation about
the individual body center of gravity to equalize force on extremeties, painting, lighting
to hide support or enclosure structure, and so on. The hardware design as well as the
computer software must take into account the man-in-the-loop aspect. Convenient in-
g r e s s and e g r e s s provisions are required and actual man-machine interface is neces-
s a r y ; however, only the pertinent interface should be included. Special programing,
such as drive-system compensation, may be required for proper hardware perform-
ance. An overall systems analysis should be performed before design finalization to
ensure that optimum simulation can be performed. Size and weight are basic consid-
erations in the design. The simulator size is dictated by flight-vehicle configuration,
and the design weight affects drive-system design and overall system complexity.
Structural integrity must be consistent with the dynamic environment and the man-
machine interface. Fidelity of the simulations is dependent on a satisfactory balance
of these parameters. Controls and displays usually are limited t o those necessary to
accomplish the unique task o r tasks. Cockpit displays other than those of the space-
craft are necessary in some moving-base simulators, such as the LLTV, because of
their operating requirements. Special effects of lighting and sound have been used t o
add significant cues for the performance of a given task. Lighting also can be used to
enhance the simulation. For example, in the MSC TDS, the target vehicle was illumi-
nated t o make it stand out against a subdued background. This technique is used to re-
duce the false cues given by supporting structures and surrounding walls. Foremost
in the mind of the designer must be the characteristics of the spacecraft or the situa-
tion being simulated. If characteristics peculiar to the simulator overshadow the situa-
tion o r spacecraft being simulated, the simulator will be of little value.

Moving-base simulator operations have requirements in addition to those of other

simulators. These considerations exist because the crewman experiences the dynamic
environment and because some physical limitations with moving hardware do not exist
with electronic or optical simulations. The interface of the crewmember with the hard-
ware is a prime consideration in the design and basic configuration. Crew restraints
and hardware arresting gvar are a part of the basic design. Computer program scaling
and signal limiting should be compatible with the dynamic environment to be simulated.
Operating procedures need careful consideration to allow successful simulation. These
procedures include inspections and preventive maintenance; preflight checkout; and
power-up, power-down, and backup procedures. The key to crew safety is a knowledge-
able and alert operator with positive control over the motion systems. Velocity, accel-
eration, and position limits are a part of moving-base simulation. The task being
simulated must be considered in the setting of these limits. In addition to these physi-
c a l limits, equations-of -motion scaling limits and electrical limits are included to
provide fidelity of simulation and safety of operation, respectively. These constraints
are an inherent part of moving-base simulators and cannot be overlooked when consid-
ering operations.

As with any hardware, a development period is needed when producing a moving-

base simulator to permit optimum engineering trade-offs. Simulator design in this

35
area is unique because a limited number of simulators of a particular configuration are
built, possibly only one. Therefore, a preliminary fabrication and checkout period, in
which prototype hardware is developed and tested before production, could be used to
develop better hardware and to eliminate operational problems. Another design consid-
eration should be the use of off-the-shelf i t e m s t o minimize special equipment, which
is hard to replace and usually expensive. In addition, it should be remembered that
simulation equipment has a high use rate and needs to be designed with a high degree of
reliability. The computer program (analog o r digital) will in some ways be unique be-
cause of the interface requirements with moving hardware. The nature of the hardware
must be considered and special formatting o r signal conditioning accomplished to per-
f o r m a valid simulation. In addition, it is useful to be able to verify the computer pro-
gram independent of the moving hardware. A computer self test, o r program designed
t o close the loop on itself, can be a valuable tool in program verification and checkout.

Concluding Remarks
Various moving-base simulators have been used in manned space flight to add a
degree of fidelity in certain flight regimes not available in fixed-based simulations. In
spite of design complexities, additional operational procedures, and safety considera-
tions (compared t o fixed-base devices), moving-base simulators will continue to play a
significant role in training and simulation f o r future programs.

SIMULATOR CONFIGURATION MANAGEMENT

The three manned-space-flight programs (Project Mercury, the Gemini Program,

and, in particular, the Apollo Program) have emphasized progressively the requirement
f o r a f i r m simulator-configuration-management program. The requirements f o r
simulator-configuration management exist f o r the same reasons as those of spacecraft
configuration management; that is, the need t o know the vehicle configuration at any
point in time and the need to know the vehicle future o r desired design configuration.
The converting of the vehicle, o r in this case, simulator, f r o m an actual configuration
t o a design configuration must be by means of an organized and systematic procedure -
one that will provide the highest crew-training return with a reasonable manpower and
dollar investment. The guidelines in this section describe how this balance, o r goal,
has been achieved closely in past programs and how it can be realized fully in future
programs. The following discussion defines the necessary building blocks f o r simula-
t o r configuration identification: configuration tracking, configuration control, and con-
figuration accountability - the total of which is synonymous with configuration
%anage ment .
Configuration Tracking
The major crew-training (mission) simulators for Project Mercury and for the
Gemini and Apollo Programs all were developed and constructed by industry contractors.
Each simulator constituted a contract end item and was initially designed to a basic data
package, largely supplied by the spacecraft prime contractor through NASA. This data
package was serviced and updated in total until the simulator preliminary design review

36
(PDR) and formed the basic mathematical model and hardware design definition f o r each
respective simulator. At the PDR, the simulator reached a contract definition stage
(usually, although somewhat erroneously, referred to as a contractual "design freeze"),
beyond which all simulator updates o r changes to the spacecraft baseline data package
constituted a design change and required a corresponding simulator contractual change.
It is at this point that the t e r m s "modification, '' "configuration control, '' "in-line modi-
fications, '' and "modification kits" assume their f u l l significance and the execution phase
of modification activity begins. This modification activity usually commences prior to
f o r m a l contract delivery of the basic simulator to NASA.

In its simplest t e r m s , a spacecraft modification is a class I o r class I1 change to

the flight vehicle that requires duplication in the simulator to prevent a serious degra-
dation in crew training o r simulator configuration. A class I change is an out-of-scope
modification to the flight vehicle and is initiated by a contract change authorization
(CCA) from NASA to the spacecraft prime contractor. A c l a s s 11 change is an in-scope
modification that the spacecraft prime contractor finds necessary to implement, and
does s o without a change o r amendment to the contract. All spacecraft modifications
in either c l a s s are reviewed and considered f o r implementation into the simulator. A
routine, thorough review of all these changes is hardly acceptable in t e r m s of man-
hours (at one point in the Apollo Program, the change activity w a s running at 75 to
100 changes per week), and timesaving shortcuts can be identified quickly. Examples
of shortcuts that are used on the Apollo Program will be given later. First it is neces-
sary to define the methodology and technique used in identifying spacecraft changes
from a simulation point of view. Through January of 1970 in the Apollo Program,
1050 changes were approved for incorporation into the CMS alone, and approximately
700 of these resulted from counterpart spacecraft changes. The following procedures
can be adapted and used to identify simulator changes (resulting from actual o r proposed
spacecraft changes) f o r any given program. No attention will be given here to the
simulation-fidelity requirements relative t o a spacecraft change, as that subject is
covered in other portions of this report.

1. Monitor and review regularly the agenda and minutes of the spacecraft Con-
figuration Control Panels (CCP's). This activity will normally cover all proposed and
approved requests for engineering change proposals (RECP's) from NASA and all en-
gineering change proposals (ECP's) from the contractor of less than a certain dollar
value o r with less than a certain schedule impact.

2. Monitor and review regularly the spacecraft Configuration Control Board

(CCB) agenda and minutes. This activity will identify high-impact approved o r disap-
proved spacecraft changes and items referred by the spacecraft CCP.

3. Obtain copies of, and review, the prime contractors' internal change authori-
zation paperwork. In the Apollo Program, these authorization documents were the
manufacturing change request (MCR) and the lunar module change request (LCR) from
the prime contractors f o r the CSM and the LM, respectively. These documents are
normally released to initiate a design study and frequently a r e weeks ahead of RECP,
ECP, o r CCA action. Consequently, the use of this monitoring tool allows routine
identification of proposed changes much earlier than the activities described previously
(items 1 and 2); however, c a r e must be exercised in cross-checking these releases
against the NASA CCP and CCB activity f o r approval authorization. An alternative to
this procedure is t o obtain the contractor's MCR release-to-manufacturing milestone,

37
which signifies that the MCR is approved f o r implementation. It should be noted that
there is no obligation for the contractor always t o release an MCR (or a s i m i l a r type
paper) for a change, and frequently the contractor does not do so f o r class I1 changes.

4. Routinely review basic system schematics on a per-spacecraft basis as a

cross-check against items 1 t o 3.

5. Obtain routine distribution of all mission-definition documents and updates of

these documents within NASA.

6. Obtain routine distribution of all guidance and navigation onboard computer

program documentation and pertinent engineering reports.

7. Establish channels with all NASA associate contractors f o r applicable space-

craft data on an as-required basis.

As mentioned earlier, certain shortcuts can be taken t o decrease the NASA man-
hours required to review and control the r a t h e r large bulk of information and documen-
tation identified previously. Examples of the shortcuts that have been used on the
Apollo Program and that should be considered on future programs are as follows:

1. Have the spacecraft contractor categorize MCR's and filter out those clearly
not applicable to simulator design. Examples are ground-support equipment MCR's that
are not transmitted to NASA simulation personnel.

2. Do not submit any simulator change for approval unless the spacecraft counter-
part is released t o manufacturing o r the item is considered to be a long-lead-time type
change. In the past, the released-to-manufacturing milestone has been identified on the
MCR document; if it is not, a tabulation of this information is required from the
contractor.

3. Review CCB directives. This procedure will provide a summary of NASA-

approved CCP and spacecraft changes and will reduce review of agenda and minutes to
a cursory level to identify only those proposed changes placed in a deferred status.
4. Establish a procedure for the spacecraft contractor to audit, screen, and
identify all c l a s s I1 changes that could be applicable to the simulator configuration.

5. Initiate parallel shipment of spacecraft-modification data to the simulator

design contractor o r support contractor (or both) as well as to NASA. This procedure
will enable parallel review and impact analyses of modifications.

Whereas the previously mentioned simulator modifications may result from a

spacecraft subsystem change, subsystem improvement, elimination of crew safety
hazard, elimination of potential single-point failure, change in trajectory o r landing
site, and so forth, there is also a category of simulator improvement modifications
not contingent upon spacecraft changes. This category is f o r the improvement of opera-
tional, maintenance, o r training capabilities of the simulator in t e r m s that are evident
t o NASA operations personnel o r NASA support contractor modification and maintenance
personnel. This type of modification has no parallel in the t r u e spacecraft. Either
NASA o r simulator contractor personnel initiate this type of change, although this

38
procedure is not mandatory. However, these persons usually possess the firsthand ex-
perience and knowledge needed to recognize candidate simulator improvements. When
simulator history is traced f r o m the first Mercury procedures t r a i n e r to the CMS and
the LMS, a dramatic increase in simulator improvement modifications is apparent.
This increase can be attributed, in large part, to the justifiable increase i n complexity
in the man-machine interface. F o r example, whereas the Mercury procedures trainer
was a rather simple procedural analog training device designed t o simulate a somewhat
repetitive series of missions, the CMS and LMS, each with a powerful computing com-
plex and complicated MCC interface, were designed to simulate a much l a r g e r reper-
toire of missions.

In addition t o the configuration change identification data discussed earlier, space-

craft change implementation data must be defined and obtained. These data fall into the
following areas:

1. Internal MSC data such as mission planning and trajectory data

2. Internal NASA data such as NASA George C. Marshall Space Flight Center
booster and launch trajectory data

3. NASA associate contractor data such as the Massachusetts Institute of Tech-

nology onboard computer programs and necessary supporting documentation for the
Apollo Program

4. NASA spacecraft prime contractor and subcontractor vehicle subsystems data

The process of identifying and obtaining the data listed in i t e m s 1 to 3 is simple, but a
difficulty inherent in item 4 is the undesirability of receiving updates to 500 000 space-
craft drawings. The method that works w e l l on the Apollo Program is correlation of
the spacecraft prime contractor MCR or LCR to newly defined spacecraft drawings or
engineering erder (EO) to existing drawings, m d transmittal to NASA of the drawings
o r EO'S on microfilm aperture cards. Furthermore, NASA reviews MCR and LCR
documents immediately after they are released and informs the contractor which poten-
tial changes will have impact on the simulator; consequently, particular data are iden-
tified long before the data are released, which is a desirable condition. Also, this
procedure eliminates transmittal of data for MCR's that do not have impact on a simu-
lator. The document that relates MCR's to drawings and EO-type data is called a data
submittal letter and is a cross-tabulation of MCR number to drawing or EO number.
After an MCR o r LCR is defined as applicable to a simulator, all spacecraft data re-
leased against it will be supplied to NASA.

All proposed modifications for the simulator submitted to the Simulator Control
Panel (SCP) require preparation of a standard form known as a modification request
(MR). The MR is required to contain the following information:
1. The change t o the actual spacecraft and its effect on vehicle operation o r crew-
member interface (or both) (not required for simulator improvement modification)

2. Definition of the counterpart simulator change required to update the simula-

tor to reflect the spacecraft

39
 3. The effect on crew training if the change is not implemented

4. Spacecraft and simulator effectivity

5. How, and t o what extent, the hardware o r software ( o r both) is t o be modified

6. An estimate of parts cost and source, and the man-hours and computer-hours
required to implement the modification f r o m preliminary design to final NASA
acceptance

7. A schedule of all pertinent milestones including final installation acceptance

The author of the MR supplies information f o r items 1 to 4. The NASA simulator

contractor, who will implement the modification, supplies information f o r items 5 to 7.
All MR packages are reviewed and screened for accuracy and relevance before submittal
t o the SCP -which is the next subject and the first step in configuration control.

Conf igu ration Control

All MR's require SCP approval before implementation. The functions and re-
sponsibilities of the SCP a r e defined as follows:

1. Evaluate spacecraft changes that have impact on the simulator.

2. Evaluate all other proposed changes, such as launch vehicle, mission trajec-
tory (reset), and simulator improvement, that have impact on the simulator.

3. Review the availability of spacecraft data f o r each spacecraft modification

presented f o r approval.

4. Confirm simulator effectivity for a modification.

5 . Assign responsibility f o r implementation of each modification.

6. Approve a schedule f o r each modification based on consideration of the follow-

ing items:

a. Mission effectivity and schedule

b. Crew-training requirements

c. Simulator availability

d. Flight controller (integrated mission) training requirements

e. Difficulty and extent of modification

f. cost

7. Review the total operational and modification status of the simulator.

40
 8. Act as the overall configuration management control point by defining any addi-
tional procedures required for a specific modification, assigning action items, and en-
suring that the overall modification cycle is operating in a smooth and timely manner.

Immediately before a scheduled SCP meeting, a pre-SCP meeting is held between

NASA and simulator support Contractor personnel. The purpose of this meeting is to
review all modifications on the SCP agenda for technical accuracy, format, and com-
pleteness. In the pre-SCP meeting, the disposition of all new and open MCR’s that are
not ready for presentation to the SCP also is determined. The functional placement of
the pre-SCP and SCP activities are shown in figure 23. The following categories are
used in the pre-SCP meeting t o classify all MR’s:

1. Recommend SCP disapproval of the MR o r determine that the MR is not appli-

cable to the simulator.

2. Determine that the M R is not yet impacted and that impact is required for con-
sideration at the next SCP meeting.

3. Determine that the MR is not impacted because of lack of data and that action
is required to obtain data.

4. Recommend approval of the MR to the SCP.

5 . Place the MR in abeyance t o be reevaluated at a future NASA-specified date.

6. Place the MR in a hold status pending more detailed NASA review.

7. Determine that the MR revision has no effect, and, thus, that the previous re-
vision level remains in effect.

1 Modification ’ 3
9. Determine that the MR is approved
requirement Pre-SCP
determination review for implementation, but that new impact on
a.ndimpaci GFE o r CFE hardware is required f o r the

Modification Modification
SCP Approved -’preliminary
. final design from the appropriate MSC directorate, from
review design and * and NASA the NASA simulator support contractor
NASA approval approval

Modification
installation
checkout and
NASA acceptance
Modification- ’
documentation
(nonconcurrent)
acceptance
- updateand
acceptance
discussed. The SCP receives and reviews
those modifications recommended for ap-
proval or disapproval at the pre-SCP meet-

41
 The NASA simulator support contractor SCP responsibilities and participation
a r e as follows:

1. A s a routine activity, evaluate f o r technical impact and f o r simulator and

spacecraft effectivity all MR's received f r o m NASA, received from the prime space-
craft contractor, o r self-originated (or any combination of these sources).

2. Assure that the necessary spacecraft data are collected and reviewed to the
extent necessary for impact on the modification for the SCP. This impact entails the
following activities:

a. Estimate the engineering effort and schedule f o r each individual modifica-

tion submitted for approval. This estimate includes the engineering effort necessary
to change o r update (or both) the affected hardware drawings, software mathematical
models, specifications, interface control documents, and so forth.

b. Estimate the programing effort and schedule f o r implementation of each

software modification to the actual simulator program. The estimate will cover adding
the modification either as a patch (octal correction) o r as a basic change to the software
load (assembly change).

c. Estimate the design and drafting effort necessary to originate o r update

(or both) drawings, wiring lists, and other affected documents for an electrical o r
mechanical modification. This activity usually is related to the supporting engineering
activity in item a.

d. Estimate the on-line man-hours and machine-hours required f o r installa-

tion and checkout of each modification.

e. Estimate any required parts cost and indicate the parts sources.

f. Estimate a final date f o r each modification to be ready for NASA accept-

ance and subsequent shipment to other simulators, as required.

3. Provide logistics support and necessary SCP documentation (agenda, minutes,

manpower curves, etc. ) as a routine requirement.

4. Be prepared to participate at the project managerial level in any discussions

and reviews of the overall modification activity as it affects crew training, schedules,
manpower levels, areas of required additional technical emphasis, and future goals for
all simulators.

5. Understand and implement the ECP decisions and assigned action items with
proper NASA coordination.

42
 Configuration Accountability
Configuration accountability involves the establishment, monitoring, and updating
of simulator documentation to define a baseline and a modified current configuration of
a simulator at any point in time in t e r m s of hardware and software. This process re-
quires the following:

1. A description and understanding of the types of documentation and the method-

ology in changing these documents

2. A centralized, organized, rapid-information-transfer system for implementing

item 1 with proper interfacing approval points within configuration control management

3. A rigorous library and information system designed to handle listings and

records of multiple simulator configurations that are in work

4. Standardization of items 1 t o 3

All simulator hardware has required and will continue t o require comprehensive
documentation. This documentation ranges from the basic drawing tree definition to the
specific drawings defining fabricated and purchased hardware as well as locating the
hardware within the simulator complex. However, within this large m a s s of documen-
tation, the basic requirements and procedures for updating, providing traceability, and,
in general, accountability are the s a m e for every hardware document i n the system.
Thus, f o r purposes of this paper, discussion will be provided for a single piece of hard-
ware docume-ntation entitled a drawing, with the realization that, although this drawing
may have dozens of variations and specific uses, for purposes of configuration manage-
ment it is one homogeneous entity.

The following facts have been proved true for hardware accountability:

1. A baseline set of drawings and drawing tree must be established t o match s i m -

ulator hardware.

2. One piece of paper must be generated for every simulator hardware change.
(This paper has had and may use any one of a number of names, but it is most univer-
sally known as an EO.)

3. An EO must describe before and after conditions when the EO makes a hard-
ware change in an existing drawing.

4. New drawings must be authorized by EO'S. Tne EO'S place the new draWiiiS
in their respective positions within the drawing tree by making proper references t o
the next higher and lower drawings in the tree.

5. An EO must be approved by configuration control management and may be

issued only t o correct an e r r o r o r discrepancy or t o implement an approved modifica-
tion. The only exception to this rule is the temporary EO that is used to allow experi-
mental or short-lived changes in hardware for a definite period of time. At the
termination of this period, the hardware must be returned t o the original configuration,
o r formal modification procedures must be exercised to produce a permanent EO.

43
 6. The quality control section performs the final acceptance inspection of an
EO by comparing it to the affected, parent, and updated drawings and t o the hardware.

7. The EO's may be allowed to build up against a drawing but never t o the extent
that the usefulness of the drawing is destroyed.

8. Each time a drawing is called f o r by anyone, open EO's are automatically

provided with the requested drawing.

9. When a drawing is modified by an EO, the modification is indicated by a re-

vision letter on the drawing.

10. The exact hardware configuration of any simulator can be tracked and iden-
tified by tracking all EO's with the baseline drawings (item 1).

11. Maximum utilization is made of computerized monitoring (particularly in

multiple simulator and multiple configuration situations) of the hardware drawings and
EO definitions of each individual simulator configuration.

Although software accountability appears to be vastly different from hardware con-

figuration activities at first sight, parallel procedures are used to focus upon the s a m e
goals. The Apollo Program provided the most complex simulator software control and
accountability situation known to date and at its peak had three CM simulators and two
LM simulators, each in different spacecraft configurations, concurrently undergoing
some common and some unique spacecraft modifications. Coupled to this activity was
the routine software housekeeping-discrepancy cleanup, which resulted in further im-
pact on the situation. Fortunately, very early in the Apollo Program the master load
concept was organized and executed, and it represents the present state of the art in
simulator software accountability. The m a s t e r load operation, the use of which has
made the described situation workable, is summarized as follows:

1. As was the case in hardware accountability, the first o r d e r of business is the

establishment of one software program that operates on all common simulators with
defining mathematical model and program-listing documentation.

2. From item 2 forward, no change is made to the assembly, o r m a s t e r load,

without a software change request (SCR) -the authorizing software configuration change
document.

3. An SCR may be generated only t o implement a modification o r to c o r r e c t a

discrepancy in the software. The SCR's are reviewed and approved by one centralized
group before being coded for use. A temporary SCR is used with the s a m e ground r u l e s
and restrictions as the temporary EO.

4. Under normal circumstances, no newly added, revised, o r corrected software

is made directly in the assembly.

5. Routinely, all software changes o r additions (modifications of discrepancy c o r -

rections) are approved first as a patch to the existing load by all parties concerned.
Specifically, the new work is verified as a parallel piece of software by exiting and
entering the existing load at appropriate points. Thus, the load software represents a

44
fail-safe capability that prevents the affected program or subroutine from degenerating
t o a state any less desirable than that prevailing before a modification.

6 . Item 5 may be implemented by card patches o r octal tape techniques, which-

ever is e a s i e r for the particular simulator o r rate-of-change traffic.

7. All approved modification and discrepancy patches (SCR's) are recorded and
approved for the next scheduled assembly. It is highly desirable to minimize this re-
cording effort by automating (computerizing) the off-line capability to do so. (At the
time of this writing, this activity is in work for the Apollo Program simulators. 1

8. The frequency of new loads o r assemblies is dictated by the quantity of ap-

proved patches and the associated core and timing penalties. During the Apollo Pro-
gram, new assemblies were generated every 3 to 4 months.

9. Software mathematical models are updated and referenced to approved SCR's

by using the same logic and requirements used for the hardware drawing and the asso-
ciated EO. The SCR is the software change-defining document.

10. When a software mathematical model is called for, all open approved SCR's
a r e provided automatically.

11. Traceability exists between SCR's, patch (listing), controlling paperwork

(discrepancy report or modification), and, if approved, the SCR occupation in the next
new load.

12. The octal training tape technique also should be examined f o r usefulness and
application to a specific simulator program. This approach uses two octal tapes, one
containing all newly created work and the other containing all newly approved work.
Work is shifted (approved) from one tape to the other and, f o r crew training, the load
2nd the octal tape with approved softx72re are used. Naturally, the next new assembly
adds to this approved software and the cycle repeats itself. The advantage of this oper-
ation is that new software work can be used a l m o s t immediately without waiting for a
new assembly. At the same time, approved software is segregated from developmental
o r unapproved software and preserves the configuration and operational integrity of the
simulator.

Concluding Remarks
Because of the continuing changes of both the spacecraft and mission, and the
necessity for a correspondingly prompt and accurate method of updating the flight crew
simulators, a systematic method of simulator configuration management is a confirmed
requirement. The Apollo Program provided the most s e v e r e requirements and prob-
lems encountered t o date in this area. These requirements and problems were satis-
factorily met and resolved. The viable methods of simulator configuration management
that were developed and refined during the Apollo Program should lend themselves di-
rectly to future programs.

45
 CONCLUSIONS

Because of the total-commitment and economic aspects of manned space flight,

the use of comprehensive, high-fidelity simulators f o r flight crew training will continue
as a f i r m requirement in future programs. Through space-flight experience and the
development of simulators to meet the training requirements, a number of factors have
been established as basic in providing the required simulation fidelity.

1. A high degree of crew-station detail, particularly in the full-mission simula-

t o r s , is necessary to simulate accurately the spacecraft performance and mission char-
acteristics. In addition to a complete simulation of the spacecraft controls and displays,
such items as stowage provisions, lighting, a u r a l cues, and crew-station hardware are
extremely important in providing this required fidelity.

2. Visual display systems providing out-the-window simulation of visual tasks are

mandatory f o r accurate flight simulation.

3 . Moving-base simulators add a necessary degree of realism in certain phases

of spacecraft simulation that is important to the total training requirements.

4. A systematic method of simulator configuration management is a necessity.

Acquiring and verifying the spacecraft and mission data, reviewing changes f o r appli-
cability to the simulators, and identifying simulator configuration at any point in time
by correlation with the spacecraft and mission are all necessary p a r t s of this system.
The viable methods of simulator configuration management that were developed and re-
fined during the Apollo Program should lend themselves directly to future programs.

Manned Spacecraft Cente r

National Aeronautics and Space Administration
Houston, Texas, July 14, 1972
076-00-00-00-72

REFERENCE

1. La France, Robert C. : Sixteen Earth-Orbit Film for the Apollo Mission Simulator.
Information Display, vol. 6, May-June 1969, pp. 65-70.
,

46
 A PPEND IX
SIMULATOR DESCRIPTION

PROJECT MERCURY

Mercury Procedures Simulator

Two MPS's (fig. l), one housed at Langley Field, Virginia, and the other in the
Mercury Control Center at KSC, were the main crew simulators for Project Mercury.
Both simulators used small, although somewhat different, analog computers to drive
the equations-of -motion simulations. All spacecraft systems were simulated actively
by hardwired electronic circuitry with the capability of introducing approximately
276 separate system failures. The simulator at Langley Field had an active periscope
display consisting of a moving dot (on the face of a CRT), which was activated by a hand
controller through the analog computer. Late in the program, an out-the-window dis-
play was added t o this simulator.

Centrifuge
The centrifuge located at the Naval Air Development Center, Johnsville, Pennsyl-
vania (fig. 18), was used to provide the Project Mercury crews with training f o r the
launch, launch abort, and entry phases under simulated acceleration loads. The accel-
eration simulation was mechanized in both closed- and open-loop modes through the
Aviation Computer Laboratory analog computers. Initial runs were made in the closed-
loop mode, in which the resulting acceleration profile as well as the panel displays
responded t o inputs from the pilot's hand controller. Analyses of these first runs indi-
cated that adequate training could be obtained by simply preprograming the acceleration
profiles (open loop). In subsequent centrifuge training, only the displays were integra-
ted with the computer to respond to the pilot's inputs. The cockpit equipment included
individual crew couches, restraint systems, the spacecraft hand controller, and a por-
tion of the spacecraft instrument panel with emphasis on the sequence telelights.
Training was accomplished with both soft and hard pressure-suit operations. Manual
control of the spacecraft, including manual retrofire maneuvers and simulated system
failures during launch and entry, was covered in the training.

Air-Lubricated Free-Attitude Trainer

The ALFA simulator (fig. 12) was a moving-base device consisting of a Mercury-
type couch supported by a 5-inch-diameter spherical air bearing to provide a close sim-
ulation of spacecraft rotational motions. No computer was used; rather, the simulator
was a direct analog of the spacecraft using compressed air j e t s as the attitude ,

47
reaction-control forces. For the cockpit displays, actual spacecraft hardware was
used to measure the attitudes and rates and to display these values to the pilot. A sim-
ulated out-the-window display was provided. (A detailed description is provided in the
section entitled "Moving-Base Simulations. 'I)

Part-Task S i mulator s
Two part-task simulators (fig. 24) provided the first simulation of the astronaut's
control tasks in Project Mercury. Both simulators used analog computers. The tasks
simulated included changing spacecraft attitude in orbital flight (including orientation
for retrofire), holding r e t r o f i r e attitude in
the presence of retrorocket misalinements,
and damping pitch and yaw oscillations
through the entry.

GEMINI PROGRAM

Gemini Mission Simulators

Two GMS's (fig. 2) were the principal
crew-training devices f o r the Gemini P r o -
gram. One was located at MSC in Houston
and the other at KSC. The G M S provided
simulation of the Gemini spacecraft, the
Gemini launch vehicle, the ground tracking
sites, and the Agena target vehicle. The
GMS could be operated as an independent
crew simulator o r integrated with the MCC
f o r combined flight crew and flight controller
training. The simulator included a high-
fidelity representation of the interior of the
Figure 24. - Mercury part-task trainer. spacecraft crew station, an instructor's con-
sole with a capability to insert m o r e than
600 different system malfunctions, and a computer complex consisting of t h r e e digital
computers. Infinity optical display s y s t e m s were used to provide dynamic out-the-
window scenes including the moving earth, stars, and Agena target vehicle.

Dynamic Crew Procedures Simulator

This moving-base simulator (fig. 21), located at MSC, provided Gemini mission
training in the launch, launch abort, and entry phases. The gondola was supported in
a s e t of gimbals that accommodated a Gemini crew station. The gimbals w e r e driven
in conjunction with a visual display to provide rotational cues and initial g-force onset
typical of launch vehicle lift-off. In addition, the launch-phase environment was closely
simulated by providing launch vehicle noise and vibrations. The DCPS was driven by a
hybrid setup consisting of a digital computer and an analog computer.

48
 Translation and Docking Simulator
The TDS (fig. 20) was designed t o provide crew training for the last 100 feet of the
orbital rendezvous - the final closure and docking. The simulator provided six de-
g r e e s of freedom with the proper combination of motion of the crew station (spacecraft
mockup) and the simulated Agena target vehicle. Both the spacecraft carriage and the
target vehicle were supported on air bearings to provide the low friction required to
simulate the small, precise motion of orbital flight. Various lighting conditions and
control modes were provided in the training operation. In addition to the docking ma-
neuver, the simulator provided a training capability for formation flying and target-
vehicle inspection. The simulator was driven by analog computers.

Centrifuge
The Naval Air Development Center centrifuge (fig. 18) at Johnsville, Pennsyl-
vania, was used to provide launch, launch abort, and entry acceleration training for the
Gemini astronauts. The cockpit was configured to simulate the Gemini command pilot's
station. The acceleration profiles were preprogramed; however, the entry dynamics
as displayed to the pilot on his cockpit instruments were closed loop with the analog
computer. Suited runs were made to include the effect on the control task of both soft
and hard (pressurized) modes of suit operation.

APOLLO PROGRAM

Command Module Simulator

Three CMS's (fig. 3), one located at MSC and two at KSC, provided the major
portion of the CSM crew training for the Apollo Program. The t h r e e simulators were
designed and maintained to be identical for maximum modification and operation effi-
ciency. The CMS was capable of accurately simulating all phases of the CSM operation.
Each CMS consisted of a high-fidelity representation of the spacecraft interior, an
accurate presentation of exterior visual scenes through an infinity optics display sys-
tem, an operator console, and a computer complex. The computer complex consisted
of four digital computers, one of which was assigned solely to simulation of the onboard
guidance computer. The CMS could be operated independently, integrated with either
the MCC or the LMS, or integrated with the MCC and the LMS in a complete mission
simulation mode. Beginning with training f o r the Apollo 10 mission, a fifth computer
was added to each CMS to provide a simulation of the Apollo/Saturn V launch vehicle.

Lunar Module Simulator

Two LMS's (fig. 4), one located at MSC and the other at KSC, provided the train-
ing f o r the LM portion of the Apollo missions. The two simulators were designed, built,
and maintained to be identical. They consisted of an instructor and operator control
console, an infinity optics display system f o r complete out-the-window scene simulation,
a high-fidelity representation of the LM crew station, and a three-machine digital com-
puter complex. The digital computers were the same as those used in the CMS. Also
as in the CMS, one computer was assigned exclusively to simulation of the onboard

49
guidance computer. A significant portion of the LMS, which provided training for final
touchdown, was the L&A visual display system. This system included a lunar t e r r a i n
model (scale 1:2000) of the specific landing site f o r each mission.

Command Module Procedures Simulator

The CMPS (fig. 6) was developed originally from the GMS and was used exten-
sively for procedures development and verification in addition to providing crew training
in the various flight modes. This simulator, along with the LMPS, was driven by a
large second generation digital computer. The CMPS included the CSM guidance, navi-
gation, and control system; the stabilization and control system; and the propulsion sys-
tem, in addition to the guidance computer functions that were required to perform the
rendezvous maneuvers and earth entry. An out-the-window scene, which included stars,
the earth, and a target model, was provided through a n infinity optics system.

Lunar Module Procedures Simulator

The LMPS (fig. 7) was operated in conjunction with the CMPS and w a s driven by
the same computer system. Also like the CMPS, the LMPS was capable of simulating
all the LM guidance and control systems, and all appropriate controls and displays.
The visual display system used infinity optics to provide horizon and surface features,
s t a r s , and the CM target.

Dynamic Crew Procedures Simulator

The DCPS (fig. 9) for the Apollo Program training was modified by replacing the
Gemini Program configured gondola with a CM crew station. In addition to providing
launch, launch abort, and entry training, the simulation was expanded to cover the .
translunar injection maneuver, including the manual backup mode during this phase.
The increased complexity of the Apollo Program required the addition of another digital
computer to the existing hybrid setup used during the Gemini Program.

Translation and Docking Simulator

At the conclusion of the Gemini Program, the TDS (fig. 8) was modified to provide
training for the Apollo LM-active docking. The LM-active mode (rather than CM-
active) was simulated as it represented the more difficult task because of the range of
control available, and docking was conducted with the view through the overhead window
of the LM. An LM crew station was installed as the active vehicle, and a modified CSM
qockup replaced the Gemini Agena as the passive target vehicle. For the initial Apollo
flights, training for the CM-active mode was provided on the NASA Langley Research
Center full-scale rendezvous docking simulator (RDS)(fig. 19). For later missions,
the docking model system in the mission simulators was improved to a level that enabled
discontinuation of training on both the TDS and the RDS.

50
 Centrifuge
The MSC centrifuge (fig. 25) was
used to provide Apollo Program crew train-
ing in the u s e of the entry monitor system
during simulated lunar-return entry and
associated acceleration conditions. The
simulated cockpit in the gondola included
three crew couches, an entry monitor sys-
tem, a flight director attitude indicator, a
gravity meter, and the right-hand rotational
hand controller. Five computers, three
analog and two digital, w e r e used to simu-
late the vehicle dynamics and t o drive the Figure 25. - Centrifuge (Manned Space-
centrifuge. craft Center).

Lunar Landing Training Vehicle

The free-flight LLTV (fig. 5) was designed to provide Apollo Program crews ex-
perience in the handling characteristics of the LM during the final portion of the lunar
descent and touchdown. The LLTV used a vertically mounted, gimbaled jet engine,
automatically controlled to support five-sixths of the vehicle weight. The remaining
one-sixth was lifted by two 500-pound maximum thrust, throttleable lift rockets to sim-
ulate the LM descent engine. The cockpit included an LM three-axis attitude control
assembly, the throttle f o r the lift rockets, a horizontal velocity indicator, the altitude
and altitude-rate tape indicators, and a thrust-to-weight indicator. Although the pilot
of the LLTV w a s seated because of the necessity for a rocket-propelled ejection seat,
the location of the flight instruments and controls relative to the pilot's hands and eyes
was similar to that in the LM.

Lunar Landing Training Vehicle Simulator

The fixed-base LLTV simulator (fig. 22) was built and located a t MSC to provide
flight-crew familiarization with the LLTV systems, procedures, flight trajectories,
and control system characteristics. The major systems that were simulated included
jet engine, rocket propulsion, electrical, electronic control, and jet-engine attitude
control. The equations of motion were programed on two analog computers. A visual
system was used for display of a simulated runway scene.

Lunar Landing Research Facility

The lunar landing research facility (LLRF) (fig. 16) was a r e s e a r c h device (loca-
ted at Langley Research Center) that was used to provide initial training. The LLRF
used a cable tether system to support five-sixths of the crew-station weight and a hydro-
gen peroxide system for attitude control.

51
 Partial -Gravity Si mulators
Two dynamic simulators were designed and operated to provide astronaut training
for the 1/6-g lunar-surface operations. Both simulators incorporated a uniquely de-
signed overhead support system, which provided lifting f o r c e equal t o five-sixths of the
astronaut's total weight (suit, backpack, etc. ). The vertical servosystem of the partial-
gravity simulator (fig. 14) was suspended f r o m an overhead monorail. This concept
was subsequently adapted to a truck body f o r the mobile partial-gravity simulator
(fig. 15) and thereby provided essentially unlimited fore-and-aft mobility.

NASA-Langley, 1973 -31 S-346