Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Troubleshooting”

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.

At least 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

Discovery and Identification of Dimethylsilanediol as a Contaminant in ISS Potable Water

In September of 2010, analysis of ISS potable water samples was undertaken to determine the contaminant responsible for a rise in total organic carbon (TOC). As analysis of the routine target list of organic compounds did not reveal the contaminant, efforts to look for unknown compounds was initiated, resulting in an unknown peak being discovered in the gas chromatography/mass spectrometry (GC/MS) analysis for glycols. A mass spectrum of the contaminant was then generated by concentrating one of the samples by evaporation and analyzing by GC/MS in full-scan mode. Although a computer match of the compound s identity could not be obtained with the instrument s database, a search with a more up to date mass spectral library yielded a good match with dimethylsilanediol (DMSD). Inductively Coupled Plasma/Mass Spectrometry (ICP/MS) analyses showed abnormally high silicon levels in the samples, confirming that the unknown contained silicon. DMSD was then synthesized to confirm the identification and provide a standard to develop a calibration curve. Further confirmation was provided by external Direct Analysis in Real Time (DART) GC/MS analysis. A preliminary GC/MS method was then developed and archived samples from various locations on ISS were analyzed to determine the extent of the contamination and provide data for troubleshooting. This paper describes these events in more detail as well as problems encountered in routine GC/MS analyses and the subsequent development of high performance liquid chromatography and LC/MS/MS methods for quantitation of DMSD.

Rutz, Jeffrey A.↗
NASA NTRS2010

Product Lifecycle Management and the Quest for Sustainable Space Explorations

Product Lifecycle Management (PLM) is an outcome of lean thinking to eliminate waste and increase productivity. PLM is inextricably tied to the systems engineering business philosophy, coupled with a methodology by which personnel, processes and practices, and information technology combine to form an architecture platform for product design, development, manufacturing, operations, and decommissioning. In this model, which is being implemented by the Engineering Directorate at the National Aeronautics and Space Administration's (NASA's) Marshall Space Flight Center, total lifecycle costs are important variables for critical decision-making. With the ultimate goal to deliver quality products that meet or exceed requirements on time and within budget, PLM is a powerful concept to shape everything from engineering trade studies and testing goals, to integrated vehicle operations and retirement scenarios. This paper will demonstrate how the Engineering Directorate is implementing PLM as part of an overall strategy to deliver safe, reliable, and affordable space exploration solutions. It has been 30 years since the United States fielded the Space Shuttle. The next generation space transportation system requires a paradigm shift such that digital tools and knowledge management, which are central elements of PLM, are used consistently to maximum effect. The outcome is a better use of scarce resources, along with more focus on stakeholder and customer requirements, as a new portfolio of enabling tools becomes second nature to the workforce. This paper will use the design and manufacturing processes, which have transitioned to digital-based activities, to show how PLM supports the comprehensive systems engineering and integration function. It also will go through a launch countdown scenario where an anomaly is detected to show how the virtual vehicle created from paperless processes will help solve technical challenges and improve the likelihood of launching on schedule, with less hands-on labor needed for processing and troubleshooting.

Caruso, Pamela W.↗
NASA NTRS2010

Product Lifecycle Management and the Quest for Sustainable Space Exploration Solutions

