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 37 records · Page 2

MACH 3: Past and future approaches to intelligent tutoring

In 1986, the U.S. Army Research Institute created an intelligent tutoring system as a proof-of-concept for artificial intelligence applications in Army training. The Maintenance Aid Computer HAWK Intelligent Institutional Instructor (MACH 3) taught student mechanics to maintain and troubleshoot the AN/MPQ-57 High Power Illuminator Radar (HPIR) of the HAWK Air Defense Missile System. In 1989, TRADOC Analysis Command compared the effectiveness of MACH 3 to traditional paper-based troubleshooting drills. For the study, all students received lecture and hands-on training as usual. However, during troubleshooting drills, students traced faults using either MACH 3 or the traditional paper-based method. Class records showed that the MACH 3 group completed significantly more troubleshooting tasks and progressed through tasks of greater difficulty than the paper-based group. Upon completion of training, students took written, practical, and oral essay tests. Mean test scores showed that students performed similarly regardless of the drill method used. However, significantly different standard deviations showed that the MACH 3 group performed more consistently than the paper-based group. Furthermore, significantly different time measures showed that the MACH 3 group reached faster troubleshooting solutions on the actual radar transmitter than the paper-based group. We will present the study results and discuss how updating the design of the MACH 3 can include desktop computing in a virtual environment.

Acchione-Noel, Sylvia↗

REDEX: The ranging equipment diagnostic expert system

REDEX, an advanced prototype expert system that diagnoses hardware failures in the Ranging Equipment (RE) at NASA's Ground Network tracking stations is described. REDEX will help the RE technician identify faulty circuit cards or modules that must be replaced, and thereby reduce troubleshooting time. It features a highly graphical user interface that uses color block diagrams and layout diagrams to illustrate the location of a fault. A semantic network knowledge representation technique was used to model the design structure of the RE. A catalog of generic troubleshooting rules was compiled to represent heuristics that are applied in diagnosing electronic equipment. Specific troubleshooting rules were identified to represent additional diagnostic knowledge that is unique to the RE. Over 50 generic and 250 specific troubleshooting rules have been derived. REDEX is implemented in Prolog on an IBM PC AT-compatible workstation. Block diagram graphics displays are color-coded to identify signals that have been monitored or inferred to have nominal values, signals that are out of tolerance, and circuit cards and functions that are diagnosed as faulty. A hypertext-like scheme is used to allow the user to easily navigate through the space of diagrams and tables. Over 50 graphic and tabular displays have been implemented. REDEX is currently being evaluated in a stand-alone mode using simulated RE fault scenarios. It will soon be interfaced to the RE and tested in an online environment. When completed and fielded, REDEX will be a concrete example of the application of expert systems technology to the problem of improving performance and reducing the lifecycle costs of operating NASA's communications networks in the 1990's.

Luczak, Edward C.↗

REDEX - The ranging equipment diagnostic expert system

REDEX, an advanced prototype expert system that diagnoses hardware failures in the Ranging Equipment (RE) at NASA's Ground Network tracking stations is described. REDEX will help the RE technician identify faulty circuit cards or modules that must be replaced, and thereby reduce troubleshooting time. It features a highly graphical user interface that uses color block diagrams and layout diagrams to illustrate the location of a fault. A semantic network knowledge representation technique was used to model the design structure of the RE. A catalog of generic troubleshooting rules was compiled to represent heuristics that are applied in diagnosing electronic equipment. Specific troubleshooting rules were identified to represent additional diagnostic knowledge that is unique to the RE. Over 50 generic and 250 specific troubleshooting rules have been derived. REDEX is implemented in Prolog on an IBM PC AT-compatible workstation. Block diagram graphics displays are color-coded to identify signals that have been monitored or inferred to have nominal values, signals that are out of tolerance, and circuit cards and functions that are diagnosed as faulty. A hypertext-like scheme is used to allow the user to easily navigate through the space of diagrams and tables. Over 50 graphic and tabular displays have been implemented. REDEX is currently being evaluated in a stand-alone mode using simulated RE fault scenarios. It will soon be interfaced to the RE and tested in an online environment. When completed and fielded, REDEX will be a concrete example of the application of expert systems technology to the problem of improving performance and reducing the lifecycle costs of operating NASA's communications networks in the 1990s.

