Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software anomalies”

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 145 records · Page 8

Overview on METEOSAT geometrical image data processing

Digital Images acquired from the geostationary METEOSAT satellites are processed and disseminated at ESA's European Space Operations Centre in Darmstadt, Germany. Their scientific value is mainly dependent on their radiometric quality and geometric stability. This paper will give an overview on the image processing activities performed at ESOC, concentrating on the geometrical restoration and quality evaluation. The performance of the rectification process for the various satellites over the past years will be presented and the impacts of external events as for instance the Pinatubo eruption in 1991 will be explained. Special developments both in hard and software, necessary to cope with demanding tasks as new image resampling or to correct for spacecraft anomalies, are presented as well. The rotating lens of MET-5 causing severe geometrical image distortions is an example for the latter.

Diekmann, Frank J.↗

General Purpose Data-Driven Online System Health Monitoring with Applications to Space Operations

Modern space transportation and ground support system designs are becoming increasingly sophisticated and complex. Determining the health state of these systems using traditional parameter limit checking, or model-based or rule-based methods is becoming more difficult as the number of sensors and component interactions grows. Data-driven monitoring techniques have been developed to address these issues by analyzing system operations data to automatically characterize normal system behavior. System health can be monitored by comparing real-time operating data with these nominal characterizations, providing detection of anomalous data signatures indicative of system faults, failures, or precursors of significant failures. The Inductive Monitoring System (IMS) is a general purpose, data-driven system health monitoring software tool that has been successfully applied to several aerospace applications and is under evaluation for anomaly detection in vehicle and ground equipment for next generation launch systems. After an introduction to IMS application development, we discuss these NASA online monitoring applications, including the integration of IMS with complementary model-based and rule-based methods. Although the examples presented in this paper are from space operations applications, IMS is a general-purpose health-monitoring tool that is also applicable to power generation and transmission system monitoring.

Iverson, David L.↗

Assessment of in-flight anomalies of long life outer plant mission

Thee unmanned planetary spacecraft to the outer planets have been controlled and operated successfully in space for an accumulated total of 66 years. The Voyager 1 and 2 spacecraft each have been in space for more than 26 years. The Galileo spacecraft was in space for 14 years, including eight years in orbit about Jupiter. During the flight operations for these missions, anomalies for the ground data system and the flight systems have been tracked using the anomaly reporting tool at the Jet Propulsion Laboratory. A total of 3300 incidents, surprises, and anomaly reports have been recorded in the database. This paper describes methods and results for classifying and identifying trends relative to ground system vs. flight system, software vs. hardware, and corrective actions. There are several lessons learned from these assessments that significantly benefit the design and planning for long life missions of the future. These include the necessity for having redundancy for successful operation of the spacecraft, awareness that anomaly reporting is dependent on mission activity not the age of the spacecraft, and the need for having a program to maintain and transfer operation knowledge and tools to replacement flight team members.

anomalies↗

In Pursuit of Abundance Anomalies and the FIP Effect in Late-Type Stellar Coronae

Key EUVE and ASCA data have been retrieved from their respective archives. New software has been written in the IDL language to carry out data analysis and to interface with the relevant atomic physics databases. During the analysis of ASCA spectra, it was found that the abundances of elements other than Fe could not be constrained very well, and Fe abundances were not constrained unless the underlying emission measure distribution model was reasonably well-determined. Consequently, the study has concentrated on the quantity Fe/H. A method has been developed as a means of deriving Fe/H based on fitting the continuum to EUVE spectra, thereby using the Fe lines to determine the Fe abundance. A Monte Carlo Markov Chain algorithm was also developed to determine the emission measure distribution based on observed spectral lines. This is the first application of this type of monte carlo approach to this scientific problem. This work has resulted in three scientific publications, one of which published, one of which is now ready for submission and the other of which is still in preparation:

Drake, Jeremy↗

Aircraft Fault Detection and Classification Using Multi-Level Immune Learning Detection