Product Lifecycle Management (PLM) is an outcome of lean thinking to eliminate waste and increase productivity. PLM is inextricably tied to the systems engineering business philosophy, coupled with a methodology by which personnel, processes and practices, and information technology combine to form an architecture platform for product design, development, manufacturing, operations, and decommissioning. In this model, which is being implemented by the Engineering Directorate at the National Aeronautics and Space Administration's (NASA's) Marshall Space Flight Center, total lifecycle costs are important variables for critical decisionmaking. With the ultimate goal to deliver quality products that meet or exceed requirements on time and within budget, PLM is a powerful tool to shape everything from engineering trade studies and testing goals, to integrated vehicle operations and retirement scenarios. This paper will demonstrate how the Engineering Directorate is implementing PLM as part of an overall strategy to deliver safe, reliable, and affordable space exploration solutions. It has been 30 years since the United States fielded the Space Shuttle. The next generation space transportation system requires a paradigm shift such that digital tools and knowledge management, which are central elements of PLM, are used consistently to maximum effect. The outcome is a better use of scarce resources, along with more focus on stakeholder and customer requirements, as a new portfolio of enabling tools becomes second nature to the workforce. This paper will use the design and manufacturing processes, which have transitioned to digital-based activities, to show how PLM supports the comprehensive systems engineering and integration function. It also will go through a launch countdown scenario where an anomaly is detected to show how the virtual vehicle created from paperless processes will help solve technical challenges and improve the likelihood of launching on schedule, with less hands-on labor needed for processing and troubleshooting. Sustainable space exploration solutions demand that all lifecycle phases be optimized. Adopting PLM, which has been used by the automotive industry for many years, for aerospace applications provides a foundation for strong, disciplined systems engineering and accountable return on investment by making lifecycle considerations variables in an iterative decision-making process. This paper combines the perspectives of the founding father of PLM, along with the experience of Engineering leaders who are implementing these processes and practices real-time. As the nation moves from an industrial-based society to one where information is a valued commodity, future NASA programs and projects will benefit from the experience being gained today for the exploration missions of tomorrow.

Caruso, Pamela W.↗
NASA NTRS2011

Fault Detection, Isolation and Recovery (FDIR) Portable Liquid Oxygen Hardware Demonstrator

The Fault Detection, Isolation and Recovery (FDIR) hardware demonstration will highlight the effort being conducted by Constellation's Ground Operations (GO) to provide the Launch Control System (LCS) with system-level health management during vehicle processing and countdown activities. A proof-of-concept demonstration of the FDIR prototype established the capability of the software to provide real-time fault detection and isolation using generated Liquid Hydrogen data. The FDIR portable testbed unit (presented here) aims to enhance FDIR by providing a dynamic simulation of Constellation subsystems that feed the FDIR software live data based on Liquid Oxygen system properties. The LO2 cryogenic ground system has key properties that are analogous to the properties of an electronic circuit. The LO2 system is modeled using electrical components and an equivalent circuit is designed on a printed circuit board to simulate the live data. The portable testbed is also be equipped with data acquisition and communication hardware to relay the measurements to the FDIR application running on a PC. This portable testbed is an ideal capability to perform FDIR software testing, troubleshooting, training among others.

Oostdyk, Rebecca L.↗
NASA NTRS2011

Discovery and Identification of Dimethylsilanediol as a Contaminant in ISS Potable Water

In September 2010, analysis of ISS potable water samples was undertaken to determine the contaminant(s) responsible for a rise of total organic carbon (TOC) in the Water Processor Assembly (WPA) product water. As analysis of the routine target list of organic compounds did not reveal the contaminant, efforts to look for unknown compounds were initiated, resulting in discovery of an unknown peak in the gas chromatography/mass spectrometry (GC/MS) analysis for glycols. A mass spectrum of the contaminant was then generated by concentrating one of the samples and analyzing it by GC/MS in full-scan mode. Although a computer match of the compound identity could not be obtained with the instrument database, a search with a more up-to-date mass spectral library yielded a good match with dimethylsilanediol (DMSD). Inductively coupled plasma/mass spectrometry (ICP/MS) analyses showed abnormally high silicon levels in the samples, confirming that the unknown compound(s) contained silicon. DMSD was then synthesized to confirm the identification and provide a standard to develop a calibration curve. Further confirmation was provided by external direct analysis in real time time of flight (DART TOF) mass spectrometry. To routinely test for DMSD in the future, a quantitative method was needed. A preliminary GC/MS method was developed and archived samples from various locations on ISS were analyzed to determine the extent of the contamination and provide data for troubleshooting. This paper describes these events in more detail as well as problems encountered in routine GC/MS analyses and the subsequent development of high performance liquid chromatography and LC/MS/MS methods for measuring DMSD.

Rutz, Jeffrey A.↗
NASA NTRS2011

The Story Behind the Numbers: Lessons Learned from the Integration of Monitoring Resources in Addressing an ISS Water Quality Anomaly