Luczak, Edward C.↗

Knowledge based jet engine diagnostics

A fielded expert system automates equipment fault isolation and recommends corrective maintenance action for Air Force jet engines. The knowledge based diagnostics tool was developed as an expert system interface to the Comprehensive Engine Management System, Increment IV (CEMS IV), the standard Air Force base level maintenance decision support system. XMAM (trademark), the Expert Maintenance Tool, automates procedures for troubleshooting equipment faults, provides a facility for interactive user training, and fits within a diagnostics information feedback loop to improve the troubleshooting and equipment maintenance processes. The application of expert diagnostics to the Air Force A-10A aircraft TF-34 engine equipped with the Turbine Engine Monitoring System (TEMS) is presented.

Jellison, Timothy G.↗

MITT writer and MITT writer advanced development: Developing authoring and training systems for complex technical domains

MITT Writer is a software system for developing computer based training for complex technical domains. A training system produced by MITT Writer allows a student to learn and practice troubleshooting and diagnostic skills. The MITT (Microcomputer Intelligence for Technical Training) architecture is a reasonable approach to simulation based diagnostic training. MITT delivers training on available computing equipment, delivers challenging training and simulation scenarios, and has economical development and maintenance costs. A 15 month effort was undertaken in which the MITT Writer system was developed. A workshop was also conducted to train instructors in how to use MITT Writer. Earlier versions were used to develop an Intelligent Tutoring System for troubleshooting the Minuteman Missile Message Processing System.

Wiederholt, Bradley J.↗

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.↗

Unit Monitors Manchester-Format Data Buses

Circuit card converts data signals into convenient hexadecimal form for troubleshooting. Bus-monitoring unit converts data signals from Manchester II format used on data bus into hexadecimal format. Monitoring circuit causes hexadecimal words to display on video terminal, where test engineer compares them with hexadecimal records for troubleshooting. Circuit monitors one bus or two buses simultaneously.

Amador, Jose J.↗

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↗

Using CLIPS in a distributed system: The Network Control Center (NCC) expert system

This paper describes an intelligent troubleshooting system for the Help Desk domain. It was developed on an IBM-compatible 80286 PC using Microsoft C and CLIPS and an AT&T 3B2 minicomputer using the UNIFY database and a combination of shell script, C programs and SQL queries. The two computers are linked by a lan. The functions of this system are to help non-technical NCC personnel handle trouble calls, to keep a log of problem calls with complete, concise information, and to keep a historical database of problems. The database helps identify hardware and software problem areas and provides a source of new rules for the troubleshooting knowledge base.

Wannemacher, Tom↗

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.↗

Principal Investigator-in-a-Box

Human performance in orbit is currently limited by several factors beyond the intrinsic awkwardness of motor control in weightlessness. Cognitive functioning can be affected by such factors as cumulative sleep loss, stress and the psychological effects of long-duration small-group isolation. When an astronaut operates a scientific experiment, the performance decrement associated with such factors can lead to lost or poor quality data and even the total loss of a scientific objective, at great cost to the sponsors and to the dismay of the Principal Investigator. In long-duration flights, as anticipated on the International Space Station and on any planetary exploration, the experimental model is further complicated by long delays between training and experiment, and the large number of experiments each crew member must perform. Although no documented studies have been published on the subject, astronauts report that an unusually large number of simple errors are made in space. Whether a result of the effects of microgravity, accumulated fatigue, stress or other factors, this pattern of increased error supports the need for a computerized decision-making aid for astronauts performing experiments. Artificial intelligence and expert systems might serve as powerful tools for assisting experiments in space. Those conducting space experiments typically need assistance exactly when the planned checklist does not apply. Expert systems, which use bits of human knowledge and human methods to respond appropriately to unusual situations, have a flexibility that is highly desirable in circumstances where an invariably predictable course of action/response does not exist. Frequently the human expert on the ground is unavailable, lacking the latest information, or not consulted by the astronaut conducting the experiment. In response to these issues, we have developed "Principal Investigator-in-a-Box," or [PI], to capture the reasoning process of the real expert, the Principal Investigator, and combine that with real-time data available in space in order to advise the astronaut about how to proceed in real time. [PI] advises the astronaut during the progress of an experiment in much the same way a real Principal Investigator might do while looking over the astronaut's shoulder. In its original application, [PI] mimicked several of the tasks of the Principal Investigator, including data quality monitoring, troubleshooting, prescheduling, protocol management and "interesting data" detection. The proposed research focuses on the efficacy of this technique as applied to the data quality monitoring and troubleshooting aspects of [PI].