This work is an extension of a recently developed software tool called MILD (Multi-level Immune Learning Detection), which implements a negative selection algorithm for anomaly and fault detection that is inspired by the human immune system. The immunity-based approach can detect a broad spectrum of known and unforeseen faults. We extend MILD by applying a neural network classifier to identify the pattern of fault detectors that are activated during fault detection. Consequently, MILD now performs fault detection and identification of the system under investigation. This paper describes the application of MILD to detect and classify faults of a generic transport aircraft augmented with an intelligent flight controller. The intelligent control architecture is designed to accommodate faults without the need to explicitly identify them. Adding knowledge about the existence and type of a fault will improve the handling qualities of a degraded aircraft and impact tactical and strategic maneuvering decisions. In addition, providing fault information to the pilot is important for maintaining situational awareness so that he can avoid performing an action that might lead to unexpected behavior - e.g., an action that exceeds the remaining control authority of the damaged aircraft. We discuss the detection and classification results of simulated failures of the aircraft's control system and show that MILD is effective at determining the problem with low false alarm and misclassification rates.

Wong, Derek↗

AERCam Autonomy: Intelligent Software Architecture for Robotic Free Flying Nanosatellite Inspection Vehicles

The NASA Johnson Space Center has developed a nanosatellite-class Free Flyer intended for future external inspection and remote viewing of human spacecraft. The Miniature Autonomous Extravehicular Robotic Camera (Mini AERCam) technology demonstration unit has been integrated into the approximate form and function of a flight system. The spherical Mini AERCam Free Flyer is 7.5 inches in diameter and weighs approximately 10 pounds, yet it incorporates significant additional capabilities compared to the 35-pound, 14-inch diameter AERCam Sprint that flew as a Shuttle flight experiment in 1997. Mini AERCam hosts a full suite of miniaturized avionics, instrumentation, communications, navigation, power, propulsion, and imaging subsystems, including digital video cameras and a high resolution still image camera. The vehicle is designed for either remotely piloted operations or supervised autonomous operations, including automatic stationkeeping, point-to-point maneuvering, and waypoint tracking. The Mini AERCam Free Flyer is accompanied by a sophisticated control station for command and control, as well as a docking system for automated deployment, docking, and recharge at a parent spacecraft. Free Flyer functional testing has been conducted successfully on both an airbearing table and in a six-degree-of-freedom closed-loop orbital simulation with avionics hardware in the loop. Mini AERCam aims to provide beneficial on-orbit views that cannot be obtained from fixed cameras, cameras on robotic manipulators, or cameras carried by crewmembers during extravehicular activities (EVA s). On Shuttle or International Space Station (ISS), for example, Mini AERCam could support external robotic operations by supplying orthogonal views to the intravehicular activity (IVA) robotic operator, supply views of EVA operations to IVA and/or ground crews monitoring the EVA, and carry out independent visual inspections of areas of interest around the spacecraft. To enable these future benefits with minimal impact on IVA operators and ground controllers, the Mini AERCam system architecture incorporates intelligent systems attributes that support various autonomous capabilities. 1) A robust command sequencer enables task-level command scripting. Command scripting is employed for operations such as automatic inspection scans over a region of interest, and operator-hands-off automated docking. 2) A system manager built on the same expert-system software as the command sequencer provides detection and smart-response capability for potential system-level anomalies, like loss of communications between the Free Flyer and control station. 3) An AERCam dynamics manager provides nominal and off-nominal management of guidance, navigation, and control (GN&C) functions. It is employed for safe trajectory monitoring, contingency maneuvering, and related roles. This paper will describe these architectural components of Mini AERCam autonomy, as well as the interaction of these elements with a human operator during supervised autonomous control.

Fredrickson, Steven E.↗

Integrated System for Autonomous and Adaptive Caretaking (ISAAC): Phase 1 Low-Fidelity Demo

This presentation describes the ISAAC phase 1 low-fidelity demonstration results. The demonstration satisfied the milestone from the Gateway-ISAAC Memorandum of Understanding to "Demonstrate spatial and logical data registration between robotics and spacecraft". It integrated many new ISAAC components, including a spatially linked model, Astrobee multi-sensor mapping, and an integrated data interface. It advanced ISAAC key performance parameters related to mapping, in a lab setting. Areas for phase 1 forward work include: improve maturity toward the high-fidelity demo on the ISS; demonstrate mapping with more sensor modalities; expand initial anomaly detection implementation into a flexible framework with multiple detection algorithms for different tasks; begin open source software release process for releasable ISAAC components.