Beginning in June of 2010 an environmental mystery was unfolding on the International Space Station (ISS). The U.S. Water Processor Assembly (WPA) began to produce water with increasing levels of total organic carbon (TOC). A surprisingly consistent upward TOC trend was observed through weekly in-flight total organic carbon analyzer (TOCA) monitoring. As TOC is a general organics indicator, return of water archive samples was needed to make better-informed crew health decisions and to aid in WPA troubleshooting. TOCA-measured TOC was more than halfway to its health-based screening limit before archive samples could be returned on Soyuz 22 and analyzed. Although TOC was confirmed to be elevated, somewhat surprisingly, none of the typical target compounds were the source. After some solid detective work, it was confirmed that the TOC was associated with a compound known as dimethylsilanediol (DMSD). DMSD is believed to be a breakdown product of silicon-containing compounds present on ISS. A toxicological limit was set for DMSD and a forward plan developed for operations given this new understanding of the source of the TOC. This required extensive coordination with ISS stakeholders and innovative use of available in-flight and archive monitoring resources. Behind the numbers and scientific detail surrounding this anomaly, there exists a compelling story of multi-disciplinary awareness, teamwork, and important environmental lessons learned.

McCoy, Torin↗
NASA NTRS2011

Lessons Learned from the Space Shuttle Engine Cutoff System (ECO) Anomalies

The Space Shuttle Orbiter's main engine cutoff (ECO) system first failed ground checkout in April, 2005 during a first tanking test prior to Return-to-Flight. Despite significant troubleshooting and investigative efforts that followed, the root cause could not be found and intermittent anomalies continued to plague the Program. By implementing hardware upgrades, enhancing monitoring capability, and relaxing the launch rules, the Shuttle fleet was allowed to continue flying in spite of these unexplained failures. Root cause was finally determined following the launch attempts of STS-122 in December, 2007 when the anomalies repeated, which allowed drag-on instrumentation to pinpoint the fault (the ET feedthrough connector). The suspect hardware was removed and provided additional evidence towards root cause determination. Corrective action was implemented and the system has performed successfully since then. This white paper presents the lessons learned from the entire experience, beginning with the anomalies since Return-to-Flight through discovery and correction of the problem. To put these lessons in better perspective for the reader, an overview of the ECO system is presented first. Next, a chronological account of the failures and associated investigation activities is discussed. Root cause and corrective action are summarized, followed by the lessons learned.

Martinez, Hugo E.↗
NASA NTRS2004

Stray Light Lessons Learned from the Mars Reconnaissance Orbiter's Optical Navigation Camera

The Optical Navigation Camera (ONC) is a technical demonstration slated to fly on NASA"s Mars Reconnaissance Orbiter in 2005. Conventional navigation methods have reduced accuracy in the days immediately preceding Mars orbit insertion. The resulting uncertainty in spacecraft location limits rover landing sites to relatively safe areas, away from interesting features that may harbor clues to past life on the planet. The ONC will provide accurate navigation on approach for future missions by measuring the locations of the satellites of Mars relative to background stars. Because Mars will be a bright extended object just outside the camera"s field of view, stray light control at small angles is essential. The ONC optomechanical design was analyzed by stray light experts and appropriate baffles were implemented. However, stray light testing revealed significantly higher levels of light than expected at the most critical angles. The primary error source proved to be the interface between ground glass surfaces (and the paint that had been applied to them) and the polished surfaces of the lenses. This paper will describe troubleshooting and correction of the problem, as well as other lessons learned that affected stray light performance.

stray lights↗
NASA NTRS2004

Improving Control of Two Motor Controllers

A computer program controls motors that drive translation stages in a metrology system that consists of a pair of two-axis cathetometers. This program is specific to Compumotor Gemini (or equivalent) motors and the Compumotor 6K-series (or equivalent) motor controller. Relative to the software supplied with the controller, this program affords more capabilities and is easier to use. Written as a Virtual Instrument in the LabVIEW software system, the program presents an imitation control panel that the user can manipulate by use of a keyboard and mouse. There are three modes of operation: command, movement, and joystick. In command mode, single commands are sent to the controller for troubleshooting. In movement mode, distance, speed, and/or acceleration commands are sent to the controller. Position readouts from the motors and from position encoders on the translation stages are displayed in marked fields. At any time, the position readouts can be recorded in a file named by the user. In joystick mode, the program yields control of the motors to a joystick. The program sends commands to, and receives data from, the controller via a serial cable connection, using the serial-communication portion of the software supplied with the controller.