Young, Laurence R.↗

STS-107 Flight Day 13 Highlights

This video shows the activities of the STS-107 crew on flight day 13 of the Columbia orbiter's final mission. The crew members include: Rick Husband, Commander; William McCool, Pilot; Kalpana Chawla, David Brown, Michael Anderson, Laurel Clark, Mission Specialists; Ilan Ramon, Payload Specialist. The primary activities of flight day 13 are spaceborne experiments, including troubleshooting undertaken by Mission Specialist Chawla on the Water Mist Fire Suppression (MIST) experiment. Chawla performs troubleshooting tasks relayed to her by Mission Control. She shows Mission Control the location of air and water in a transparent hose that is part of the atomizer on the exterior of the combustion module. She also changes the atomizer head. All six Space Technology and Research Students (STARS) experiments are profiled in the video. These experiments are on ants, crystal growth in a chemical garden, fish embryos, carpenter bees, spiders, and silkworms. The video also includes a view of the southeast Texas coast near Houston, and a view of Portugal, Spain, Gibraltar, Morocco, and the Sahara Desert. The video ends with an explanation of roses at Mission Control which commemorate astronauts who have died on missions.

Source record↗

An expert system for fault management assistance on a space sleep experiment

The expert system, Principal Investigator-in-a-box, or [PI], was designed to assist astronauts or other operators in performing experiments outside their expertise. Currently, the software helps astronauts calibrate instruments for a Sleep and Respiration Experiment without contact with the investigator on the ground. It flew on the Space Shuttle missions STS-90 and STS-95. [PI] displays electrophysiological signals in real time, alerts astronauts via the indicator lights when a poor signal quality is detected, and advises astronauts how to restore good signal quality. Thirty subjects received training on the sleep instrumentation and the [PI] interface. A beneficial effects of [PI] and training reduced troubleshooting time. [PI] benefited subjects on the most difficult scenarios, even though its lights were not 100% accurate. Further, questionnaires showed that most subjects preferred monitoring waveforms with [PI] assistance rather than monitoring waveforms alone. This study addresses problems of complex troubleshooting and the extended time between training and execution that is common to many human operator situations on earth such as in power plant operation, and marine exploration.

NASA Discipline Neuroscience↗

Technology That's Ready and Able to Inspect Those Cables

Attempting to locate a malfunctioning wire in a complex bundle of wires or in a cable that is concealed behind a wall is as difficult as trying to find a needle in a haystack. The result of such an effort can also be costly, time-consuming, and frustrating, whether it is the tedious process of examining cable connections for the Space Shuttle or troubleshooting a cable television hookup. Furthermore, other maintenance restrictions can compound the effort required to locate and repair a particular wiring problem. For example, on the Space Shuttle, once a repair is completed, all systems that have a wire passing through any of the connectors that were disconnected during troubleshooting are affected and, therefore, must undergo retesting, an arduous task that is completely unrelated to the original problem. In an effort to streamline wire inspection and maintenance, two contractors supporting NASA's Kennedy Space Center invented the Standing Wave Reflectometer (SWR) in 1999. In doing so, they leveraged technology that was first developed to detect problems that could lead to aircraft accidents, such as the one that resulted in the catastrophic failure of TWA flight 800 in 1996. The SWR performs a non-intrusive inspection that verifies the condition of electrical power and signal-distribution systems inside the Space Shuttle orbiters. Such testing reduces processing delays and ensures safe operation of these systems.

