How much technical information is given to astronauts on a spaceflight? How much of it is left to the control center?

Question

In many space exploration movies, we see that the control center, most notably the Mission Control Center has a team of engineers and scientists communicating with the astronauts regarding a variety of things like altitude, propulsion, etc.

But we also see that the astronauts themselves have a lot of technical understanding. They take exams, undergo severe training, etc.

So just how much more information/help does the MCC provide? In other words, for what reasons/data do the astronauts rely on the MCC for, that they cannot possibly realize or figure out themselves?

I was not sure as to how much more data the MCC has because it seems to me that almost all of the data that the MCC provides to the astronauts would already be accessible to them inside the spacecraft (like the fuel loads, the altitude, which engines are functioning, the speed, the thermal values, etc.).

Answer 1

At least for shuttle, the MCC had a lot more detailed information than the crew does.

The crew was only provided with the information necessary for situational awareness and procedure execution. The MCC got a lot of detailed engineering data that the crew would not normally need. If they did end up needing it, they could get it from the MCC.

Here are some examples for a single system, the Remote Manipulator System (the robot arm).

The crew had a control panel that provided them with status indicator and caution lights, a rate meter, and three digital displays that could display one of 7 sets of data at a time.

(Personal photograph from shuttle Endeavour)

They also had two computer displays. One provided status information, much of which was duplicated on the hardware panel. The second provided more detailed information on malfunctions.

(Source: DPS Dictionary)

The Payload Deployment and Retrieval System flight controllers had access to much more information. Some of their displays are shown in this picture.

(Personal photo)

They also had generic capabilities like plotting graphs of any desired telemetry parameter.

---

A simple example of the difference between what the crew saw and the flight controller saw is as follows:

Let's say the crew encountered a malfunction of the arm's end effector while grappling a payload. The crew would get a caution light and tone, a fault message on the CRT screen, and possibly one or more "down arrows" under the CHECK CRT heading on the malfunction computer screen. The control panel also had six "talkbacks" giving information on the status microswitches in the end effector.

The flight controller would see the parameters that drove all these crew displays, and much more:

• Plots of the current being drawn by the motors in the end effector mechanism.
• Detailed telemetry information about the end effector drive commands generated by the Manipulator Control Interface Unit (MCIU) firmware in response to crew commands.
• Event time logs showing precisely when crew commands were entered in relation to when error messages or relevant telemetry data were emitted
• Telemetry showing whether relevant switch contacts are "made" or "broken" corresponding to the physical switch position
• Status of other internal flags generated by the MCIU according to its interpretation of the grapple's progress
• Built-In Test Equipment (BITE) status generated by the system

The flight controllers also had access to reference information not available to the crew: software listings, detailed schematics, engineering support from the Mission Evaluation Room, etc.

Answer 2

I supported several visiting-vehicle-to-ISS rendezvous from the Mission Evaluation Room (MER) that Organic Marble mentions in his answer (supporting RPOP), and was involved in some of the procedures development and training for using RPOP for crewed vehicle rendezvous. This could be considered a continuation of Marble's answer into post-Shuttle operations.

For these less-critical functions (we were supposed to be go for rendezvous if RPOP failed... and then we delayed rendezvous during Crew Dragon DM-1 because one of the RPOP laptops wouldn't talk to the data source) crew were taught how to use the tool, given procedures for how to fix it if it broke in the most likely ways, and then had subject-matter-expert backup on the ground for the things that were harder to predict. I was also there to confirm the tool was operating properly, by running a separate copy on the ground using a copy of the data the on-orbit software was receiving.

A lot of the nature of the job I had (continuing development of a situational awareness tool) was trying to give the crew just enough technical information for them to make a call (do we trust that the vehicle is safely navigating to the station, or not?) and eliding the rest. Technically the raw information was available elsewhere (and I think at least once I was told by someone in the Mission Operations Directorate that they'd rather use that instead), but there's only so much attention the crew has to give compared to the amount of attention possessed by the small army on the ground.