Toland, Ronald W.↗
NASA NTRS2011

Space Environments Testbed

The Space Environments Testbed (SET) is a flight controller data system for the Common Carrier Assembly. The SET-1 flight software provides the command, telemetry, and experiment control to ground operators for the SET-1 mission. Modes of operation (see dia gram) include: a) Boot Mode that is initiated at application of power to the processor card, and runs memory diagnostics. It may be entered via ground command or autonomously based upon fault detection. b) Maintenance Mode that allows for limited carrier health monitoring, including power telemetry monitoring on a non-interference basis. c) Safe Mode is a predefined, minimum power safehold configuration with power to experiments removed and carrier functionality minimized. It is used to troubleshoot problems that occur during flight. d) Operations Mode is used for normal experiment carrier operations. It may be entered only via ground command from Safe Mode.

Leucht, David K.↗
NASA NTRS2006

NASA Crew Launch Vehicle Approach Builds on Lessons from Past and Present Missions

The United States Vision for Space Exploration, announced in January 2004, outlines the National Aeronautics and Space Administration's (NASA) strategic goals and objectives, including retiring the Space Shuttle and replacing it with a new human-rated system suitable for missions to the Moon and Mars. The Crew Exploration Vehicle (CEV) that the new Crew Launch Vehicle (CLV) lofts into space early next decade will initially ferry astronauts to the International Space Station and be capable of carrying crews back to lunar orbit and of supporting missions to Mars orbit. NASA is using its extensive experience gained from past and ongoing launch vehicle programs to maximize the CLV system design approach, with the objective of reducing total lifecycle costs through operational efficiencies. To provide in-depth data for selecting this follow-on launch vehicle, the Exploration Systems Architecture Study was conducted during the summer of 2005, following the confirmation of the new NASA Administrator. A team of aerospace subject matter experts used technical, budget, and schedule objectives to analyze a number of potential launch systems, with a focus on human rating for exploration missions. The results showed that a variant of the Space Shuttle, utilizing the reusable Solid Rocket Booster as the first stage, along with a new upper stage that uses a derivative of the RS-25 Space Shuttle Main Engine to deliver 25 metric tons to low-Earth orbit, was the best choice to reduce the risks associated with fielding a new system in a timely manner. The CLV Project, managed by the Exploration Launch Office located at NASA's Marshall Space Flight Center, is leading the design, development, testing, and operation of this new human-rated system. The CLV Project works closely with the Space Shuttle Program to transition hardware, infrastructure, and workforce assets to the new launch system . leveraging a wealth of lessons learned from Shuttle operations. The CL V is being designed to reduce costs through a number of methods, ranging from validating requirements to conducting trades studies against the concept design. Innovations such as automated processing will build on lessons learned from the Shuttle, other launch systems, Department of Defense operations experience, and subscale flight tests such as the Delta Clipper-Experimental Advanced (DCXA) vehicle operations that utilized minimal touch labor, automated cryogen ic propellant loading , and an 8-hour turnaround for a cryogenic propulsion system. For the CLV, the results of hazard analyses are contributing to an integrated vehicle health monitoring system that will troubleshoot anomalies and determine which ones can be solved without human intervention. Such advances will help streamline the mission operations process for pilots and ground controllers alike. In fiscal year 2005, NASA invested approximately $4.5 billion of its $16 bill ion budget on the Space Shuttle. The ultimate goal of the CLV Project is to deliver a safe, reliable system designed to minimize lifecycle costs so that NASA's budget can be invested in missions of scientific discovery. Lessons learned from developing the CLV will be applied to the growth path for future systems, including a heavy lift launch vehicle.

Dumbacher, Daniel L.↗
NASA NTRS2012

Small Radioisotope Power System at NASA Glenn Research Center

