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 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
DOE OSTI2024

A Hybrid Anomaly Detection Approach for Obfuscated Malware

With the rapid evolution of malicious software, cyber threats have become increasingly sophisticated, employing advanced obfuscation techniques to evade traditional detection methods. This study presents a hybrid anomaly detection approach applied to obfuscated malware. Even though there is a large body of research in this field, existing malware detection techniques have some drawbacks, such as requiring large amounts of data, trustworthiness (imprecise results) of algorithms, and advanced obfuscation. To overcome these challenges, there is a need to employ solid and efficient techniques for malware detection. This paper proposes a hybrid approach, combining an autoencoder with traditional machine-learning methods to create an efficient malware detection framework. We used the malware memory dataset (MalMemAnalysis-2022) to evaluate this framework. The results indicate that our proposed approach can detect obfuscated malware when a deep autoencoder used for feature learning is combined with logistic regression, and it is extremely fast with an Accuracy, Detection Rate (DR), Matthew Correlation Coefficient(MCC), and Statistical Parity Difference

malware detection, Hybrid Anomly Detection, Obfusc↗
NASA NTRS1979

Star tracker error analysis: Roll-to-pitch nonorthogonality

An error analysis is described on an anomaly isolated in the star tracker software line of sight (LOS) rate test. The LOS rate cosine was found to be greater than one in certain cases which implied that either one or both of the star tracker measured end point unit vectors used to compute the LOS rate cosine had lengths greater than unity. The roll/pitch nonorthogonality matrix in the TNB CL module of the IMU software is examined as the source of error.

Corson, R. W.↗
NASA NTRS1997

Hubble Space Telescope Astrometry Science Team

Topics considered include: Calibration and Astrometry Pipeline; Astrometry Anomaly Analysis; The STAT pipeline and software analysis tools; GTO Program; Parallaxes of Astrophysically Interesting Objects; HST- Hipparcos Extragalactic Link; Ground-Based Observations of Radial Velocities; GTO Globular Cluster Internal Motions; and GTO Hyades Cluster Member FGS Parallaxes.

Benedict, George F.↗
NASA NTRS2003

Resource Management for Real-Time Adaptive Agents

Increased autonomy and automation in onboard flight systems offer numerous potential benefits, including cost reduction and greater flexibility. The existence of generic mechanisms for automation is critical for handling unanticipated science events and anomalies where limitations in traditional control software with fixed, predetermined algorithms can mean loss of science data and missed opportunities for observing important terrestrial events. We have developed such a mechanism by adding a Hierarchical Agent-based ReaLTime technology (HART) extension to our Dynamic Resource Management (DRM) middleware. Traditional DRM provides mechanisms to monitor the realtime performance of distributed applications and to move applications among processors to improve real-time performance. In the HART project we have designed and implemented a performance adaptation mechanism to improve reaktime performance. To use this mechanism, applications are developed that can run at various levels of quality. The DRM can choose a setting for the quality level of an application dynamically at run-time in order to manage satellite resource usage more effectively. A groundbased prototype of a satellite system that captures and processes images has also been developed as part of this project to be used as a benchmark for evaluating the resource management framework A significant enhancement of this generic mission-independent framework allows scientists to specify the utility, or "scientific benefit," of science observations under various conditions like cloud cover and compression method. The resource manager then uses these benefit tables to determine in redtime how to set the quality levels for applications to maximize overall system utility as defined by the scientists running the mission. We also show how maintenance functions llke health and safety data can be integrated into the utility framework. Once thls framework has been certified for missions and successfully flight tested it can be reused with little development overhead for other missions. In contrast, current space missions llke Swift manage similar types of resource trade -off completely with the scientific application code itself, and such code must be re-certified and tested for each mission even if a large portion of the code base is shared. This final report discusses some of the major issues motivating this research effort, provides a literature review of the related work, discusses the resource management framework and ground-based satellite system prototype that has been developed, indicates what work is yet to be performed, and provides a list of publications resulting from this work.

Welch, Lonnie↗
NASA NTRS2010

Functional Fault Modeling Conventions and Practices for Real-Time Fault Isolation