robotics↗

Evolution of safety-critical requirements post-launch

This paper reports the results of a small study of requirements changes to the onboard software of three spacecraft subsequent to launch. Only those requirement changes that resulted from post-launch anomalies (i.e., durring operations) were of interest here, since the goal was to better understand the relationship between critical anomolies during operations and how safety-critical requirements evolve.

requirements↗

Considerations for Using Autonomous Flight Termination Software in Crewed Launch Vehicles

Autonomous flight termination systems (AFTS) are being progressively employed onboard launch vehicles to replace ground personnel and infrastructure needed to terminate flight or destruct the vehicle should an anomaly occur. This automation uses on-board real-time data and encoded logic to determine if the flight should be self-terminated. For uncrewed launch vehicles, FTS systems are required to protect the public and governed by the United States Space Force (USSF). For crewed missions, NASA must augment range AFTS requirements for crew safety and certify each flight according to human rating standards, thus adding unique requirements for reuse of software originally intended for uncrewed missions. This bulletin summarizes new information relating to AFTS to raise awareness of key distinctions, summarize considerations and outline best practices for incorporating AFTS into human-rated systems.

Avionics↗

Spread spectrum time domain reflectometry (SSTDR) and frequency domain reflectometry (FDR) cable inspection using machine learning

Cables are initially qualified for nuclear power plant use for 40 years. As plants extend their operating license to 60 and 80 years, justification for continued cable use must shift to a condition-based approach since it is cost prohibitive to completely replace cables that are likely still capable of performing their design function. The Pacific Northwest National Laboratory (PNNL) Accelerated and Real Time Experimental Nodal Analysis (ARENA) cable motor test bed was used to test the response of a commercial spread spectrum time domain reflectometry (SSTDR) system, a laboratory instrument software-controlled SSTDR, and a vector network analyzer-based frequency domain reflectometry (FDR) system to various cable anomalies. The three instrument systems were able to interrogate cables over a range of frequency bandwidths that can be helpful for human data analysis. Data were subjected to supervised and unsupervised machine learning (ML) analyses to distinguish normal undamaged cable responses from anomalous cable responses. Both supervised and unsupervised ML approaches produced encouraging results with an undamaged/anomalous prediction accuracy from 0.69% to 0.87%. Recommendations for further development and field implementation include increased and more balanced sample sets particularly including more training data.

SSTDR, FDR, Reflectometry, Machine Learning, ARENA↗

An innovative design for autonomous backup attitude control of the Gamma Ray Observatory

The Gamma Ray Observatory is a NASA funded three-axis stabilized spacecraft which will carry four scientific instruments to observe gamma ray phenomena. The requirement to protect the scientific mission from system failures led to the attitude control and determination system design described in this paper. The design employs nine control modes with error detection, hardware substitution, and autonomous mode switching. The system architecture evolved to eliminate cross-dependence between the primary on-board computer (OBC) and the backup control processor electronics. Cross strapping of sensors and actuators and separation of the input/output electronics ensure that a reliable set of sensors and actuators will be available for backup mode operation. The OBC software includes failure detection, hardware reconfiguration, and mode switching logic which provide the ability to autonomously transfer, upon anomaly, to a reliable backup mode. Verification of this mode transition design is done in four test programs: at the unit level, by analytical simulation, by a hybrid breadboard electronics-simulation setup, and by a flight hardware-simulation test.

Tai, F.↗

Development of a Relay Performance Web Tool for the Mars Network

Modern Mars surface missions rely upon orbiting spacecraft to relay communications to and from Earth systems. An important component of this multi-mission relay process is the collection of relay performance statistics supporting strategic trend analysis and tactical anomaly identification and tracking.

data accountability↗

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a unique private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed along with evolution of the system in preparation for the second uncrewed test flight. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies.

