SEARCH · Engineering Papers

Results for “troubleshooting procedures”

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.

SourceResearch connectionFrom yearThrough year

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

At least 37 records · Page 2

All sources NASA NTRS DOE OSTI

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 NTRS1988

An intelligent tutoring system for space shuttle diagnosis

An Intelligent Tutoring System (ITS) transcends conventional computer-based instruction. An ITS is capable of monitoring and understanding student performance thereby providing feedback, explanation, and remediation. This is accomplished by including models of the student, the instructor, and the expert technician or operator in the domain of interest. The space shuttle fuel cell is the technical domain for the project described below. One system, Microcomputer Intelligence for Technical Training (MITT), demonstrates that ITS's can be developed and delivered, with a reasonable amount of effort and in a short period of time, on a microcomputer. The MITT system capitalizes on the diagnostic training approach called Framework for Aiding the Understanding of Logical Troubleshooting (FAULT) (Johnson, 1987). The system's embedded procedural expert was developed with NASA's C-Language Integrated Production (CLIP) expert system shell (Cubert, 1987).

Johnson, William B.↗

NASA NTRS2003

STS-107 Mission Highlights Resource, Part 4 of 4

This video, Part 4 of 4, shows the activities of the STS-107 crew during flight days 13 through 15 of the Columbia orbiter's final flight. The crew consists of Commander Rick Husband, Pilot William McCool, Payload Commander Michael Anderson, Mission Specialists David Brown, Kalpana Chawla, and Laurel Clark, and Payload Specialist Ilan Ramon. The highlight of flight day 13 is Kalpana Chawla conversing with Mission Control Center in Houston during troubleshooting of the Combustion Module in a recovery procedure to get the MIST fire suppression experiment back online. Chawla is shown replacing an atomizer head. At Mission Control Center a vase of flowers commemorating the astronauts who died on board Space Shuttle Challenger's final flight is shown and explained. The footage of flight day 14 consists of a tour of Columbia's flight deck, middeck, and Spacehab research module. Rick Husband narrates the tour, which features Kalpana Chawla, Laurel Clark, and himself. The astronauts demonstrate hygene, a dining tray, the orbiter's toilet, and a space iron, which is a rack for strapping down shirts. The Earth limb is shown with the Spacehab module in the foreground. Clark exercises on a bicycle for a respiration experiment, and demonstrates how a compact disk player gyrates in microgravity. On flight day 15, the combustion module is running again, and footage is shown of the Water Mist Fire-Suppression Experiment (Mist) in operation. Laurel Clark narrates a segment of the video in which Ilan Ramon exercises on a bicycle, Rick Husband, Kalpana Chawla, and Ramon demonstrate spinning and push-ups in the Spacehab module, and Clark demonstrates eating from a couple of food packets. The video ends with a shot of the Earth limb reflected on the radiator on the inside of Columbia's open payload bay door with the Earth in the background.

Source record↗

NASA NTRS2011

PCB-Based Break-Out Box

Break-out boxes (BOBs) are necessary for all electrical integration/cable checkouts and troubleshooting. Because the price of a BOB is high, and no work can be done without one, often the procedure stops, simply waiting for a BOB. A less expensive BOB would take less time in the integration, testing, and troubleshooting process. The PCB-based BOB works and looks the same as a standard JPL BOB, called Gold Boxes. The only differences between the old BOB and the new PCB-based BOB is that the new one has 80 percent of its circuitry in a printed circuit board. This process reduces the time for fabrication, thus making the BOBs less expensive. Moreover, because of its unique design, the new BOBs can be easily assembled and fixed. About 80 percent of the new PCB-based BOB is in a $22 (at the time of this reporting) custom-designed, yet commercially available PCB. This device has been used successfully to verify that BOB cables were properly made. Also, upon completion, the BOB was beeped out via a multimeter to ensure that all sockets on the connectors were properly connected to the respective banana jack. When compared to the Gold Box BOBs, the new BOB has many advantages. It is much more cost efficient, it delivers equal usability at substantially lower cost of the BOB, and the Gold Box is much heavier when compared to the new BOB. The new BOB is also a bit longer and much more versatile in that connectors are easily changeable and if a banana jack is broken, it can be replaced instead of throwing away an entire BOB.

Lee, Jason H.↗

NASA NTRSDate not supplied

Lessons Learned from Astrobee Operations on the International Space Station