The purpose of this paper is to present the conventions, best practices, and processes that were established based on the prototype development of a Functional Fault Model (FFM) for a Cryogenic System that would be used for real-time Fault Isolation in a Fault Detection, Isolation, and Recovery (FDIR) system. The FDIR system is envisioned to perform health management functions for both a launch vehicle and the ground systems that support the vehicle during checkout and launch countdown by using a suite of complimentary software tools that alert operators to anomalies and failures in real-time. The FFMs were created offline but would eventually be used by a real-time reasoner to isolate faults in a Cryogenic System. Through their development and review, a set of modeling conventions and best practices were established. The prototype FFM development also provided a pathfinder for future FFM development processes. This paper documents the rationale and considerations for robust FFMs that can easily be transitioned to a real-time operating environment.

Ferrell, Bob↗
NASA NTRS2018

Command and Control Software Development

As NASA’s role in spaceflight operations change, so too does its design priorities. NASA’s flagship venture, the Space Launch System (SLS), is being created primarily to explore deep space. While commercial partners conduct low Earth orbit resupplies, tests, and even transportation of astronauts, NASA can divert more resources to more exciting projects - going back to the moon, or onwards to Mars. In the short term, this goal manifests in the upcoming Exploration Mission-1 (EM-1) test of the SLS, slated for as early as 2019. SLS, with the Orion capsule, will travel farther than any human-rated spacecraft has gone before. As the most powerful launch vehicle ever created, SLS requires many new innovations to ensure mission success. One such technology is the launch control software, which is the focus of this internship. The SLS launch control software is composed of many functions, all of which require rigorous testing to meet the standard of life-critical code. To facilitate easier testing, the first project I undertook was to customize the open-source tool Wireshark to the software team’s needs. Wireshark is a network protocol analyzer that can take in information about custom information packets. The launch control software will have several protocols that are custom to NASA. I ensured that all necessary component files were the correct file type and in the correct structure for Wireshark to compile. Having allowed Wireshark access to understand custom NASA data packets, testers of the launch control software will be able to find anomalies easier.

Wang, Zhengdong↗
NASA NTRS2008

JPL Test Effectiveness Analysis

1) The pilot study provided meaningful conclusions that are generally consistent with the earlier Test Effectiveness work done between 1992 and 1994: a) Analysis of pre-launch problem/failure reports is consistent with earlier work. b) Analysis of post-launch early mission anomaly reports indicates that there are more software issues in newer missions, and the no-test category for identification of post-launch failures is more significant than in the earlier analysis. 2) Future work includes understanding how differences in Missions effect these analyses: a) There are large variations in the number of problem reports and issues that are documented by the different Projects/Missions. b) Some missions do not have any reported environmental test anomalies, even though environmental tests were performed. 3) Each project/mission has different standards and conventions for filling out the PFR forms, the industry may wish to address this issue: a) Existing problem reporting forms are to document and track problems, failures, and issues (etc.) for the projects, to ensure high quality. b) Existing problem reporting forms are not intended for data mining.

failure cause↗
NASA NTRS2007

NASA's Software Safety Standard