In April 2009, NASA Glenn Research Center (GRC) formed an integrated product team (IPT) to develop a Small Radioisotope Power System (SRPS) utilizing a single Advanced Stirling Convertor (ASC) with passive balancer for possible use by the International Lunar Network (ILN) program. The ILN program is studying the feasibility of implementing a multiple node seismometer network to investigate the internal lunar structure. A single ASC produces approximately 80 W(sub e) and could potentially supply sufficient power for that application. The IPT consists of Sunpower, Inc., to provide the single ASC with balancer, The Johns Hopkins University Applied Physics Laboratory (JHU/APL) to design an engineering model Single Convertor Controller (SCC) for an ASC with balancer, and NASA GRC to provide technical support to these tasks and to develop a simulated lunar lander test stand. A controller maintains stable operation of an ASC. It regulates the alternating current produced by the linear alternator of the convertor, provides a specified output voltage, and maintains operation at a steady piston amplitude and hot end temperature. JHU/APL also designed an ASC dynamic engine/alternator simulator to aid in the testing and troubleshooting of the SCC. This paper describes the requirements, design, and development of the SCC, including some of the key challenges and the solutions chosen to overcome those issues. In addition, it describes the plans to analyze the effectiveness of a passive balancer to minimize vibration from the ASC, characterize the effect of ASC vibration on a lunar lander, characterize the performance of the SCC, and integrate the single ASC, SCC, and lunar lander test stand to characterize performance of the overall system.

Dugala, Gina M.↗
NASA NTRS2012

Flow Analysis Tool White Paper

Faster networks are continually being built to accommodate larger data transfers. While it is intuitive to think that implementing faster networks will result in higher throughput rates, this is often not the case. There are many elements involved in data transfer, many of which are beyond the scope of the network itself. Although networks may get bigger and support faster technologies, the presence of other legacy components, such as older application software or kernel parameters, can often cause bottlenecks. Engineers must be able to identify when data flows are reaching a bottleneck that is not imposed by the network and then troubleshoot it using the tools available to them. The current best practice is to collect as much information as possible on the network traffic flows so that analysis is quick and easy. Unfortunately, no single method of collecting this information can sufficiently capture the whole endto- end picture. This becomes even more of a hurdle when large, multi-user systems are involved. In order to capture all the necessary information, multiple data sources are required. This paper presents a method for developing a flow analysis tool to effectively collect network flow data from multiple sources and provide that information to engineers in a clear, concise way for analysis. The purpose of this method is to collect enough information to quickly (and automatically) identify poorly performing flows along with the cause of the problem. The method involves the development of a set of database tables that can be populated with flow data from multiple sources, along with an easyto- use, web-based front-end interface to help network engineers access, organize, analyze, and manage all the information.

Boscia, Nichole K.↗
NASA NTRS2012

Failure Analysis of T-38 Aircraft Burst Hydraulic Aileron Return Line

During maintenance troubleshooting for fluctuating hydraulic pressures, a technician found that a right hand aileron return line, on the flight hydraulic side, was ruptured (Fig. 1, 2). This tubing is part of the Hydraulic Flight Control Aileron Return Reducer to Aileron Manifold and is suspected to be original to the T-38 Talon trainer aircraft. Ailerons are small hinged sections on the outboard portion of a wing used to generate rolling motion thereby banking the aircraft. The ailerons work by changing the effective shape of the airfoil of the outer portion of the wing [1]. The drawing, Northrop P/N 3-43033-55 (6/1960), specifies that the line is made from 0.375 inch OD, aluminum 5052-0 tubing with a 0.049 inch wall thickness. WW-T-787 requires the tube shall be seamless and uniform in quality and temper [2]. The test pressure for this line is 3000 psi, and the operational pressure for this line is estimated to be between 45 psi and 1500 psi based on dynamic loading during flight. Examination of the fracture surface found evidence of arrest bands originating on the inner diameter (Fig 3). Ductile dimples are observed on the tube fractures (Fig. 4). The etched cross-section revealed thinning and work-hardening in the burst region (Fig. 5). The wall thickness just outside the work-hardened fracture region measured 0.035". Barlow's Formula: P = 2St/D, where P is burst pressure, S is allowable stress, t is wall thickness and D is the outer diameter of tube. Using the ultimate tensile strength of 28 ksi and a measured wall thickness of 0.035 inches at burst, P = 5.2 ksi (burst pressure). Using the yield of 13 ksi (YS) for aluminum 5052-0, plastic deformation will happen at P = 2.4 ksi suggesting plastic deformation occurred at a proof pressure of 3.0 ksi. Conclusion: The burst resulted from high stress, low-cycle fatigue. Evidence of arrest bands originating on the inner diameter. Fracture is predominately shear dimples, characteristic of high load ductile fractures (Fig 6). Section wall reduction in the burst region. Plastic deformation and thinning of the out-of-specification tube wall likely happened during the initial proof testing years ago. Metallography of tubing away from rupture site confirmed tubing was seamless. Based on the tube microstructure, it is likely that the initial wall thickness was about 30 % thinner than the requirement of 0.049 inches. Fracture initiated on the ID and progressed to the OD (shear lip). The tube is made of the correct material of 5052-0 aluminum as verified using Optical Emission Spectroscopy (Table 2). The tubing hardness tested 77 HV100 (77 HRE). This hardness is slightly above the requirement for 70 HRE maximum for aluminum 5052-0 in AMS 2658C [3].