Since its launch in 2019, NASA has been operating three Astrobee free-flying robots providing an autonomous and adaptable research platform aboard the International Space Station (ISS). These robots have not only facilitated a myriad of national and international research endeavors in microgravity but have also served as a STEM outreach platform for student competitions aboard the ISS. Amidst its extensive operational tenure, spanning over five years and exceeding 1200 hours of cumulative free-flyer operation as of April 2024, the Astrobee robots have encountered software and hardware anomalies. Despite its inherent design for on-orbit repair or replacement, certain anomalies have proven to be complex, necessitating remote resolution via software and firmware updates or, in extreme cases, hardware replacements or the return of faulty units to NASA's ground facilities for repair. Such challenges underscore the delicate balance between the autonomous functionality of Astrobee and the occasional need for human intervention to maintain optimal performance. One recurring point of failure identified during Astrobee's operational lifespan has been the SD card, a critical component utilized by the different Astrobee processors and the Dock Station. The occurrence of SD card anomalies, both on orbit and within ground units, has provided invaluable insights into the improvement of Astrobee's systems and mitigation to future faults. This presentation will focus on four key areas: 1. Overview of Faults and Anomalies: A comprehensive examination of the diverse array of faults and anomalies encountered by Astrobee and its associated systems both in orbit and on the ground. From software glitches to hardware malfunctions, this section provides insights into the challenges faced during Astrobee's operational tenure. 2. Resolution Processes and Procedures: An in-depth discussion of the methodologies and procedures implemented to resolve the encountered anomalies. This includes remote troubleshooting, software patches, firmware updates, and, when necessary, the logistics involved in hardware replacements or down-massing for repair. 3. Implementation of Software Updates and Hardware Upgrades: A detailed exploration of the strategies employed to mitigate the risk of recurring anomalies through the implementation of software updates and hardware upgrades. This section highlights the iterative nature of Astrobee's development, emphasizing the continuous pursuit of robustness and reliability. 4. Lessons Learned and Future Directions: Reflecting on the insights gained from addressing anomalies, this section examines the lessons learned and outlines future directions for enhancing Astrobee's robustness and resilience. It underscores the iterative nature of space exploration and the importance of adaptability and continuous improvement in the pursuit of scientific discovery. Through a nuanced examination of Astrobee's operational challenges and the strategies employed to overcome them, this presentation sheds light on the complexities of operating autonomous robotic systems in the ISS environment. It underscores NASA's commitment to pushing the boundaries of exploration and innovation while navigating the inherent challenges of space exploration.

Astrobee↗

NASA NTRSDate not supplied

Lessons Learned from Astrobee Operations on the International Space Station

Astrobee↗

NASA NTRS2004

Agent Architecture for Aviation Data Integration System

This paper describes the proposed agent-based architecture of the Aviation Data Integration System (ADIS). ADIS is a software system that provides integrated heterogeneous data to support aviation problem-solving activities. Examples of aviation problem-solving activities include engineering troubleshooting, incident and accident investigation, routine flight operations monitoring, safety assessment, maintenance procedure debugging, and training assessment. A wide variety of information is typically referenced when engaging in these activities. Some of this information includes flight recorder data, Automatic Terminal Information Service (ATIS) reports, Jeppesen charts, weather data, air traffic control information, safety reports, and runway visual range data. Such wide-ranging information cannot be found in any single unified information source. Therefore, this information must be actively collected, assembled, and presented in a manner that supports the users problem-solving activities. This information integration task is non-trivial and presents a variety of technical challenges. ADIS has been developed to do this task and it permits integration of weather, RVR, radar data, and Jeppesen charts with flight data. ADIS has been implemented and used by several airlines FOQA teams. The initial feedback from airlines is that such a system is very useful in FOQA analysis. Based on the feedback from the initial deployment, we are developing a new version of the system that would make further progress in achieving following goals of our project.

Kulkarni, Deepak↗

NASA NTRS1981

Operation and maintenance manual for a preprototype Sabatier carbon dioxide reduction subsystem

The manual delineates the procedures, precautions and necessary sequences of steps required to prepare the package for test, provide troubleshooting information and perform required maintenance by the operating crew. The manual is divided into five sections: Installation, Checkout, Operation, Failure Detection/Isolation and Maintenance.

Kleiner, G. N.↗

NASA NTRS1980

Installation, operation, and maintenance for the pyramidal optics solar system installed at Yacht Cover, Columbia, South Carolina

Information concerning the installation, operation, and maintenance of the pyramidal Solar System for space heating and domestic hot water is presented. Principles of operation, sequence of installation, and procedures for the operation and maintenance of each subsystem making up the solar system are presented. Troubleshooting charts and maintenance schedules are presented.

Source record↗

NASA NTRS1993

Advanced Technology Training System on Motor-Operated Valves