NASA relies more and more on software to control, monitor, and verify its safety critical systems, facilities and operations. Since the 1960's there has hardly been a spacecraft launched that does not have a computer on board that will provide command and control services. There have been recent incidents where software has played a role in high-profile mission failures and hazardous incidents. For example, the Mars Orbiter, Mars Polar Lander, the DART (Demonstration of Autonomous Rendezvous Technology), and MER (Mars Exploration Rover) Spirit anomalies were all caused or contributed to by software. The Mission Control Centers for the Shuttle, ISS, and unmanned programs are highly dependant on software for data displays, analysis, and mission planning. Despite this growing dependence on software control and monitoring, there has been little to no consistent application of software safety practices and methodology to NASA's projects with safety critical software. Meanwhile, academia and private industry have been stepping forward with procedures and standards for safety critical systems and software, for example Dr. Nancy Leveson's book Safeware: System Safety and Computers. The NASA Software Safety Standard, originally published in 1997, was widely ignored due to its complexity and poor organization. It also focused on concepts rather than definite procedural requirements organized around a software project lifecycle. Led by NASA Headquarters Office of Safety and Mission Assurance, the NASA Software Safety Standard has recently undergone a significant update. This new standard provides the procedures and guidelines for evaluating a project for safety criticality and then lays out the minimum project lifecycle requirements to assure the software is created, operated, and maintained in the safest possible manner. This update of the standard clearly delineates the minimum set of software safety requirements for a project without detailing the implementation for those requirements. This allows the projects leeway to meet these requirements in many forms that best suit a particular project's needs and safety risk. In other words, it tells the project what to do, not how to do it. This update also incorporated advances in the state of the practice of software safety from academia and private industry. It addresses some of the more common issues now facing software developers in the NASA environment such as the use of Commercial-Off-the-Shelf Software (COTS), Modified OTS (MOTS), Government OTS (GOTS), and reused software. A team from across NASA developed the update and it has had both NASA-wide internal reviews by software engineering, quality, safety, and project management. It has also had expert external review. This presentation and paper will discuss the new NASA Software Safety Standard, its organization, and key features. It will start with a brief discussion of some NASA mission failures and incidents that had software as one of their root causes. It will then give a brief overview of the NASA Software Safety Process. This will include an overview of the key personnel responsibilities and functions that must be performed for safety-critical software.

Ramsay, Christopher M.↗
NASA NTRS2001

Chandra Space Flight Software: Using Software to Autonomously Operation the Largest and Most Sensitive X-Ray Telescope in the World

Chandra is the world's largest and most sensitive X-ray telescope. The Chandra X-ray Observatory is the third in NASA's family of "Great Observatories." The Chandra X-ray Observatory, launched by Space Shuttle Columbia on July 23, 1999, is NASA's newest Great Observatory. The Chandra space flight software is the operational software, which controls and directs the Chandra X-ray Observatory. The Chandra flight software has executed faultlessly for over 13,000 hours on-orbit. The Chandra flight software directly controls the Pointing, Aspect Determination, Electrical Power Subsystem, Propulsion system, and the Command, Communications, and Data Management subsystems. The software controls the spacecraft operations during all phases of the mission. The software also performs thermal control of the telescope to maintain pointing accuracy and monitors radiation levels throughout the orbit so that the Science Instruments can be safed if radiation thresholds are exceeded. The efficient operation of Chandra flight software has enabled the gathering of crucial science data. The Chandra flight software fault protection is the key to early detection and prevention of science instrument or spacecraft damage in an operating platform/environment, which is completely unforgiving. Permanently open Sun Shade Door and ACIS focal plane radiator sensitivity exposes science instruments and mirrors to damage for pointing anomalies causing an attitude excursion. The Chandra flight software must prevent these attitude excursions from occurring for ANY failure. Another example is that the power system has an unregulated bus, which imposes severe operating requirements on Chandra flight software to control array pointing and battery connection/disconnect using a unique algorithmic and logic approach. The Chandra flight software has enabled a truly autonomous vehicle with greater than 99% of all mission data collected as planned. Less than 15% of spacecraft operations are conducted in view (1 hour out of 8) leading to very extended periods without ground contact. The Chandra flight software implements the flexible mission plan during this out of view period, manages the solid state recorder capacity, controls all pointing and maneuvers, provides fault detection for all satellite subsystems, and initiates communications with the ground at the appropriate time. This paper will describe the software architecture features, key design elements and software testing techniques that have facilitated Chandra's success.

Crumbley, Tim↗
NASA NTRS1993

Magellan spacecraft and memory state tracking: Lessons learned, future thoughts

