“From a slightly different perspective…”

By Tom Sheehan, Apollo “Houston Track” & “Network”. August 2011.

Tom Sheehan (right) receiving a citation from Director of Flight Operations Chris Kraft – photo taken just before Apollo 10 (note the MCC mission badge). The citation was for support of Apollo 8.

This article references a 1972 article titled, “A Look at Apollo Ground Support Control” by Richard Stachurski and published in the USAF “Air University Review”. His article was well-written and probably at the right level for the intended readership. However, as a more-or-less contemporary in the Apollo ground support control endeavor, I have a slightly different perspective.

As Richard noted, his time at the NASA Mission Control Center in Houston was as a USAF detailee. Most of the original cadre of Network Controllers were from the USAF and performed well in the pressure-filled environment of real-time flight operations.

My perspective is from a background of:

1. operations support on several national test ranges;
2. installation, modification & acceptance testing of instrumentation radars for several of these ranges as a manufacturer’s field engineer;
3. service as a GSFC team member of the Gemini Network Support Team (NST) as a Radar Support Controller;
4. being the NASA group head of the Tracking Controller discipline of the Apollo Instrumentation Support Team (IST);
5. being a Network Controller for later Apollo missions. (Several members of the TRACK group also had similar range, NST & IST experience.)

The NASA Goddard Space Flight Center (GSFC) was the implementer of the Manned Space Flight Network (MSFN) for the Mercury, Gemini & Apollo programs with major evolutions of equipment and communications during these programs. They provided the engineering oversight and configuration management of the network throughout these programs. GSFC also provided maintenance & operations of the MSFN through international and US DOD agreements, and with contractor support.

Not being personally knowledgeable about Mercury, I will only address the Gemini and Apollo Mission Control Center (MCC) relationships with GSFC and the MSFN.

When the Houston MCC became operational in Gemini, GSFC & DOD deployed a Network Support Team (NST) to the MCC for each mission, to provide resident experts in the various network instrumentation systems. Personnel were variously NASA civil servants, military and contractors. A senior member served as Team Chief and the team functioned as staff support to the Network Controller on the Flight Control Team in the Mission Operations Control Room (MOCR).

While the Gemini network support was provided by separate systems for command (CMD), telemetry (TLM), air/ground voice (A/G) and tracking (RADAR), the main Apollo support was to be provided by an integrated system; the Unified S-Band (USB) system. This was to have a profound effect on the composition of the MCC support team. Each discipline would be more capability/data oriented rather than system oriented.

This new focus and the planned fast-pace of the Apollo program, coupled with the increased usage of integrated simulations and overlapping mission preparation, created the need for a permanent, resident Instrumentation Support Team (IST) at the Houston MCC. Therefore, the IST was formed with the makeup as Richard described in his article.

A permanent Network Support Team (NST), under a Network Operations Manager (NOM), at the GSFC Network Operations Control Center (NOCC) supported the MSFN continuously, overseeing system changes, testing and flight preparation. After Instrumentation Support Instruction (ISI) #1 was issued for a flight, the NST conducted each station’s pre-pass interface testing and “handed-over” the station to the MCC for pass support. They continued to monitor the station support and provided advice and aid as needed to both the station and the MCC.

The fact of an integrated, multi-function system, the USB, was the source of both efficiency and overlap (even conflict) among the various disciplines. For example: TRACK was a member of the Flight Dynamics Team whose need for geometric diversity for the tracking data often created issues at station handovers or AOS. Most of the flight controllers just wanted a quick “go for command” and no interruptions; likewise, CAPCOM wanted continuous A/G voice. Earlier missions (including Apollo 11) had numerous instances of multiple flight controllers requesting changes from the same IST members. The Network Controller was the arbiter. Implementation of the Integrated Communications Officer (INCO) helped this situation significantly.

Regarding the Network Controller/IST working relationship, many of the USAF NC’s were rated (pilots) and others not. Therefore, they had more than one perspective on the job. Some emphasized the ‘control’ aspect and others functioned as ‘team leaders’. Most of the IST members preferred the latter approach. TRACK probably had the most difficult relationship because of multiple “masters”. Mostly this worked out OK.

As an aside, the IST members were almost all contractors and were somewhat older than the MOCR Flight Controllers. Generally, they had served as military technical personnel and many had served as operational and/or support personnel on various test ranges. Most had attended the MSFN level I training at the GSFC Network Test & Training Facility and many visited various MSFN stations; mostly Texas & Merritt Island. Therefore, they had confidence in their own abilities, but were mature enough to respect those in leadership positions.

Other important operational interfaces were with the MSFN stations and the GSFC NST. By and large, the stations did a great job in responding to multiple ‘managers’ while the NST was always vigilant about the IST exceeding their authority. But ops people have a habit of doing whatever is necessary to ‘get the job done’, regardless.

Within the MCC, the most contentious interface was with the Real Time Computer Center (RTCC). Richard explained well that this organization was the only MCC mission support facility that reported directly to the Flight Director, rather than to the Network Controller. The “why” was more political than complexity. IBM was the contractor for the RTCC, not a sub-contractor to Philco. Working relationships did improve over time, but not without tension.

Richard’s explanation of “Network” vs. “Assistant Network” functions originally provided a path for MOCR manning by contractor (Philco) personnel since all of the MCC (except RTCC) were staffed by Philco M&O people. Over time, the distinction disappeared and all functions were performed by both console positions.

The pre-mission Instrumentation Support Plan (ISP) was coordinated by TRACK and provided some insight to everyone on expected support. Other than the summary of view-periods and nominal vehicle and support mode (2-way, 3-way, CSM, LM, ALSEP), not much survived during the actual missions. The real support planning activity occurred during flight, with TRACK responsible for coordinating and sending the Site Configuration Messages (SCM).

The air/ground voice (A/G) configurations grew in complexity with multiple vehicles, relay modes, etc. Eventually the Communications Controller and Communications Technician (COMTECH) defined these as configurations “Alpha” through “Juliet” (or more) and were documented in a published plan. This greatly helped referencing them for implementation, but many were beyond comprehension by other than the people involved.

Richard’s conclusion that the Network Controller/Instrumentation Support Team system worked well is justified by the success of the Apollo missions. It was a system that fit the era, the divided responsibilities for the MSFN/MCC and the limitations of communications and data processing at the time

Tom Sheehan.

(Bold emphasis added.)