This paper describes how features from the field of Intelligent Tutoring Systems are applied to the Motor-Operated Valve (MOV) Advanced Technology Training System (ATTS). The MOV ATTS is a training system developed at Galaxy Scientific Corporation for the Central Research Institute of Electric Power Industry in Japan and the Electric Power Research Institute in the United States. The MOV ATTS combines traditional computer-based training approaches with system simulation, integrated expert systems, and student and expert modeling. The primary goal of the MOV ATTS is to reduce human errors that occur during MOV overhaul and repair. The MOV ATTS addresses this goal by providing basic operational information of the MOV, simulating MOV operation, providing troubleshooting practice of MOV failures, and tailoring this training to the needs of each individual student. The MOV ATTS integrates multiple expert models (functional and procedural) to provide advice and feedback to students. The integration also provides expert model validation support to developers. Student modeling is supported by two separate student models: one model registers and updates the student's current knowledge of basic MOV information, while another model logs the student's actions and errors during troubleshooting exercises. These two models are used to provide tailored feedback to the student during the MOV course.

Wiederholt, Bradley J.↗

NASA NTRS1990

Success in tutoring electronic troubleshooting

Two years ago Dr. Sherrie Gott of the Air Force Human Resources Laboratory described an avionics troubleshooting tutor being developed under the Basic Job Skills Research Program. The tutor, known as Sherlock, is directed at teaching the diagnostic procedures necessary to investigate complex test equipment used to maintain F-15 fighter aircraft. Since Dr. Gott's presentation in 1987, the tutor has undergone field testing at two Air Force F-15 flying wings. The results of the field test showed that after an average of 20 hours on the tutor, the 16 airmen in the experimental group (who average 28 months of experience) showed significant performance gains when compared to a control group (having a mean experience level of 37 months) who continued participating in the existing on-the-job training program. Troubleshooting performance of the tutored group approached the level of proficiency of highly experienced airmen (averaging approximately 114 months of experience), and these performance gains were confirmed in delayed testing six months following the intervention. The tutor is currently undergoing a hardware and software conversion form a Xerox Lisp environment to a PC-based environment using an object-oriented programming language. Summarized here are the results of the successful field test. The focus is on: (1) the instructional features that contributed to Sherlock's success; and (2) the implementation of these features in the PC-based version of the avionics troubleshooting tutor.

Parker, Ellen M.↗

NASA NTRSDate not supplied

Lessons for Future In-Space Telerobotic Servicing from Robotic Refueling Mission

The Robotic Refueling Mission (RRM) was a multi-phased technology development effort by the National Aeronautics & Space Administration (NASA) and the Canadian Space Agency (CSA). The program leveraged the existing robotic systems and expertise of the International Space Station (ISS) program and the tool design and satellite servicing expertise of NASA’s Exploration & In-space Services (NExIS) Projects Division at Goddard Space Flight Center (GSFC) to evaluate new hardware and techniques for on-orbit telerobotic servicing. Between 2011 and 2021, two external ISS payloads housed over a dozen robotic tools and adapters designed to service a variety of existing and novel satellite interfaces. Robot operators at NASA’s Johnson Space Center (JSC) and CSA used the Special Purpose Dexterous Manipulator (SPDM) to retrieve and operate these tools for tasks such as cutting wires or multi-layer insulation blanketing, removing valve caps, mating electrical connectors, transferring fluids, and performing visual inspections inside a vehicle. Each phase of RRM involved years of preparation. Tool and interface designs were prototyped and evaluated using both NASA and Canadian ground robotic systems. Procedures were developed by GSFC engineers and vetted in partnership with JSC and CSA robot operators. GSFC engineers were trained to provide real-time support during on-orbit operations. These preparatory efforts and the successful on-orbit evaluations yielded an array of lessons for future in-space telerobotic missions. Designing robotic tools for the space environment requires special consideration of materials, indicators, and differences between ground and flight use cases and environments. When there is a limited window for on-orbit operations, devoting time and high-fidelity hardware to ground testing can be critical. Needs during potential troubleshooting are more essential to camera view quality, frame rate, and position requirements more than nominal operations. Detailed hardware manuals, nominal and contingency procedures, along with clearly defined operations team roles and protocols are vital for efficiency. RRM also demonstrated how the ISS can be utilized to increase the technology readiness levels required for future missions and led to additional technology partnerships between NExIS and the ISS program. The lessons from RRM are currently being applied to designs, operations concepts, and ground test methodology for missions such as On-orbit Servicing, Assembly, and Manufacturing1(OSAM-1)and Mars Sample Return.

Zakiya Tomlinson↗

NASA NTRS1992

Intelligent diagnostics systems

Intelligent systems have been applied to today's problems and could also be applied to space operations integrity. One of these systems is the XMAN tool designed for 'troubleshooting' jet engines. XMAN is the eXpert MAiNtenance tool developed to be an expert information analysis tool which stores trending and diagnostic data on Air Force engines. XMAN operates with a 'network topology' which follows a flow chart containing engine management information reports required by the governments technical order procedures. With XMAN technology, the user is able to identify engine problems by presenting the assertions of the fault isolation logic and attempting to satisfy individual assertions by referring to the databases created by an engine monitoring system. The troubleshooting process requires interaction between the technician and the computer to acquire new evidence form auxiliary maintenance tests corroboration of analytical results to accurately diagnose equipment malfunctions. This same technology will be required for systems which are functioning in space either with an onboard crew, or with an unmanned system. The technology and lessons learned developing this technology while suggesting definite applications for its use with developing space systems are addressed.

