Diagram based on descriptions in ref.5
|
|
|
The RTCC Controllers
|
|
SELECT - Tracking Data Select Controller
Was responsible for the RTCC processing and evaluation of all tracking data.
DYNAMICS - Flight Dynamics Processing Controller
Was responsible for RTCC processing related to trajectory control.
COMPUTER COMMAND - Computer Command Controller
The responsibility of this controller pertained to:
- RTCC Digital Command System processing;
- retrofire and reentry planning;
- and recovery support.
COMPUTER TM - Telemetry Processing Controller
Was responsible for all RTCC processing of telemetry data.
SUPPORT - RTCC Select Support Controller
The select support controller provided advise on trajectory and orbit determination. In that role it also provided assistance to the Tracking Data Select Controller.
|
RTCC CMCC - RTCC Computer Monitoring & Computer Control
COMPUTER SUPERVISOR - RTCC Complex Supervisor
Was responsible for the overall RTCC operation.
COMPUTER M & O - Computer Maintenance & Operations Support
This name must be considered as a station designation.
Behind this station the RTCC director and the M&O supervisor were residing. They were responsible for all of the RTCC computer related hardware configurations and their functioning.
ALSEP - ALSEP Computer Controller
|
|
The MOCR Controllers
|
|
FLIGHT - Flight Director
The flight director, FLIGHT, can be compared to an orchestra leader. FLIGHT had ultimate authority to do anything necessary to ensure the crew's safety and the mission's success, in that order of priority.
AFLIGHT - Assistant Flight Director
Duplicating the flight director's duties, monitoring the mission and supplementing the flight director's control.
CAPCOM - Capsule Communicator
Was usually a colleague astronaut and was in his role as flight controller the only one in the room who was allowed to talk directly to the spacecraft's crew.
INCO - Instrumentation and Communication Officer
INCO monitored the communications systems for both the Command Module and the Lunar Module, taking these tasks from EECOM and TELMU respectively.
O & P - Operations and Procedures
Making sure that flight controllers followed all of the procedures when asking for data or communicating with people, all according to flight control operations handbook.
FAO - Flight Activities Officer
FAO, was the timeline manager for the mission and ensured that the preplanned activities for each mission were occurring on schedule.
NETWORK - Network Controller
NETWORK functioned as the interface with the global network of MSFN data collection and transmission stations which served NASA.
(MSFN: The Manned Space Flight Network was a set of tracking stations built to support the American Mercury, Gemini, Apollo, and Skylab space programs)
EECOM - Electrical, Environmental and Communications
Watching over the Command and Service Module's electrical and environmental systems.
The "communications" part was moved over to INCO after the Apollo 10 mission to ease the elaborate task of EECOM.
|
GNC - CSM Guidance, Navigation and Control
The GNC operator monitored the state of the reaction-control systems and the Service Module's main engine, as well as the hardware components of the spacecraft's guidance systems.
TELMU - Telemetry, Electrical and EVA Mobility Unit
Watching over electrical and environmental systems of the Lunar Module and the Lunar suits.
CONTROL - LM Guidance, Navigation and Control
The CONTROL operator monitored the state of the reaction-control systems, the descent and the ascent engines of the Lunar Module, as well as the hardware components of the spacecraft's guidance systems.
BOOSTER - Booster System Engineers
Monitoring the performance of all three stages of the Saturn V
FDO - Flight Dynamics Officer
Monitoring the flight trajectory of the launch vehicle and the spacecraft. FDO was also responsible for producing the data to compensate for flight path deviations.
GUIDO - Guidance Officer
Ensure that the Apollo Primary Guidance, Navigation and Control Systems (PGNCS) on both the Command Module and the Lunar Module operate correctly.
RETRO - Retrofire Officer
Is reponsible for getting the spacecraft back in case of mission abort and during the return phase of a mission. During the mission RETRO always kept a list of abort options to take swiftly adequate actions in case of emergencies.
SURGEON - Life Systems Officer / Flight Surgeon
Medical doctor who monitored the health of the crew.
|
|
The Intercom Keyset Unit
|
Copied from ref.12
Credit to Andy Anderson
This picture above of the Keyset Unit has been copied with permission out of his drawing of the EECOM console as configured for supporting the Apollo 13 mission.
|
Each station or controller console was equipped with a keyset unit as shown on the left. This keyset unit was part of an elaborate intercom system and enabled the controller to select from various voice loops of the intercom system. It also enabled the controller to use the normal telephone system.
A voice loop could be used in two different modes:
- A monitor mode in which the controller was constantly listening in on the loop.
- A listen/talk mode in which the controller could make a call to another controller on that loop or participate in an ongoing conversation.
There was one key for each mode. To monitor a voice loop, the monitor key had to be pressed, and the key lit up yellow. As soon as another controller would use the voice loop, the listen/talk key would light up white. The present controller could participate in the call by pressing the listen/talk key; this key would then start flashing white to indicate that the microphone is active.
For those voice loops for which it would only be required to listen/talk but not to monitor, only the listen/talk key could be found on the Keyset Unit. If the loop was used by somebody, the key would light up white, but audio was not reproduced. By pressing the lit key, the controller could listen and talk; the lit key went from steady white to flashing white.
|
|
|
Voice loops between CCATS, RTCC and MOCR
|
|
There were various voice loops available to enable the controllers to communicate with each other. In the MCC there were many voice loops to organize the communication around a category of activities or responsibilities, much like how WhatsApp groups are organized today.
All the voice loops depicted above were monitored constantly by at least one controller, meaning all the controllers involved were supposed to listen in continuously. By pressing an appropriate button on the Intercom Keyset Unit, a controller was enabled to speak on that particular voice loop. Since controllers had to listen in on many channels simultaneously to maintain a mission situational awareness, there was a way to manage the stream of audio information by controlling the volume of the individual voice loop channels.
Usage modes of the voice loops
Voice loop "MOCR DYN" was monitored by the RTCC controllers SUPERVISOR, DYNAMICS and COMPUTER TM and by the MOCR controllers GNC, CONTROL, FIDO, GUIDO and RETRO.
This voice loop was primarily used to discuss matters or exchange information on trajectory control.
The remaining MOCR controllers also had access to this voice loop, but they were not able to monitor this loop. They were only able to initiate a call or participate in an ongoing conversation, as denoted by the one-direction arrows.
Voice loop "RTCC TLM" was only monitored by RTCC controller COMPUTER TM to be alert to any request or any question from an MOCR controller. This voice loop was not monitored by the MOCR controllers.
The voice loop "FD" was used by the flight director to manage the MOCR controllers and the RTCC supervisor. Via this voice loop the supervisor kept FLIGHT informed about the status and the conditions of the MOC and the DSC. It underlines the importance of the RTCC providing support to MOCR. Without the RTCC, the MOCR controllers would be virtually blind.
The voice loop "RTCC CA/CB" was monitored by all the RTCC controllers and the MOCR controller NETWORK. The RTCC supervisor was the point of contact for NETWORK.
The voice loop "RTCC DYN" illustrates the required intensity of communication between FIDO, RETRO and the Computer Command Controller during a mission. The RTCC mainframes provided computational support during the mission. To make optimum use of the mainframes, the mission was divided into phases. For each phase a computer program subroutine was written to provide the support. Each phase and the transition between phases were meticulously monitored jointly by the RTCC supervisor, the Computer Command Controller, FIDO and RETRO. An emergency during launch, for example, would have triggered an abort for which it was required to force the computer to go into mission phase "Abort (Mode I, II, III)" and immediately start running the appropriate program subroutine to produce the required trajectory data for a safe return.
The tasks of FIDO and RETRO also encompassed submitting computational requests to the Computer Command Controller via "RTCC DYN" on a regular basis to anticipate eventualities or to have trajectory options available on request.
The "re-entry" phase apparently did require intensive consultation between the RETRO and the Computer Command Controller to have a dedicated voice loop "REENTRY SUPPORT" justified for those two controllers. The RTCC Supervisor was monitoring this voice loop.
|
|
|
CCATS, RTCC and MOCR for sending commands to the spacecraft
|
|
The Command Subsystem
The Command System was also known as the Universal Command System or the Apollo Digital Command System (DCS).
This system enabled the mission controllers to command the computers of the Saturn launch vehicle (LVDC), of the Apollo Command Module (AGC) and of the Apollo Lunar Module (LGC) remotely. During an Apollo mission, data and commands were sent to those computers to enable the mission controllers to update data and software and to operate the spacecraft's subsystems remotely via the onboard computers.
Command load messages and real-time commands
The data packages and the software updates were called command load messages and were used to update the navigation and guidance systems.
The commands to operate the spacecraft systems were called real-time commands (RTCs).
RTCs were prepared for the start of each Apollo mission and were dispatched to remote tracking stations and stored, ready to be uplinked to a spacecraft when required.
During the Apollo 11 mission, about 106 command loads were generated; 15 of them were "premission", prepared prior to the mission. The majority of the command loads had to be prepared during the mission because their content depended on the most recent telemetry and trajectory data.
Interplay between MOCR, RTCC and CCATS to generate and to send command load messages
According to ref.11 on page 9-6, the controllers BOOSTER, RETRO, FIDO and GUIDO were able to request the generation of command loads.
According to the voice loop configuration as depicted above, the voice loops "RTCC DYN", "REENTRY SUPPORT" and "RTCC CMD NET" were used by these four MOCR controllers to request a so-called command load generation. These three voice loops were monitored by the RTCC Computer Command Controller, who was responsible for generating the command loads.
Requests could also be submitted by sending request forms via the pneumatic tube system containing the most recent telemetry and trajectory data, which needed to be incorporated into the generation process.
The RTCC assigns unique 4-digit load numbers to each generated command load message. Each command load message was reviewed by a MOCR controller before it was transferred from the RTCC to CCATS for approval and formatting of the message to have it transferred to one or more remote tracking stations.
Command panels for mission controllers
The consoles of MOCR controllers BOOSTER, GUIDO, INCO and CONTROL were equipped with command panels to request an uplink of a specific command load to a spacecraft. These command panels also enabled the controllers to uplink so-called Real Time Commands (RTCs) to flip a valve or switch on equipment remotely. These command panels can be considered as the MOCR user interface with the Command Subsystem.
More information about the use of the command system can be found on these pages:
- "The Command Subsystem"
- "User procedures for the Command Subsystem"
Note:
This page contains message sequence diagrams which depict the interaction between MOCR, RTCC, CCATS, the Goddard Space Flight Center, the remote tracking station and the spacecraft to uplink command load messages and real-time commands.
Furthermore, command panels used by the MOCR controllers are depicted on this page. However, the page itself functions as a tool to gather information about how the panels have been actually used.
Voice loops and the Command Subsystem
Since consultation between the MOCR, RTCC and CCATS was pivotal to operate the command subsystem properly, the voice loops had an important function.
The voice loops were organized to optimize the communication between the officers in MOCR, RTCC and CCATS for particular tasks or mission phases. For example:
The voice loop "RTCC CMD NET" provided the possibility for quick and efficient consultation between BOOSTER, GUIDO, the RTCC Computer Command Controller, the CCATS Computer Command Controller and the CCATS Command Load Transfer Controller during the generation of a command load, its CCATS validity check, during the formatting of the command load message and the transfer of the message to the remote station.
The voice loop "REENTRY SUPPORT" was dedicated to the critical reentry phase of a mission. Unlike the officers BOOSTER, GUIDO, INCO AND CONTROL, the RETRO console was not equipped with command panels. However, via voice loop "REENTRY SUPPORT", RETRO could request a data update to be uploaded by the COMPUTER COMMAND CONTROLLER via the Command Subsystem system.
|
|
