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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS1985

Least squares collocation applied to local gravimetric solutions from satellite gravity gradiometry data

An autonomous spaceborne gravity gradiometer mission is being considered as a post Geopotential Research Mission project. The introduction of satellite diometry data to geodesy is expected to improve solid earth gravity models. The possibility of utilizing gradiometer data for the determination of pertinent gravimetric quantities on a local basis is explored. The analytical technique of least squares collocation is investigated for its usefulness in local solutions of this type. It is assumed, in the error analysis, that the vertical gravity gradient component of the gradient tensor is used as the raw data signal from which the corresponding reference gradients are removed to create the centered observations required in the collocation solution. The reference gradients are computed from a high degree and order geopotential model. The solution can be made in terms of mean or point gravity anomalies, height anomalies, or other useful gravimetric quantities depending on the choice of covariance types. Selected for this study were 30 x 30 foot mean gravity and height anomalies. Existing software and new software are utilized to implement the collocation technique. It was determined that satellite gradiometry data at an altitude of 200 km can be used successfully for the determination of 30 x 30 foot mean gravity anomalies to an accuracy of 9.2 mgal from this algorithm. It is shown that the resulting accuracy estimates are sensitive to gravity model coefficient uncertainties, data reduction assumptions and satellite mission parameters.

Robbins, J. W.↗
NASA NTRS2006

Anomaly Recovery and the Mars Exploration Rovers

The premise of the design of operations for the Mars Exploration Rovers (MER) is that the vehicles will drive each day. As a result, they will encounter some aspect of the terrain environment that cannot be anticipated or otherwise accommodated by the sequences linked onboard that day. The operations team then must correct the problem by planning then commanding the execution of a different drive the next day. Often other aspects of the operation on the surface of Mars: environmental changes, component degradation, errors in sequence design or execution, etc., lead to anomalies which must be addressed before normal operations can resume. The operational design that makes it possible to recover from a driving error each day also reduces the time needed to recover from anomalies. As an example of the efficiency achieved, less than 5% (about 30 sols out of 700 sols of operations) of the time on the surface has been devoted to recovery from anomalies for each vehicle. In this paper the major anomalies experienced by the MER rovers will be recounted and the streamlined approaches to addressing these problems described. The operational flexibility developed for these missions is also a function of the system design that anticipated a number of likely faults and conditions arising from uncertainty in sequence execution and environmental change. This design will be described as well as the considerations in operation that motivated this design. These considerations will likely be present in any future surface mission.

rovers↗
NASA NTRS2004

Analysis of SSEM Sensor Data Using BEAM

A report describes analysis of space shuttle main engine (SSME) sensor data using Beacon-based Exception Analysis for Multimissions (BEAM) [NASA Tech Briefs articles, the two most relevant being Beacon-Based Exception Analysis for Multimissions (NPO- 20827), Vol. 26, No.9 (September 2002), page 32 and Integrated Formulation of Beacon-Based Exception Analysis for Multimissions (NPO- 21126), Vol. 27, No. 3 (March 2003), page 74] for automated detection of anomalies. A specific implementation of BEAM, using the Dynamical Invariant Anomaly Detector (DIAD), is used to find anomalies commonly encountered during SSME ground test firings. The DIAD detects anomalies by computing coefficients of an autoregressive model and comparing them to expected values extracted from previous training data. The DIAD was trained using nominal SSME test-firing data. DIAD detected all the major anomalies including blade failures, frozen sense lines, and deactivated sensors. The DIAD was particularly sensitive to anomalies caused by faulty sensors and unexpected transients. The system offers a way to reduce SSME analysis time and cost by automatically indicating specific time periods, signals, and features contributing to each anomaly. The software described here executes on a standard workstation and delivers analyses in seconds, a computing time comparable to or faster than the test duration itself, offering potential for real-time analysis.

Zak, Michail↗
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

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↗
DOE OSTI2025

