SEARCH · Search NASA

Results for “software tasks”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

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

At least 253 records · Page 14

All sources NASA NTRS DOE OSTI

DOE OSTI2024

Mini Report: LLMs for Vulnerability Repair in Code

Software vulnerability repair is a notoriously difficult task that is both time consuming and labor intensive. While research into this area has a long history, the recent successes of large language models (LLMs) across many tasks have also spurred efforts to leverage LLM capabilities for automated software vulnerability repair. Currently, there are limitations in the capabilities of LLMs to fix bugs and insufficiently addressed problems in the evaluations of these studies may cause performance to not transfer when they are used in practice. Additionally, most research in the area treats finding and fixing bugs as separate concerns - how to best combine all the subtasks involved in removing vulnerabilities from code remains an open question. In this report, we summarize our findings and opinions on the current state of the art in LLM-assisted code vulnerability repair, highlighting current unresolved problems in the field as well as potential applications and future research.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2009

Software Health Management: A Short Review of Challenges and Existing Techniques

Modern spacecraft (as well as most other complex mechanisms like aircraft, automobiles, and chemical plants) rely more and more on software, to a point where software failures have caused severe accidents and loss of missions. Software failures during a manned mission can cause loss of life, so there are severe requirements to make the software as safe and reliable as possible. Typically, verification and validation (V&V) has the task of making sure that all software errors are found before the software is deployed and that it always conforms to the requirements. Experience, however, shows that this gold standard of error-free software cannot be reached in practice. Even if the software alone is free of glitches, its interoperation with the hardware (e.g., with sensors or actuators) can cause problems. Unexpected operational conditions or changes in the environment may ultimately cause a software system to fail. Is there a way to surmount this problem? In most modern aircraft and many automobiles, hardware such as central electrical, mechanical, and hydraulic components are monitored by IVHM (Integrated Vehicle Health Management) systems. These systems can recognize, isolate, and identify faults and failures, both those that already occurred as well as imminent ones. With the help of diagnostics and prognostics, appropriate mitigation strategies can be selected (replacement or repair, switch to redundant systems, etc.). In this short paper, we discuss some challenges and promising techniques for software health management (SWHM). In particular, we identify unique challenges for preventing software failure in systems which involve both software and hardware components. We then present our classifications of techniques related to SWHM. These classifications are performed based on dimensions of interest to both developers and users of the techniques, and hopefully provide a map for dealing with software faults and failures.

Pipatsrisawat, Knot↗

NASA NTRS2013

Memory-Efficient Onboard Rock Segmentation

Rockster-MER is an autonomous perception capability that was uploaded to the Mars Exploration Rover Opportunity in December 2009. This software provides the vision front end for a larger software system known as AEGIS (Autonomous Exploration for Gathering Increased Science), which was recently named 2011 NASA Software of the Year. As the first step in AEGIS, Rockster-MER analyzes an image captured by the rover, and detects and automatically identifies the boundary contours of rocks and regions of outcrop present in the scene. This initial segmentation step reduces the data volume from millions of pixels into hundreds (or fewer) of rock contours. Subsequent stages of AEGIS then prioritize the best rocks according to scientist- defined preferences and take high-resolution, follow-up observations. Rockster-MER has performed robustly from the outset on the Mars surface under challenging conditions. Rockster-MER is a specially adapted, embedded version of the original Rockster algorithm ("Rock Segmentation Through Edge Regrouping," (NPO- 44417) Software Tech Briefs, September 2008, p. 25). Although the new version performs the same basic task as the original code, the software has been (1) significantly upgraded to overcome the severe onboard re source limitations (CPU, memory, power, time) and (2) "bulletproofed" through code reviews and extensive testing and profiling to avoid the occurrence of faults. Because of the limited computational power of the RAD6000 flight processor on Opportunity (roughly two orders of magnitude slower than a modern workstation), the algorithm was heavily tuned to improve its speed. Several functional elements of the original algorithm were removed as a result of an extensive cost/benefit analysis conducted on a large set of archived rover images. The algorithm was also required to operate below a stringent 4MB high-water memory ceiling; hence, numerous tricks and strategies were introduced to reduce the memory footprint. Local filtering operations were re-coded to operate on horizontal data stripes across the image. Data types were reduced to smaller sizes where possible. Binary- valued intermediate results were squeezed into a more compact, one-bit-per-pixel representation through bit packing and bit manipulation macros. An estimated 16-fold reduction in memory footprint relative to the original Rockster algorithm was achieved. The resulting memory footprint is less than four times the base image size. Also, memory allocation calls were modified to draw from a static pool and consolidated to reduce memory management overhead and fragmentation. Rockster-MER has now been run onboard Opportunity numerous times as part of AEGIS with exceptional performance. Sample results are available on the AEGIS website at http://aegis.jpl.nasa.gov.