Mcquiston, Barbara M.↗

NASA NTRS2001

B and F Signal Conditioner Checkout Unit

ATK Thiokol Propulsion, Test Services uses B&F Signal Conditioning units to provide excitation power and shunt calibration information to the data recording systems. Gage measurements such as force, temperature, pressure, strain, etc. are recorded using this equipment. Approximately 2500 reusable instrumentation B&F Signal Conditioning units were purchased over an interval from 1978 to 1988 at a cost of around $1000 each. Through use and over time, the relay contacts on the signal conditioning mode cards have become corroded, resulting in excessive contact resistance. This causes inaccurate and inconsistent calibration data and could jeopardize the test results. These signal conditioning cards are needed for product testing for an estimated five more years, therefore, it is necessary to develop a solution to isolate the malfunctioning units for repair. The current screening method requires Test Area technicians to check cards manually, however the connections and measurements required for this process are inefficient and time consuming. To resolve this problem, funding was approved to design and build two B&F Signal Conditioner Checkout Units. Each unit will allow technicians to test relay contact resistance on signal conditioning mode cards before they are installed for data collection procedures. This tool will allow Test Area to resolve calibration accuracy problems and extend the life of the data acquisition equipment, as well as save troubleshooting time for the technicians.

Magleby, Alyssa↗

NASA NTRS1994

The Buffer Diagnostic Prototype: A fault isolation application using CLIPS

This paper describes problem domain characteristics and development experiences from using CLIPS 6.0 in a proof-of-concept troubleshooting application called the Buffer Diagnostic Prototype. The problem domain is a large digital communications subsystems called the real-time network (RTN), which was designed to upgrade the launch processing system used for shuttle support at KSC. The RTN enables up to 255 computers to share 50,000 data points with millisecond response times. The RTN's extensive built-in test capability but lack of any automatic fault isolation capability presents a unique opportunity for a diagnostic expert system application. The Buffer Diagnostic Prototype addresses RTN diagnosis with a multiple strategy approach. A novel technique called 'faulty causality' employs inexact qualitative models to process test results. Experimental knowledge provides a capability to recognize symptom-fault associations. The implementation utilizes rule-based and procedural programming techniques, including a goal-directed control structure and simple text-based generic user interface that may be reusable for other rapid prototyping applications. Although limited in scope, this project demonstrates a diagnostic approach that may be adapted to troubleshoot a broad range of equipment.

Porter, Ken↗

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 NTRS1974

Repair of major system elements on Skylab

In-flight maintenance, as conceived and preplanned for the Skylab mission was limited to simple scheduled and unscheduled replacement tasks and minor contingency repairs. Tools and spares were provided accordingly. However, failures during the mission dictated complicated and sophisticated repairs to major systems so that the mission could continue. These repairs included the release of a large structure that failed to deploy, the assembly and deployment of large mechanical devices, the installation and checkout of precision electronic equipment, troubleshooting and repair of precision electromechanical equipment, and tapping into and recharging a cooling system. The repairs were conducted both inside the spacecraft and during extravehicular activities. Some of the repair tasks required team effort on the part of the crewmen including close procedural coordination between internal and extravehicular crewmen. The Skylab experience indicates that crewmen can, with adequate training, make major system repairs in space using standard or special tools. Design of future spacecraft systems should acknowledge this capability and provide for more extensive in-flight repair and maintenance.

Pace, R. E., Jr.↗

NASA NTRS2009

Service Management Database for DSN Equipment

This data- and event-driven persistent storage system leverages the use of commercial software provided by Oracle for portability, ease of maintenance, scalability, and ease of integration with embedded, client-server, and multi-tiered applications. In this role, the Service Management Database (SMDB) is a key component of the overall end-to-end process involved in the scheduling, preparation, and configuration of the Deep Space Network (DSN) equipment needed to perform the various telecommunication services the DSN provides to its customers worldwide. SMDB makes efficient use of triggers, stored procedures, queuing functions, e-mail capabilities, data management, and Java integration features provided by the Oracle relational database management system. SMDB uses a third normal form schema design that allows for simple data maintenance procedures and thin layers of integration with client applications. The software provides an integrated event logging system with ability to publish events to a JMS messaging system for synchronous and asynchronous delivery to subscribed applications. It provides a structured classification of events and application-level messages stored in database tables that are accessible by monitoring applications for real-time monitoring or for troubleshooting and analysis over historical archives.

Zendejas, Silvino↗