POWER DATA ANOMALY DETECTION PACKAGE

SF-25-150 Software package for developing anomaly detection models for electric power operational data

PLATHOTTAM, SIBY JOSE [Argonne National Laboratory↗
NASA NTRSDate not supplied

Recovering from On-orbit Anomalies on the Astrobee Free Flyers and its Systems

Since 2019, NASA has been operating three Astrobee free flying robots on board the International Space Station (ISS) providing an autonomous and flexible research platform for national and international payload developers in microgravity and serving as a robotic assistant for astronauts on the ISS. During its use on the ISS, in particular with over 750 hours of free-flyer operation as of March 2022, Astrobee and its Docking Station have encountered multiple software and hardware anomalies. These anomalies were either resolved remotely via software and firmware updates, or, where not possible, with hardware replacements on orbit or by the return of the faulty unit to NASA’s ground facilities for its repair. Despite being inherently designed to be repaired or replaced on orbit, Astrobee and its systems can still suffer anomalies that would be complex enough to disassemble, cause risks of hardware damage, or use excessive crew time to perform the repair in orbit. That was the case for the anomaly the Astrobee unit ‘Honey’ encountered, reason why it needed to be down-massed for repair. One of the most common points of failure was found to be the SD card, which is used for the different Astrobee processors and for the Dock Station. Other comparable SD card anomalies were found also on the Astrobee ground units, which provided useful data in the effort of upgrading their systems. This presentation will focus on 1) The overview of the different faults and anomalies on Astrobee and its systems on orbit and on the ground 2) The processes and procedures implemented to resolve the anomalies 3) The implementation of software updates and hardware upgrades in order to reduce the risk on returning anomalies 4) The lessons learned in increasing Astrobee’s robustness and resilience to such anomalies.

International Space Station↗
DOE OSTI2024

TwinMe4AD: WGAN-based Digital Twins for Anomaly Detection

SAND2024-08373O TwinMe4AD is a Python-based software tool designed for anomaly detection using digital twins that closely mimic real, wearable healthcare datasets. The tool is invaluable for scenarios where collecting data is either expensive or impractical, serving as a privacy-preserving solution. Sensitive information is protected by training deep learning models on synthetic data derived from real datasets. One of TwinMe4AD's key features is its anomaly detection capability, which is based on fourth-order moments of parameters. This versatile approach can be applied across a range of datasets, from univariate to multivariate, making it compatible with various types of data. It also generates synthetic twins using Wasserstein Generative Adversarial Networks (WGANs), allowing users to create a small cohort of a population similar to that of a village population. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Poorey, Kunal↗
NASA NTRS2006

Multi-Agent System for Managing Human Activities in Space Operations

In manned space operations today, the astronauts' activity schedules are preplanned and adjusted daily on Earth. We have developed the Distributed Collaboration and Interaction (DCI) multi-agent system to investigate automating aspects of human activity management. The DCI System assists (1) plan generation, (2) human activity tracking, (3) plan revision, and (4) mixed initiative interaction with the plan. We have deployed and evaluated the DCI system at JSC to assist control engineers in managing anomaly handling activities for automated life support systems. DCI operated round the clock for 20 months in the Water Research Facility at JSC. Using this software, we reduced anomaly response time by engineers from up to 10 hours in previous tests to under an hour. Based on this evaluation, we conclude that agent assistance for schedule management has potential to improve astronaut activity awareness and reduce response time in situations where crew are interrupted to handle anomalies.

Schrenkenghost, Debra↗
NASA NTRS2007

System for Secure Integration of Aviation Data