Burl, Michael C.↗

NASA NTRS1994

Transition From NASA Space Communication Systems to Commerical Communication Products

Transitioning from twenty-five years of space communication system architecting, engineering and development to creating and marketing of commercial communication system hardware and software products is no simple task for small, high-tech system engineering companies whose major source of revenue has been the U.S. Government. Yet, many small businesses are faced with this onerous and perplexing task. The purpose of this talk/paper is to present one small business (LinCom) approach to taking advantage of the systems engineering expertise and knowledge captured in physical neural networks and simulation software by supporting numerous National Aeronautics and Space Administration (NASA) and the Department of Defense (DoD) projects, e.g., Space Shuttle, TDRSS, Space Station, DCSC, Milstar, etc. The innovative ingredients needed for a systems house to transition to a wireless communication system products house that supports personal communication services and networks (PCS and PCN) development in a global economy will be discussed. Efficient methods for using past government sponsored space system research and development to transition to VLSI communication chip set products will be presented along with notions of how synergy between government and industry can be maintained to benefit both parties.

Ghazvinian, Farzad↗

NASA NTRS2004

Software Quality Assurance Metrics

Software Quality Assurance (SQA) is a planned and systematic set of activities that ensures conformance of software life cycle processes and products conform to requirements, standards and procedures. In software development, software quality means meeting requirements and a degree of excellence and refinement of a project or product. Software Quality is a set of attributes of a software product by which its quality is described and evaluated. The set of attributes includes functionality, reliability, usability, efficiency, maintainability, and portability. Software Metrics help us understand the technical process that is used to develop a product. The process is measured to improve it and the product is measured to increase quality throughout the life cycle of software. Software Metrics are measurements of the quality of software. Software is measured to indicate the quality of the product, to assess the productivity of the people who produce the product, to assess the benefits derived from new software engineering methods and tools, to form a baseline for estimation, and to help justify requests for new tools or additional training. Any part of the software development can be measured. If Software Metrics are implemented in software development, it can save time, money, and allow the organization to identify the caused of defects which have the greatest effect on software development. The summer of 2004, I worked with Cynthia Calhoun and Frank Robinson in the Software Assurance/Risk Management department. My task was to research and collect, compile, and analyze SQA Metrics that have been used in other projects that are not currently being used by the SA team and report them to the Software Assurance team to see if any metrics can be implemented in their software assurance life cycle process.

McRae, Kalindra A.↗

NASA NTRS1992

Repository-based software engineering program

The activities performed during September 1992 in support of Tasks 01 and 02 of the Repository-Based Software Engineering Program are outlined. The recommendations and implementation strategy defined at the September 9-10 meeting of the Reuse Acquisition Action Team (RAAT) are attached along with the viewgraphs and reference information presented at the Institute for Defense Analyses brief on legal and patent issues related to software reuse.

Wilson, James↗

NASA NTRS1975

Apollo experience report: Engineering and analysis mission support

The tasks performed by the team of specialists that evaluated hardware performance during prelaunch checkout and in-flight operation are discussed. The organizational structure, operational procedures, and interfaces as well as the facilities and software required to perform these tasks are discussed. The scope of the service performed by the team and the evaluation philosophy are described. Summaries of problems and their resolution are included as appendixes.

Fricke, R. W., Jr.↗

DOE OSTI2024

RadSim: Particle Transport Wrapper