Robert C. Dempsey↗

Continuous monitoring of the lunar or Martian subsurface using on-board pattern recognition and neural processing of Rover geophysical data

The ultimate goal is to create an extraterrestrial unmanned system for subsurface mapping and exploration. Neural networks are to be used to recognize anomalies in the profiles that correspond to potentially exploitable subsurface features. The ground penetrating radar (GPR) techniques are likewise identical. Hence, the preliminary research focus on GPR systems will be directly applicable to seismic systems once such systems can be designed for continuous operation. The original GPR profile may be very complex due to electrical behavior of the background, targets, and antennas, much as the seismic record is made complex by multiple reflections, ghosting, and ringing. Because the format of the GPR data is similar to the format of seismic data, seismic processing software may be applied to GPR data to help enhance the data. A neural network may then be trained to more accurately identify anomalies from the processed record than from the original record.

Mcgill, J. W.↗

Virtual Instrument Simulator for CERES

A benchtop virtual instrument simulator for CERES (Clouds and the Earth's Radiant Energy System) has been built at NASA, Langley Research Center in Hampton, VA. The CERES instruments will fly on several earth orbiting platforms notably NASDA's Tropical Rainfall Measurement Mission (TRMM) and NASA's Earth Observing System (EOS) satellites. CERES measures top of the atmosphere radiative fluxes using microprocessor controlled scanning radiometers. The CERES Virtual Instrument Simulator consists of electronic circuitry identical to the flight unit's twin microprocessors and telemetry interface to the supporting spacecraft electronics and two personal computers (PC) connected to the I/O ports that control azimuth and elevation gimbals. Software consists of the unmodified TRW developed Flight Code and Ground Support Software which serves as the instrument monitor and NASA/TRW developed engineering models of the scanners. The CERES Instrument Simulator will serve as a testbed for testing of custom instrument commands intended to solve in-flight anomalies of the instruments which could arise during the CERES mission. One of the supporting computers supports the telemetry display which monitors the simulator microprocessors during the development and testing of custom instrument commands. The CERES engineering development software models have been modified to provide a virtual instrument running on a second supporting computer linked in real time to the instrument flight microprocessor control ports. The CERES Instrument Simulator will be used to verify memory uploads by the CERES Flight Operations TEAM at NASA. Plots of the virtual scanner models match the actual instrument scan plots. A high speed logic analyzer has been used to track the performance of the flight microprocessor. The concept of using an identical but non-flight qualified microprocessor and electronics ensemble linked to a virtual instrument with identical system software affords a relatively inexpensive simulation system capable of high fidelity.

Chapman, John J.↗

Systems Modeling to Implement Integrated System Health Management Capability

ISHM capability includes: detection of anomalies, diagnosis of causes of anomalies, prediction of future anomalies, and user interfaces that enable integrated awareness (past, present, and future) by users. This is achieved by focused management of data, information and knowledge (DIaK) that will likely be distributed across networks. Management of DIaK implies storage, sharing (timely availability), maintaining, evolving, and processing. Processing of DIaK encapsulates strategies, methodologies, algorithms, etc. focused on achieving high ISHM Functional Capability Level (FCL). High FCL means a high degree of success in detecting anomalies, diagnosing causes, predicting future anomalies, and enabling health integrated awareness by the user. A model that enables ISHM capability, and hence, DIaK management, is denominated the ISHM Model of the System (IMS). We describe aspects of the IMS that focus on processing of DIaK. Strategies, methodologies, and algorithms require proper context. We describe an approach to define and use contexts, implementation in an object-oriented software environment (G2), and validation using actual test data from a methane thruster test program at NASA SSC. Context is linked to existence of relationships among elements of a system. For example, the context to use a strategy to detect leak is to identify closed subsystems (e.g. bounded by closed valves and by tanks) that include pressure sensors, and check if the pressure is changing. We call these subsystems Pressurizable Subsystems. If pressure changes are detected, then all members of the closed subsystem become suspect of leakage. In this case, the context is defined by identifying a subsystem that is suitable for applying a strategy. Contexts are defined in many ways. Often, a context is defined by relationships of function (e.g. liquid flow, maintaining pressure, etc.), form (e.g. part of the same component, connected to other components, etc.), or space (e.g. physically close, touching the same common element, etc.). The context might be defined dynamically (if conditions for the context appear and disappear dynamically) or statically. Although this approach is akin to case-based reasoning, we are implementing it using a software environment that embodies tools to define and manage relationships (of any nature) among objects in a very intuitive manner. Context for higher level inferences (that use detected anomalies or events), primarily for diagnosis and prognosis, are related to causal relationships. This is useful to develop root-cause analysis trees showing an event linked to its possible causes and effects. The innovation pertaining to RCA trees encompasses use of previously defined subsystems as well as individual elements in the tree. This approach allows more powerful implementations of RCA capability in object-oriented environments. For example, if a pressurizable subsystem is leaking, its root-cause representation within an RCA tree will show that the cause is that all elements of that subsystem are suspect of leak. Such a tree would apply to all instances of leak-events detected and all elements in all pressurizable subsystems in the system. Example subsystems in our environment to build IMS include: Pressurizable Subsystem, Fluid-Fill Subsystem, Flow-Thru-Valve Subsystem, and Fluid Supply Subsystem. The software environment for IMS is designed to potentially allow definition of any relationship suitable to create a context to achieve ISHM capability.

Figueroa, Jorge F.↗

Generic trending and analysis system

The Generic Trending and Analysis System (GTAS) is a generic spacecraft performance monitoring tool developed by NASA Code 511 and Loral Aerosys. It is designed to facilitate quick anomaly resolution and trend analysis. Traditionally, the job of off-line analysis has been performed using hardware and software systems developed for real-time spacecraft contacts; then, the systems were supplemented with a collection of tools developed by Flight Operations Team (FOT) members. Since the number of upcoming missions is increasing, NASA can no longer afford to operate in this manner. GTAS improves control center productivity and effectiveness because it provides a generic solution across multiple missions. Thus, GTAS eliminates the need for each individual mission to develop duplicate capabilities. It also allows for more sophisticated tools to be developed because it draws resources from several projects. In addition, the GTAS software system incorporates commercial off-the-shelf tools software (COTS) packages and reuses components of other NASA-developed systems wherever possible. GTAS has incorporated lessons learned from previous missions by involving the users early in the development process. GTAS users took a proactive role in requirements analysis, design, development, and testing. Because of user involvement, several special tools were designed and are now being developed. GTAS users expressed considerable interest in facilitating data collection for long term trending and analysis. As a result, GTAS provides easy access to large volumes of processed telemetry data directly in the control center. The GTAS archival and retrieval capabilities are supported by the integration of optical disk technology and a COTS relational database management system.

Keehan, Lori↗

Mission Summary of Cassini Spacecraft Guidance and Control Hardware Health and Performance

The Cassini-Huygens mission ended on September 15, 2017, after nearly two decades in ight. The well-designed Cassini spacecraft had robust hardware that permitted two extended missions, lasting nine years longer than the expected prime mission. At the end of the mission, the Attitude and Articulation Control Subsystem (AACS) was using two pieces of redundant back-up of hardware, one reaction wheel and the hydrazine thruster branch, due to hardware anomalies earlier in the mission. The back-up hardware performed nominally through the rest of mission. The prime reaction wheels at the end of the mission had reached more than 130% of the consumable limit for number of revolutions. No thruster on either thruster branch accumulated more than 45% of the consumable limits. The inertial reference unit slightly exceeded the pre-launch requirements on bias error, but as the software continuously estimated this value in ight, the attitude estimation was not adversely a ected. The star trackers performed nominally, and though there was a spacecraft anomaly in 1998 related to the star trackers, the origin was not in hardware itself. The Sun sensors and accelerometer both performed as expected and met all requirements throughout the mission. Ultimately, the lifetime of the Cassini spacecraft was not limited by hardware performance. Planetary protection requirements necessitated the end of the mission as the spacecraft's propellant reserves depleted, and Cassini plunged into Saturn's atmosphere with a healthy attitude control system.

Stupik, Joan↗