Search NASA⌕ Search

SEARCH · Search NASA

Results for “Mission Control Center Operations (MCC / MER)”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

Backup Optical Navigation Attitude for Artemis-1 Backup Attitude Ground Tool

The Backup Optical Navigation Attitude (BONA) software was developed as a response to the Artemis1 Power Distribution Unit (PDU) hardware problems found early in 2021. The hardware problem, a capacitor installed incorrectly, removes the intended redundant path for which the PDU can relay its power and data to attached devices. Specific to the BONA context, the concern is that a failure of the single remaining path in this PDU would lead to an inability to communicate with one of the two-star trackers (STs) on Orion. By flight rule, being reduced to a single star tracker means an immediate turn around end-of-mission. The BONA software is not intended to extend the mission, but instead act as a single star tracker attitude confirmation tool. Insurance, if you will, for the Orion project that a ground tool is available to compare the single remaining ST results with optical navigation images retrieved during the mission. Engineers operating BONA in the Mission Control Center (MCC) Mission Evaluation Room (MER) will analyze the downlinked star field images and based on the stars identified and known time of image, derive vehicle attitude estimates, which can be compared with the ST results. Potentially, in extreme situations, and with expert recommendation, the derivations could lead to navigation state updates being commanded to Orion.

GNC↗

On-Orbit Engineering and Vehicle Integration Poster Presentation

One of the duties of the MER Managers is getting the consoles to review and sign Electronic Flight Notes (EFN) and Mission Action Requests (Chit) before they are due. Chits and EFNs and are accessible through the Mission Control Center - Houston (MCC-H) Gateway. Chits are the official means of documenting questions and answers, technical direction, real-time changes to Flight Rules (FR) and procedures, request for analysis, etc. between various consoles concerning on-orbit operations. EFNs are documents used by the Flight Control Team (FCT) to communicate precise details between console positions and manage real time changes to FR and Systems Operation Data File (SODF) procedures. On GMT 2013/345 the External Active Thermal Control System (EATCS) on the Columbus (COL) Moderate Temperature Loop (MTL) Interface Heat Exchanger (IFHX) shut down due to low temperatures. Over the next couple of days, the core temperature of COL MT IFHX dropped due to the failure of the Flow Control Valve (FCV). After the temperature drop was discovered, heaters were turned on to bring the temperatures back to nominal. After the incident occurred, a possible freeze threat was discovered that could have ruptured the heat exchanger. The COL MT IFHX rupturing would be considered a catastrophic failure and potentially result in a loss of the vehicle and/or the lives of the International Space Station (ISS) crew members

Heimerdinger, Madison↗

The Cooling Loop A Anomaly of 2013: A Case Study in Human-Systems Resilience

Throughout the history of human spaceflight, NASA has employed an operational paradigm of 24/7 dependence on experts in Mission Control Center (MCC). In addition to nominal flight control and mission operations, these 85+ experts per shift manage anomaly detection, diagnosis, and response, and support the crew in real-time in performing maintenance and repair, procedure execution, and other complex mission operations. Future long-duration exploration missions (LDEMs) beyond low-Earth orbit (LEO) will not operate successfully using this same Human-Systems Integration Architecture (HSIA) where crew rely on ground controllers, have ready access to resupply, and have a fallback plan of evacuation. As distance from Earth increases and the communication delay grows, crews will need to respond independently and adequately to time-critical vehicle malfunctions. It will not always be sufficient or even possible to ‘safe the system’ and then wait upon ground intervention. A new and radically different HSIA is needed to accommodate the paradigm shift of deep-space travel. Historical International Space Station (ISS) data show that for a 30-day mission, the likelihood of a high-consequence vehicle anomaly of uncertain origin that requires rapid response is greater than 10%. The likelihood of such an event is 50% by the fourth month of the mission, and it grows exponentially with time. Our team has conducted in-depth investigations into these events and their corresponding anomaly resolution activities. Using MCC and Mission Evaluation Room (MER) anomaly resolution artifacts (including meeting summaries, caution and warning data, and ISS daily summaries), we created timelines detailing ground actions and in-orbit events for two significant anomalies. We then mapped these timelines onto Mars transit conditions, introducing a ground-crew communications time delay and shifting immediate response, time-critical task execution, and vehicle commanding to the crew. In detailing successful anomaly resolution in transit to Mars, the timelines highlight where effective resolution requires drastically evolved onboard capabilities. Though this research has yielded a rich data set based on ground response in past missions, there is still insufficient knowledge to assess the potential impact of inflight anomalies on a small autonomous crew on future LDEMs beyond LEO. To begin building an evidence base that will inform future HSIA standards and requirements, we are developing an approach to systematically capture crew anomaly response and procedure execution during early Artemis missions. Being the first human spaceflight beyond LEO since Apollo, early Artemis missions provide a rare and unique opportunity to serve as a testbed for Mars missions. Our work aims to capitalize on planned data collection to derive crew operational responses to anomalous events in real-time. Our team is also researching the level of simulation fidelity required for empirically validating proposed HSIA standards and evaluating HSIA implementations for LDEMs beyond LEO. This work will produce a trade space study of HSIA simulation objectives and fidelity requirements. Ultimately, these research efforts will assist in developing the standards and technologies needed to build a next-generation HSIA for LDEMs beyond LEO.

human-systems integration architecture↗

Conceptual Inquiry of the Space Shuttle and International Space Station GNC Flight Controllers

The concept of Mission Control was envisioned by Christopher Columbus Kraft in the 1960's. Instructed to figure out how to operate human space flight safely, Kraft envisioned a room of sub-system experts troubleshooting problems and supporting nominal flight activities under the guidance of one Flight Director who is responsible for the success of the mission. To facilitate clear communication, MCC communicates with the crew through a Capsule Communicator (CAPCOM) who is an astronaut themselves. Gemini 4 was the first mission to be supported by such a MCC and successfully completed the first American EVA. The MCC seen on television is called the Flight Control Room (FCR, pronounced ficker) or otherwise known as the front room. While this room is the most visible aspect, it is a very small component of the entire control center. The Shuttle FCR is known as the White FCR (WFCR) and Station's as FCR-1. (FCR-1 was actually the first FCR built at JSC which was used through the Gemini, Apollo and Shuttle programs until the WFCR was completed in 1992. Afterwards FCR-1 was refurbished first for the Life Sciences Center and then for the ISS in 2006.) Along with supporting the Flight Director, each FCR operator is also the supervisor for usually two or three support personnel in a back room called the Multi-Purpose Support Room (MPSR, pronounced mipser). MPSR operators are more deeply focused on their specific subsystems and have the responsible to analyze patterns, and diagnose and assess consequences of faults. The White MPSR (WMPSR) operators are always present for Shuttle operations; however, ISS FCR controllers only have support from their Blue MPSR (BMPSR) while the Shuttle is docked and during critical operations. Since ISS operates 24-7, the FCR team reduces to a much smaller Gemini team of 4-5 operators for night and weekend shifts when the crew is off-duty. The FCR is also supported by the Mission Evaluation Room (MER) which is a collection of contractor engineers who provide analysis and long-term troubleshooting support. Each MER operator is an expert in a very small portion of a sub-system and each FCR console usually interfaces with several MER positions.

Kranzusch, Kara↗