RadSim is being developed to provide the capability to simulate radiation source emissions, interpolate results from radiation transport tools into a common format to prepare incident flux, and model radiation detector response. This software package includes wrapper API code which is utilized in the development of the second (transport) task of the RadSim project. This software package only contains tools to interface RadSim with radiation transport tools (GEANT4 and MCNP) and does not include any part of the transport source code itself. The users will need prior access to the transport tools (GEANT4 and MCNP), and can use this software package to interface with the transport tool of their choice. This software package takes the geometry file for a radiation transport problem and converts it into an input deck for the transport tools (GEANT4 and MCNP). Additionally, it also contains filters that convert the output of the transport tools to a common flux format.

Cheung, Hoi Sing↗

NASA NTRS1990

Automatic programming of simulation models

The concepts of software engineering were used to improve the simulation modeling environment. Emphasis was placed on the application of an element of rapid prototyping, or automatic programming, to assist the modeler define the problem specification. Then, once the problem specification has been defined, an automatic code generator is used to write the simulation code. The following two domains were selected for evaluating the concepts of software engineering for discrete event simulation: manufacturing domain and a spacecraft countdown network sequence. The specific tasks were to: (1) define the software requirements for a graphical user interface to the Automatic Manufacturing Programming System (AMPS) system; (2) develop a graphical user interface for AMPS; and (3) compare the AMPS graphical interface with the AMPS interactive user interface.

Schroer, Bernard J.↗

NASA NTRS2007

Assurance of Complex Electronics. What Path Do We Take?

Many of the methods used to develop software bare a close resemblance to Complex Electronics (CE) development. CE are now programmed to perform tasks that were previously handled in software, such as communication protocols. For instance, Field Programmable Gate Arrays (FPGAs) can have over a million logic gates while system-on-chip (SOC) devices can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of "software-like" bugs such as incorrect design, logic, and unexpected interactions within the logic is great. Since CE devices are obscuring the hardware/software boundary, we propose that mature software methodologies may be utilized with slight modifications to develop these devices. By using standardized S/W Engineering methods such as checklists, missing requirements and "bugs" can be detected earlier in the development cycle, thus creating a development process for CE that will be easily maintained and configurable based on the device used.

FROM↗

NASA NTRS2007

Filling the Assurance Gap on Complex Electronics

Many of the methods used to develop software bare a close resemblance to Complex Electronics (CE) development. CE are now programmed to perform tasks that were previously handled by software, such as communication protocols. For example, the James Webb Space Telescope will use Field Programmable Gate Arrays (FPGAs), which can have over a million logic gates, to send telemetry. System-on-chip (SoC) devices, another type of complex electronics, can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of software-like bugs such as incorrect design, logic, and unexpected interactions within the logic is great. Since CE devices are obscuring the hardware/software boundary, mature software methodologies have been proposed, with slight modifications, to develop these devices. By using standardized S/W Engineering methods such as checklists, missing requirements and bugs can be detected earlier in the development cycle, thus creating a development process for CE that can be easily maintained and configurable based on the device used.

Plastow, Richard A.↗

NASA NTRSDate not supplied

Crew Autonomy through Self-Scheduling: Scheduling Performance Pilot Study

Within the domain of human spaceflight, crew scheduling for International Space Station (ISS) remains a human-driven planning task. Large teams of flight controllers (called Ops Planners) spend weeks creating violation-free schedules for all crewmembers. As NASA considers long-duration exploration missions, the necessary shift of scheduling and planning management from Ops Planners to crew members requires significant research and investigation of crew performance to complete these scheduling tasks. This pilot study was conducted to evaluate non-expert human performance for the task of planning and scheduling, focusing on scheduling problems that increased in complexity based on the number of activities to be scheduled and the number of planning constraints. Nine non-expert planners were recruited to complete scheduling tasks using Playbook, a scheduling software. The results of this pilot study show that scheduling performance decreased as scheduling workload (i.e. number of activities and percent of activities with planning constraints) increased. This paper provides evidence towards developing a model for scheduling task difficulty and identifies potential implications for future automated aids for flight crew scheduling.