The Aviation Data Integration System (ADIS) of Ames Research Center has been established to promote analysis of aviation data by airlines and other interested users for purposes of enhancing the quality (especially safety) of flight operations. The ADIS is a system of computer hardware and software for collecting, integrating, and disseminating aviation data pertaining to flights and specified flight events that involve one or more airline(s). The ADIS is secure in the sense that care is taken to ensure the integrity of sources of collected data and to verify the authorizations of requesters to receive data. Most importantly, the ADIS removes a disincentive to collection and exchange of useful data by providing for automatic removal of information that could be used to identify specific flights and crewmembers. Such information, denoted sensitive information, includes flight data (here signifying data collected by sensors aboard an aircraft during flight), weather data for a specified route on a specified date, date and time, and any other information traceable to a specific flight. The removal of information that could be used to perform such tracing is called "deidentification." Airlines are often reluctant to keep flight data in identifiable form because of concerns about loss of anonymity. Hence, one of the things needed to promote retention and analysis of aviation data is an automated means of de-identification of archived flight data to enable integration of flight data with non-flight aviation data while preserving anonymity. Preferably, such an automated means would enable end users of the data to continue to use pre-existing data-analysis software to identify anomalies in flight data without identifying a specific anomalous flight. It would then also be possible to perform statistical analyses of integrated data. These needs are satisfied by the ADIS, which enables an end user to request aviation data associated with de-identified flight data. The ADIS includes client software integrated with other software running on flight-operations quality-assurance (FOQA) computers for purposes of analyzing data to study specified types of events or exceedences (departures of flight parameters from normal ranges). In addition to ADIS client software, ADIS includes server hardware and software that provide services to the ADIS clients via the Internet (see figure). The ADIS server receives and integrates flight and non-flight data pertaining to flights from multiple sources. The server accepts data updates from authorized sources only and responds to requests from authorized users only. In order to satisfy security requirements established by the airlines, (1) an ADIS client must not be accessible from the Internet by an unauthorized user and (2) non-flight data as airport terminal information system (ATIS) and weather data must be displayed without any identifying flight information. ADIS hardware and software architecture as well as encryption and data display scheme are designed to meet these requirements. When a user requests one or more selected aviation data characteristics associated with an event (e.g., a collision, near miss, equipment malfunction, or exceedence), the ADIS client augments the request with date and time information from encrypted files and submits the augmented request to the server. Once the user s authorization has been verified, the server returns the requested information in de-identified form.

Kulkarni, Deepak↗
NASA NTRS2009

Biennial Research and Technology Development Report

Various articles for the Biennial Research and Technology Development Report of the Johnson Space Center include: Automating ISS File Management using Agent-Based Systems Integration; International Space Station Operations; Planning and Monitoring ISS Solar Array Operations; Water Egress and Survival Trainer; Search and Relationship -- Mining of Heterogeneous Flight Control Documents; and Anomaly Monitoring Inductive Software System.

Taylor, Elizabeth↗
NASA NTRSDate not supplied

Quality Assurance of ISS LIS lightning Data

Optical lighting detection from space has been ongoing since 1995 from the Optical Transient detector (1995-2000), then later by the Lightning Imaging Sensors (LIS) on the Tropical Rainfall Measuring Mission (TRMM) satellite (1997-2015) and the International Space Station (ISS) (ISS 2017-present). A rapid readout (2 ms) 128x128 pixel CCD (Charge-coupled Device) array detects optical transients from lightning (events) and transmits the observations to ground. Ground processing determines whether individual events are likely due to lightning or noise. Likely lightning events are then grouped into groups, flashes, and areas and their location on the earth are determined. The lightning data are saved in orbit files; each file containing the time, location, and intensity of the lightning events, groups, flashes, and areas detected during one orbit. Even after this processing anomalies may exist in some of the orbits. A manual quality assurance (QA) procedure is performed monthly to assess the data and omit orbits with obvious anomalies from the dataset. These files are not included in the final dataset that has undergone QA. The manual QA was developed during the OTD mission to identify artifacts that made it through ground processing algorithms. The manual QA process was continued for the TRMM and ISS LIS missions. Many anomalies have been identified and software updates now address many of them. However, some anomalies still occur in the processed datasets. The manual QA process examines the data for obvious issues in the lightning files that passed through the processing algorithms. These files are considered anomalous and are not included in the final QA dataset. Some issues that may cause an orbit to be considered anomalous include: obvious noise (excess events that make it through the processing), suspect geolocation, and excessive missing data packets. As an example, one way noise manifests is as “streaks” in lightning climatology plots. These streaks are especially apparent in low lightning rate regions (eg., over oceans). Since there is no method at present to extract these anomalies during processing, orbit files with significant anomalies are identified and removed from the final QA ISS LIS dataset. The final QA dataset can be obtained files from the Global Hydrometeorological Resource Center (GHRC). This presentation will provide examples of the various anomalies and examine how often the various anomalies occur and how much data is lost due to the omission of the anomalous orbits. Comparisons with OTD and TRMM LIS will also be examined.