Martinez, J. E.↗
NASA NTRS2013

Shuttle Repair Tools Automate Vehicle Maintenance

Successfully building, flying, and maintaining the space shuttles was an immensely complex job that required a high level of detailed, precise engineering. After each shuttle landed, it entered a maintenance, repair, and overhaul (MRO) phase. Each system was thoroughly checked and tested, and worn or damaged parts replaced, before the shuttle was rolled out for its next mission. During the MRO period, workers needed to record exactly what needed replacing and why, as well as follow precise guidelines and procedures in making their repairs. That meant traceability, and with it lots of paperwork. In 2007, the number of reports generated during electrical system repairs was getting out of hand-placing among the top three systems in terms of paperwork volume. Repair specialists at Kennedy Space Center were unhappy spending so much time at a desk and so little time actually working on the shuttle. "Engineers weren't spending their time doing technical work," says Joseph Schuh, an electrical engineer at Kennedy. "Instead, they were busy with repetitive, time-consuming processes that, while important in their own right, provided a low return on time invested." The strain of such inefficiency was bad enough that slow electrical repairs jeopardized rollout on several occasions. Knowing there had to be a way to streamline operations, Kennedy asked Martin Belson, a project manager with 30 years experience as an aerospace contractor, to co-lead a team in developing software that would reduce the effort required to document shuttle repairs. The result was System Maintenance Automated Repair Tasks (SMART) software. SMART is a tool for aggregating and applying information on every aspect of repairs, from procedures and instructions to a vehicle s troubleshooting history. Drawing on that data, SMART largely automates the processes of generating repair instructions and post-repair paperwork. In the case of the space shuttle, this meant that SMART had 30 years worth of operations that it could apply to ongoing maintenance work. According to Schuh, "SMART standardized and streamlined many shuttle repair processes, saving time and money while increasing safety and the quality of repairs." Maintenance technicians and engineers now had a tool that kept them in the field, and because SMART is capable of continually evolving, each time an engineer put it to use, it would enrich the Agency-wide knowledge base. "If an engineer sees something in the work environment that they could improve, a repair process or a procedure, SMART can incorporate that data for use in future operations," says Belson.

Source record↗
NASA NTRS2014

Cameras Monitor Spacecraft Integrity to Prevent Failures

The Jet Propulsion Laboratory contracted Malin Space Science Systems Inc. to outfit Curiosity with four of its cameras using the latest commercial imaging technology. The company parlayed the knowledge gained under working with NASA to develop an off-the-shelf line of cameras, along with a digital video recorder, designed to help troubleshoot problems that may arise on satellites in space.

Source record↗
NASA NTRS2014

Use of Semi-Autonomous Tools for ISS Commanding and Monitoring