Source record↗

"Fly-by-Wireless": A Revolution in Aerospace Vehicle Architecture for Instrumentation and Control

Aerospace vehicle programs have always counted on the cables and connectors to provide power, grounding, data and time synchronization throughout a vehicle's life-cycle. Even with numerous improvements, wiring and connector problems and sensors continue to be key failure points, causing many hours of troubleshooting and replacement. Costly flight delays have been precipitated by the need to troubleshoot cables/connections, and/or repair a sensor. Wiring continues to be too expensive to remove once it is installed, even with the weight penalties. Miles of test instrumentation and low flight sensor wires still plague the aerospace industry. New technology options for data connectivity, processing and micro/nano manufacturing are making it possible to retrofit existing vehicles, like the Space Shuttle. New vehicles can now develop architectures that provide for and take advantage of alternatives to wired connectivity. This project motivates the aerospace industry and technology providers to establish: (1) A new emphasis for system engineering approaches to reduce cables and connectors. (2) Provisions for modularity and accessibility in the vehicle architecture. (3) A set of technologies that support alternatives to wired connectivity.

Studor, George↗

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↗

Control of Technology Transfer at JPL

Controlled Technology: 1) Design: preliminary or critical design data, schematics, technical flow charts, SNV code/diagnostics, logic flow diagrams, wirelist, ICDs, detailed specifications or requirements. 2) Development: constraints, computations, configurations, technical analyses, acceptance criteria, anomaly resolution, detailed test plans, detailed technical proposals. 3) Production: process or how-to: assemble, operated, repair, maintain, modify. 4) Manufacturing: technical instructions, specific parts, specific materials, specific qualities, specific processes, specific flow. 5) Operations: how-to operate, contingency or standard operating plans, Ops handbooks. 6) Repair: repair instructions, troubleshooting schemes, detailed schematics. 7) Test: specific procedures, data, analysis, detailed test plan and retest plans, detailed anomaly resolutions, detailed failure causes and corrective actions, troubleshooting, trended test data, flight readiness data. 8) Maintenance: maintenance schedules and plans, methods for regular upkeep, overhaul instructions. 9) Modification: modification instructions, upgrades kit parts, including software

Jet Propulsion Laboratory (JPL)↗

NASA/MOD Operations Impacts from Shuttle Program

Operations plays a pivotal role in the success of any human spaceflight program. This paper will highlight some of the core tenets of spaceflight operations from a systems perspective and use several examples from the Space Shuttle Program to highlight where the success and safety of a mission can hinge upon the preparedness and competency of the operations team. Further, awareness of the types of operations scenarios and impacts that can arise during human crewed space missions can help inform design and mission planning decisions long before a vehicle gets into orbit. A strong operations team is crucial to the development of future programs; capturing the lessons learned from the successes and failures of a past program will allow for safer, more efficient, and better designed programs in the future. No matter how well a vehicle is designed and constructed, there are always unexpected events or failures that occur during space flight missions. Preparation, training, real-time execution, and troubleshooting are skills and values of the Mission Operations Directorate (MOD) flight controller; these operational standards have proven invaluable to the Space Shuttle Program. Understanding and mastery of these same skills will be required of any operations team as technology advances and new vehicles are developed. This paper will focus on individual Space Shuttle mission case studies where specific operational skills, techniques, and preparedness allowed for mission safety and success. It will detail the events leading up to the scenario or failure, how the operations team identified and dealt with the failure and its downstream impacts. The various options for real-time troubleshooting will be discussed along with the operations team final recommendation, execution, and outcome. Finally, the lessons learned will be summarized along with an explanation of how these lessons were used to improve the operational preparedness of future flight control teams.

Fitzpatrick, Michael↗