Numerous studies have been dedicated to improving the two main elements of Spacecraft Mission Operations: Command and Telemetry. As a result, not much attention has been given to other tasks that can become tedious, repetitive, and error prone. One such task is Spacecraft and Memory State Tracking, the process by which the status of critical spacecraft components, parameters, and the contents of on-board memory are managed on the ground to maintain knowledge of spacecraft and memory states for future testing, anomaly investigation, and on-board memory reconstruction. The task of Spacecraft and Memory State Tracking has traditionally been a manual task allocated to Mission Operations Procedures. During nominal Mission Operations this job is tedious and error prone. Because the task is not complex and can be accomplished manually, the worth of a sophisticated software tool is often questioned. However, in the event of an anomaly which alters spacecraft components autonomously or a memory anomaly such as a corrupt memory or flight software error, an accurate ground image that can be reconstructed quickly is a priceless commodity. This study explores the process of Spacecraft and Memory State Tracking used by the Magellan Spacecraft Team highlighting its strengths as well as identifying lessons learned during the primary and extended missions, two memory anomalies, and other hardships encountered due to incomplete knowledge of spacecraft states. Ideas for future state tracking tools that require minimal user interaction and are integrated into the Ground Data System will also be discussed.

Bucher, Allen W.↗
NASA NTRS2005

An Expert System for Autonomous Spacecraft Control

The Autonomous Sciencecraft Experiment (ASE), part of the New Millennium Space Technology 6 Project, is flying onboard the Earth Orbiter 1 (EO-1) mission. The ASE software enables EO-1 to autonomously detect and respond to science events such as: volcanic activity, flooding, and water freeze/thaw. ASE uses classification algorithms to analyze imagery onboard to detect chang-e and science events. Detection of these events is then used to trigger follow-up imagery. Onboard mission planning software then develops a response plan that accounts for target visibility and operations constraints. This plan is then executed using a task execution system that can deal with run-time anomalies. In this paper we describe the autonomy flight software and how it enables a new paradigm of autonomous science and mission operations. We will also describe the current experiment status and future plans.

utonomy flight software↗
NASA NTRS1983

Power subsystem automation study

Generic power-system elements and their potential faults are identified. Automation functions and their resulting benefits are defined and automation functions between power subsystem, central spacecraft computer, and ground flight-support personnel are partitioned. All automation activities were categorized as data handling, monitoring, routine control, fault handling, planning and operations, or anomaly handling. Incorporation of all these classes of tasks, except for anomaly handling, in power subsystem hardware and software was concluded to be mandatory to meet the design and operational requirements of the space station. The key drivers are long mission lifetime, modular growth, high-performance flexibility, a need to accommodate different electrical user-load equipment, onorbit assembly/maintenance/servicing, and potentially large number of power subsystem components. A significant effort in algorithm development and validation is essential in meeting the 1987 technology readiness date for the space station.

Imamura, M. S.↗
NASA NTRS2009

Processing Ocean Images to Detect Large Drift Nets

A computer program processes the digitized outputs of a set of downward-looking video cameras aboard an aircraft flying over the ocean. The purpose served by this software is to facilitate the detection of large drift nets that have been lost, abandoned, or jettisoned. The development of this software and of the associated imaging hardware is part of a larger effort to develop means of detecting and removing large drift nets before they cause further environmental damage to the ocean and to shores on which they sometimes impinge. The software is capable of near-realtime processing of as many as three video feeds at a rate of 30 frames per second. After a user sets the parameters of an adjustable algorithm, the software analyzes each video stream, detects any anomaly, issues a command to point a high-resolution camera toward the location of the anomaly, and, once the camera has been so aimed, issues a command to trigger the camera shutter. The resulting high-resolution image is digitized, and the resulting data are automatically uploaded to the operator s computer for analysis.

Veenstra, Tim↗
NASA NTRS2006

Integrated System for Autonomous Science

The New Millennium Program Space Technology 6 Project Autonomous Sciencecraft software implements an integrated system for autonomous planning and execution of scientific, engineering, and spacecraft-coordination actions. A prior version of this software was reported in "The TechSat 21 Autonomous Sciencecraft Experiment" (NPO-30784), NASA Tech Briefs, Vol. 28, No. 3 (March 2004), page 33. This software is now in continuous use aboard the Earth Orbiter 1 (EO-1) spacecraft mission and is being adapted for use in the Mars Odyssey and Mars Exploration Rovers missions. This software enables EO-1 to detect and respond to such events of scientific interest as volcanic activity, flooding, and freezing and thawing of water. It uses classification algorithms to analyze imagery onboard to detect changes, including events of scientific interest. Detection of such events triggers acquisition of follow-up imagery. The mission-planning component of the software develops a response plan that accounts for visibility of targets and operational constraints. The plan is then executed under control by a task-execution component of the software that is capable of responding to anomalies.