As the International Space Station (ISS) has moved into a utilization phase, operations have shifted to become more ground-based with fewer mission control personnel monitoring and commanding multiple ISS systems. This shift to fewer people monitoring more systems has prompted use of semi-autonomous console tools in the ISS Mission Control Center (MCC) to help flight controllers command and monitor the ISS. These console tools perform routine operational procedures while keeping the human operator "in the loop" to monitor and intervene when off-nominal events arise. Two such tools, the Pre-positioned Load (PPL) Loader and Automatic Operators Recorder Manager (AutoORM), are used by the ISS Communications RF Onboard Networks Utilization Specialist (CRONUS) flight control position. CRONUS is responsible for simultaneously commanding and monitoring the ISS Command & Data Handling (C&DH) and Communications and Tracking (C&T) systems. PPL Loader is used to uplink small pieces of frequently changed software data tables, called PPLs, to ISS computers to support different ISS operations. In order to uplink a PPL, a data load command must be built that contains multiple user-input fields. Next, a multiple step commanding and verification procedure must be performed to enable an onboard computer for software uplink, uplink the PPL, verify the PPL has incorporated correctly, and disable the computer for software uplink. PPL Loader provides different levels of automation in both building and uplinking these commands. In its manual mode, PPL Loader automatically builds the PPL data load commands but allows the flight controller to verify and save the commands for future uplink. In its auto mode, PPL Loader automatically builds the PPL data load commands for flight controller verification, but automatically performs the PPL uplink procedure by sending commands and performing verification checks while notifying CRONUS of procedure step completion. If an off-nominal condition occurs during procedure execution, PPL Loader notifies CRONUS through popup messages, allowing CRONUS to examine the situation and choose an option of how PPL loader should proceed with the procedure. The use of PPL Loader to perform frequent, routine PPL uplinks offloads CRONUS to better monitor two ISS systems. It also reduces procedure performance time and decreases risk of command errors. AutoORM identifies ISS communication outage periods and builds commands to lock, playback, and unlock ISS Operations Recorder files. Operation Recorder files are circular buffer files of continually recorded ISS telemetry data. Sections of these files can be locked from further writing, be played back to capture telemetry data that occurred during an ISS loss of signal (LOS) period, and then be unlocked for future recording use. Downlinked Operation Recorder files are used by mission support teams for data analysis, especially if failures occur during LOS. The commands to lock, playback, and unlock Operations Recorder files are encompassed in three different operational procedures and contain multiple user-input fields. AutoORM provides different levels of automation for building and uplinking the commands to lock, playback, and unlock Operations Recorder files. In its automatic mode, AutoORM automatically detects ISS LOS periods, then generates and uplinks the commands to lock, playback, and unlock Operations Recorder files when MCC regains signal with ISS. AutoORM also features semi-autonomous and manual modes which integrate CRONUS more into the command verification and uplink process. AutoORMs ability to automatically detect ISS LOS periods and build the necessary commands to preserve, playback, and release recorded telemetry data greatly offloads CRONUS to perform more high-level cognitive tasks, such as mission planning and anomaly troubleshooting. Additionally, since Operations Recorder commands contain numerical time input fields which are tedious for a human to manually build, AutoORM's ability to automatically build commands reduces operational command errors. PPL Loader and AutoORM demonstrate principles of semi-autonomous operational tools that will benefit future space mission operations. Both tools employ different levels of automation to perform simple and routine procedures, thereby offloading human operators to perform higher-level cognitive tasks. Because both tools provide procedure execution status and highlight off-nominal indications, the flight controller is able to intervene during procedure execution if needed. Semi-autonomous tools and systems that can perform routine procedures, yet keep human operators informed of execution, will be essential in future long-duration missions where the onboard crew will be solely responsible for spacecraft monitoring and control.

Brzezinski, Amy S.↗
NASA NTRS2013

Spitzer Telemetry Processing System

The Spitzer Telemetry Processing System (SirtfTlmProc) was designed to address objectives of JPL's Multi-mission Image Processing Lab (MIPL) in processing spacecraft telemetry and distributing the resulting data to the science community. To minimize costs and maximize operability, the software design focused on automated error recovery, performance, and information management. The system processes telemetry from the Spitzer spacecraft and delivers Level 0 products to the Spitzer Science Center. SirtfTlmProc is a unique system with automated error notification and recovery, with a real-time continuous service that can go quiescent after periods of inactivity. The software can process 2 GB of telemetry and deliver Level 0 science products to the end user in four hours. It provides analysis tools so the operator can manage the system and troubleshoot problems. It automates telemetry processing in order to reduce staffing costs.

Stanboli, Alice↗