ISS↗
NASA NTRS1994

An expert system for diagnosing anomalies of spacecraft

Although the analysis of anomalous behavior of satellites is difficult because it is a very complex process, it is important to be able to make an accurate assessment in a timely manner when the anomaly is observed. Spacecraft operators may have to take corrective action or to 'safe' the spacecraft; space-environment forecasters may have to assess the environmental situation and issue warnings and alerts regarding hazardous conditions, and scientists and engineers may want to gain knowledge for future designs to mitigate the problems. Anomalies can be hardware problems, software errors, environmentally induced, or even the cause of workmanship. Spacecraft anomalies attributable to electrostatic discharges have been known to cause command errors. A goal is to develop an automated system based on this concept to reduce the number of personnel required to operate large programs or missions such as Hubble Space Telescope (HST) and Mission to Planet Earth (MTPE). Although expert systems to detect anomalous behavior of satellites during operations are established, diagnosis of the anomaly is a complex procedure and is a new development.

Lauriente, Michael↗
NASA NTRS1980

DSS command software update

The modifications, additions, and testing results for a version of the Deep Space Station command software, generated for support of the Voyager Saturn encounter, are discussed. The software update requirements included efforts to: (1) recode portions of the software to permit recovery of approximately 2000 words of memory; (2) correct five Voyager Ground data System liens; (3) provide capability to automatically turn off the command processor assembly local printer during periods of low activity; and (4) correct anomalies existing in the software.

Stinnett, W. G.↗
NASA NTRS2007

The Dangers of Failure Masking in Fault-Tolerant Software: Aspects of a Recent In-Flight Upset Event

On 1 August 2005, a Boeing Company 777-200 aircraft, operating on an international passenger flight from Australia to Malaysia, was involved in a significant upset event while flying on autopilot. The Australian Transport Safety Bureau's investigation into the event discovered that an anomaly existed in the component software hierarchy that allowed inputs from a known faulty accelerometer to be processed by the air data inertial reference unit (ADIRU) and used by the primary flight computer, autopilot and other aircraft systems. This anomaly had existed in original ADIRU software, and had not been detected in the testing and certification process for the unit. This paper describes the software aspects of the incident in detail, and suggests possible implications concerning complex, safety-critical, fault-tolerant software.

Johnson, C. W.↗
NASA NTRS2018

LADEE Simulation for Mission Operations

The Lunar Atmosphere Dust Environment Explorer (LADEE) model-based spacecraft simulator has been discussed previously at the Workshop on Spacecraft Flight Software including the verification and validation of the flight software, hardware integration of payloads, and multi-domain simulation. In addition to flight software development and testing the LADEE simulator was used by Mission Operations to develop and test spacecraft command scripts, train operators during mission simulations, verification of all tactical command sequence files uploaded to spacecraft during flight.This presentation will discuss the experience of the LADEE operations team using the spacecraft simulator including implementation, processes and lessons learned. We will also discuss a specific instance where the simulator was used in operations to debug and design a software fix for a spacecraft anomaly experienced with the star tracker.

Operations↗