Chien, Steve↗
NASA NTRS2012

Avoiding Human Error in Mission Operations: Cassini Flight Experience

Operating spacecraft is a never-ending challenge and the risk of human error is ever- present. Many missions have been significantly affected by human error on the part of ground controllers. The Cassini mission at Saturn has not been immune to human error, but Cassini operations engineers use tools and follow processes that find and correct most human errors before they reach the spacecraft. What is needed are skilled engineers with good technical knowledge, good interpersonal communications, quality ground software, regular peer reviews, up-to-date procedures, as well as careful attention to detail and the discipline to test and verify all commands that will be sent to the spacecraft. Two areas of special concern are changes to flight software and response to in-flight anomalies. The Cassini team has a lot of practical experience in all these areas and they have found that well-trained engineers with good tools who follow clear procedures can catch most errors before they get into command sequences to be sent to the spacecraft. Finally, having a robust and fault-tolerant spacecraft that allows ground controllers excellent visibility of its condition is the most important way to ensure human error does not compromise the mission.

guidance and control↗
NASA NTRSDate not supplied

Recovering from on-orbit anomalies on the Astrobee free flyers and its systems

During its use on the ISS, Astrobee and its systems have encountered multiple anomalies, which were either resolved remotely via software 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.

Astrobee ISS free-flyer↗
NASA NTRS2012

Enhanced Graphics for Extended Scale Range

Enhanced Graphics for Extended Scale Range is a computer program for rendering fly-through views of scene models that include visible objects differing in size by large orders of magnitude. An example would be a scene showing a person in a park at night with the moon, stars, and galaxies in the background sky. Prior graphical computer programs exhibit arithmetic and other anomalies when rendering scenes containing objects that differ enormously in scale and distance from the viewer. The present program dynamically repartitions distance scales of objects in a scene during rendering to eliminate almost all such anomalies in a way compatible with implementation in other software and in hardware accelerators. By assigning depth ranges correspond ing to rendering precision requirements, either automatically or under program control, this program spaces out object scales to match the precision requirements of the rendering arithmetic. This action includes an intelligent partition of the depth buffer ranges to avoid known anomalies from this source. The program is written in C++, using OpenGL, GLUT, and GLUI standard libraries, and nVidia GEForce Vertex Shader extensions. The program has been shown to work on several computers running UNIX and Windows operating systems.

Hanson, Andrew J.↗
NASA NTRS2012

Autonomous Cryogenic Load Operations: KSC Autonomous Test Engineer

The KSC Autonomous Test Engineer (KATE) program has a long history at KSC. Now a part of the Autonomous Cryogenic Load Operations (ACLO) mission, this software system has been sporadically developed over the past 20+ years. Originally designed to provide health and status monitoring for a simple water-based fluid system, it was proven to be a capable autonomous test engineer for determining sources of failure in. the system, As part.of a new goal to provide this same anomaly-detection capability for a complicated cryogenic fluid system, software engineers, physicists, interns and KATE experts are working to upgrade the software capabilities and graphical user interface. Much progress was made during this effort to improve KATE. A display ofthe entire cryogenic system's graph, with nodes for components and edges for their connections, was added to the KATE software. A searching functionality was added to the new graph display, so that users could easily center their screen on specific components. The GUI was also modified so that it displayed information relevant to the new project goals. In addition, work began on adding new pneumatic and electronic subsystems into the KATE knowledgebase, so that it could provide health and status monitoring for those systems. Finally, many fixes for bugs, memory leaks, and memory errors were implemented and the system was moved into a state in which it could be presented to stakeholders. Overall, the KATE system was improved and necessary additional features were added so that a presentation of the program and its functionality in the next few months would be a success.

Shrading, Nicholas J.↗