planning↗

NASA NTRSDate not supplied

Crew Autonomy Through Self-Scheduling: Scheduling Performance Pilot Study

planning↗

NASA NTRS1988

The Environment for Application Software Integration and Execution (EASIE) version 1.0. Volume 4: System installation and maintenance guide

The Environment for Application Software Integration and Execution (EASIE) provides both a methodology and a set of software utility programs to ease the task of coordinating engineering design and analysis codes. This document provides necessary information for installing the EASIE software on a host computer system. The target host is a DEX VAX running VMS version 4; host dependencies are noted when appropriate. Relevant directories and individual files are identified, and compile/load/execute sequences are specified. In the case of the data management utilities, database management system (DBMS) specific features are described in an effort to assist the maintenance programmer in converting to a new DBMS. The document also describes a sample EASIE program directory structure to guide the program implementer in establishing his/her application dependent environment.

Randall, Donald P.↗

DOE OSTI2021

Neuromorphic Computing for Autonomous Racing

Neuromorphic computing has many opportunities in future autonomous systems, especially those that will operate at the edge. However, there are relatively few demonstrations of neuromorphic implementations on real-world applications, partly because of the lack of availability of neuromorphic hardware and software, but also because of the lack of availability of an accessible demonstration platform. In this work, we propose utilizing the F1Tenth platform as an evaluation task for neuromorphic computing. F1Tenth is a competition wherein one tenth scale cars compete in an autonomous racing task; there are significant open source resources in both software and hardware for realizing this task. We present a workflow with neuromorphic hardware, software, and training that can be used to develop a spiking neural network for neuromorphic hardware deployment to perform autonomous racing. We present initial results on utilizing this approach for this small-scale, real-world autonomous vehicle task.

Patton, Robert↗

NASA NTRS1983

Development of land based radar polarimeter processor system

The processing subsystem of a land based radar polarimeter was designed and constructed. This subsystem is labeled the remote data acquisition and distribution system (RDADS). The radar polarimeter, an experimental remote sensor, incorporates the RDADS to control all operations of the sensor. The RDADS uses industrial standard components including an 8-bit microprocessor based single board computer, analog input/output boards, a dynamic random access memory board, and power supplis. A high-speed digital electronics board was specially designed and constructed to control range-gating for the radar. A complete system of software programs was developed to operate the RDADS. The software uses a powerful real time, multi-tasking, executive package as an operating system. The hardware and software used in the RDADS are detailed. Future system improvements are recommended.

Kronke, C. W.↗

NASA NTRS1981

Deep space network software cost estimation model

A parametric software cost estimation model prepared for Deep Space Network (DSN) Data Systems implementation tasks is presented. The resource estimation model incorporates principles and data from a number of existing models. The model calibrates task magnitude and difficulty, development environment, and software technology effects through prompted responses to a set of approximately 50 questions. Parameters in the model are adjusted to fit DSN software life cycle statistics. The estimation model output scales a standard DSN Work Breakdown Structure skeleton, which is then input into a PERT/CPM system, producing a detailed schedule and resource budget for the project being planned.

Tausworthe, R. C.↗

NASA NTRS1992

System for Anomaly and Failure Detection (SAFD) system development

This task specified developing the hardware and software necessary to implement the System for Anomaly and Failure Detection (SAFD) algorithm, developed under Technology Test Bed (TTB) Task 21, on the TTB engine stand. This effort involved building two units; one unit to be installed in the Block II Space Shuttle Main Engine (SSME) Hardware Simulation Lab (HSL) at Marshall Space Flight Center (MSFC), and one unit to be installed at the TTB engine stand. Rocketdyne personnel from the HSL performed the task. The SAFD algorithm was developed as an improvement over the current redline system used in the Space Shuttle Main Engine Controller (SSMEC). Simulation tests and execution against previous hot fire tests demonstrated that the SAFD algorithm can detect engine failure as much as tens of seconds before the redline system recognized the failure. Although the current algorithm only operates during steady state conditions (engine not throttling), work is underway to expand the algorithm to work during transient condition.

Oreilly, D.↗