Search NASA⌕ Search

SEARCH · Search NASA

Results for “software development management”

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 451 records · Page 25
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

Window-Based Graphics For Scheduling

XOPPS computer program generates window-based graphics for scheduling and planning projects. Provides easy and fast on-screen "what-you-see-is-what-you-get" editing capabilities. Object-oriented, but unique in its capability for creating objects that have date attributes. Can be used in conjunction with project-management software. Written in C language for Sunseries workstations running SunOS. XOPPS was developed in 1992, based on the Sunview version of OPPS (NPO-18439) developed in 1990. It is copyrighted work with all copyright vested in NASA.

Mulnix, Cassie↗
NASA NTRS1994

The ground vehicle manager's associate

An overview of MAX, a software framework for manager's associate systems, is presented. MAX is used to develop and execute a problem-solving strategy for the task planning of semi-autonomous agents with the assistance of human performance. This paper describes the use of MAX in the supervisory management of robotic vehicles as they explore a planetary surface.

Edwards, Gary R.↗
NASA NTRS2007

Organization's Orderly Interest Exploration: Inception, Development and Insights of AIAA's Topics Database

Since 2003, AIAA's Computer Systems and Software Systems Technical Committees (TCs) have developed a database that aids technical committee management to map technical topics to their members. This Topics/Interest (T/I) database grew out of a collection of charts and spreadsheets maintained by the TCs. Since its inception, the tool has evolved into a multi-dimensional database whose dimensions include the importance, interest and expertise of TC members and whether or not a member and/or a TC is actively involved with the topic. In 2005, the database was expanded to include the TCs in AIAA s Information Systems Group and then expanded further to include all AIAA TCs. It was field tested at an AIAA Technical Activities Committee (TAC) Workshop in early 2006 through live access by over 80 users. Through the use of the topics database, TC and program committee (PC) members can accomplish relevant tasks such as: to identify topic experts (for Aerospace America articles or external contacts), to determine the interest of its members, to identify overlapping topics between diverse TCs and PCs, to guide new member drives and to reveal emerging topics. This paper will describe the origins, inception, initial development, field test and current version of the tool as well as elucidate the benefits and insights gained by using the database to aid the management of various TC functions. Suggestions will be provided to guide future development of the database for the purpose of providing dynamics and system level benefits to AIAA that currently do not exist in any technical organization.

Marshall, Jospeh R.↗
NASA NTRS2008

Virtual Satellite

Virtual Satellite (VirtualSat) is a computer program that creates an environment that facilitates the development, verification, and validation of flight software for a single spacecraft or for multiple spacecraft flying in formation. In this environment, enhanced functionality and autonomy of navigation, guidance, and control systems of a spacecraft are provided by a virtual satellite that is, a computational model that simulates the dynamic behavior of the spacecraft. Within this environment, it is possible to execute any associated software, the development of which could benefit from knowledge of, and possible interaction (typically, exchange of data) with, the virtual satellite. Examples of associated software include programs for simulating spacecraft power and thermal- management systems. This environment is independent of the flight hardware that will eventually host the flight software, making it possible to develop the software simultaneously with, or even before, the hardware is delivered. Optionally, by use of interfaces included in VirtualSat, hardware can be used instead of simulated. The flight software, coded in the C or C++ programming language, is compilable and loadable into VirtualSat without any special modifications. Thus, VirtualSat can serve as a relatively inexpensive software test-bed for development test, integration, and post-launch maintenance of spacecraft flight software.

Hammrs, Stephan R.↗
NASA NTRS2000

Space Shuttle Software Development and Certification

Man-rated software, "software which is in control of systems and environments upon which human life is critically dependent," must be highly reliable. The Space Shuttle Primary Avionics Software System is an excellent example of such a software system. Lessons learn from more than 20 years of effort have identified basic elements that must be present to achieve this high degree of reliability. The elements include rigorous application of appropriate software development processes, use of trusted tools to support those processes, quantitative process management, and defect elimination and prevention. This presentation highlights methods used within the Space Shuttle project and raises questions that must be addressed to provide similar success in a cost effective manner on future long-term projects where key application development tools are COTS rather than internally developed custom application development tools

Orr, James K.↗
NASA NTRS2011

Systems, methods and apparatus for developing and maintaining evolving systems with software product lines

Systems, methods and apparatus are provided through which an evolutionary system is managed and viewed as a software product line. In some embodiments, the core architecture is a relatively unchanging part of the system, and each version of the system is viewed as a product from the product line. Each software product is generated from the core architecture with some agent-based additions. The result may be a multi-agent system software product line.

Hinchey, Michael G.↗
NASA NTRS2021

Integrated Demand Management (IDM): Concept of Operations

NASA's Integrated Demand Management research activity developed a concept for a novel use of the FAA's Collaborative Trajectory Options Program (CTOP) decision support software to support airspace capacity-limited arrival operations involving Time Based Flow Management (TBFM). This document provides a detailed, graphical description of the concept.

IDM↗
NASA NTRS1983

Integration of Landsat data into the Saginaw River Basin geographic information system

One of the objectives of the Saginaw River Basin study is related to the development of a computer model to predict flood damages. The computer model is to be operational in June 1985. In order to achieve this objective, the input of land-use data into a data base consisting of 198,000 grid cells will be required. A planning technique using Spatial Analysis Methodology (SAM) was developed by the Corps of Engineers Hydrologic Engineering Center (HEC) to systematically handle these data. The HEC-SAM system uses the spatially oriented map data in a series of data management and analysis software programs for input to the Corps hydrologic and environmental models. Attention is given to data base development, Landsat digital data, the placement of the Landsat data into the grid cell data base, and the development of the land cover classification. The Landsat-2 MSS scene covering 85 percent of the Saginaw River Basin was geometrically corrected to a UTM coordinate system.

Mckim, H. L.↗
NASA NTRS1989

Knowledge-based control of an adaptive interface

The analysis, development strategy, and preliminary design for an intelligent, adaptive interface is reported. The design philosophy couples knowledge-based system technology with standard human factors approaches to interface development for computer workstations. An expert system has been designed to drive the interface for application software. The intelligent interface will be linked to application packages, one at a time, that are planned for multiple-application workstations aboard Space Station Freedom. Current requirements call for most Space Station activities to be conducted at the workstation consoles. One set of activities will consist of standard data management services (DMS). DMS software includes text processing, spreadsheets, data base management, etc. Text processing was selected for the first intelligent interface prototype because text-processing software can be developed initially as fully functional but limited with a small set of commands. The program's complexity then can be increased incrementally. The intelligent interface includes the operator's behavior and three types of instructions to the underlying application software are included in the rule base. A conventional expert-system inference engine searches the data base for antecedents to rules and sends the consequents of fired rules as commands to the underlying software. Plans for putting the expert system on top of a second application, a database management system, will be carried out following behavioral research on the first application. The intelligent interface design is suitable for use with ground-based workstations now common in government, industrial, and educational organizations.

Lachman, Roy↗
NASA NTRS1994

Changes and challenges in the Software Engineering Laboratory

Since 1976, the Software Engineering Laboratory (SEL) has been dedicated to understanding and improving the way in which one NASA organization, the Flight Dynamics Division (FDD), develops, maintains, and manages complex flight dynamics systems. The SEL is composed of three member organizations: NASA/GSFC, the University of Maryland, and Computer Sciences Corporation. During the past 18 years, the SEL's overall goal has remained the same: to improve the FDD's software products and processes in a measured manner. This requires that each development and maintenance effort be viewed, in part, as a SEL experiment which examines a specific technology or builds a model of interest for use on subsequent efforts. The SEL has undertaken many technology studies while developing operational support systems for numerous NASA spacecraft missions.

Pajerski, Rose↗
NASA NTRS1989

Space station dynamics, attitude control and momentum management

The Space Station Attitude Control System software test-bed provides a rigorous environment for the design, development and functional verification of GN and C algorithms and software. The approach taken for the simulation of the vehicle dynamics and environmental models using a computationally efficient algorithm is discussed. The simulation includes capabilities for docking/berthing dynamics, prescribed motion dynamics associated with the Mobile Remote Manipulator System (MRMS) and microgravity disturbances. The vehicle dynamics module interfaces with the test-bed through the central Communicator facility which is in turn driven by the Station Control Simulator (SCS) Executive. The Communicator addresses issues such as the interface between the discrete flight software and the continuous vehicle dynamics, and multi-programming aspects such as the complex flow of control in real-time programs. Combined with the flight software and redundancy management modules, the facility provides a flexible, user-oriented simulation platform.

Sunkel, John W.↗
NASA NTRS2007

Processing Satellite Imagery To Detect Waste Tire Piles

A methodology for processing commercially available satellite spectral imagery has been developed to enable identification and mapping of waste tire piles in California. The California Integrated Waste Management Board initiated the project and provided funding for the method s development. The methodology includes the use of a combination of previously commercially available image-processing and georeferencing software used to develop a model that specifically distinguishes between tire piles and other objects. The methodology reduces the time that must be spent to initially survey a region for tire sites, thereby increasing inspectors and managers time available for remediation of the sites. Remediation is needed because millions of used tires are discarded every year, waste tire piles pose fire hazards, and mosquitoes often breed in water trapped in tires. It should be possible to adapt the methodology to regions outside California by modifying some of the algorithms implemented in the software to account for geographic differences in spectral characteristics associated with terrain and climate. The task of identifying tire piles in satellite imagery is uniquely challenging because of their low reflectance levels: Tires tend to be spectrally confused with shadows and deep water, both of which reflect little light to satellite-borne imaging systems. In this methodology, the challenge is met, in part, by use of software that implements the Tire Identification from Reflectance (TIRe) model. The development of the TIRe model included incorporation of lessons learned in previous research on the detection and mapping of tire piles by use of manual/ visual and/or computational analysis of aerial and satellite imagery. The TIRe model is a computational model for identifying tire piles and discriminating between tire piles and other objects. The input to the TIRe model is the georeferenced but otherwise raw satellite spectral images of a geographic region to be surveyed. The TIRe model identifies the darkest objects in the images and, on the basis of spatial and spectral image characteristics, discriminates against other dark objects, which can include vegetation, some bodies of water, and dark soils. The TIRe model can identify piles of as few as 100 tires. The output of the TIRe model is a binary mask showing areas containing suspected tire piles and spectrally similar features. This mask is overlaid on the original satellite imagery and examined by a trained image analyst, who strives to further discriminate against non-tire objects that the TIRe model tentatively identified as tire piles. After the analyst has made adjustments, the mask is used to create a synoptic, geographically accurate tire-pile survey map, which can be overlaid with a road map and/or any other map or set of georeferenced data, according to a customer s preferences.

Skiles, Joseph↗
NASA NTRSDate not supplied

New Horizons for a Practical and Performance-Optimized Solar System Internet

The High-rate Delay Tolerant Networking (HDTN) project at the NASA Glenn Research Center (GRC) is developing a performance-optimized Delay Tolerant Networking (DTN) implementation using the Bundle Protocol (BP) both for infusion in modern, distributed spacecraft systems and for foundational network research purposes. While one purpose of networking is to enable a returns-to-scale with communicating assets, it is recognized that neither the protocol nor its implementations may impose a bottleneck on data delivery if expected to be implemented. With this in mind, this paper explores the current status of the HDTN software, including its capabilities and also various performance metrics at the bundle layer, the convergence layers (e.g. performance-optimized Licklider Transmission Protocol, or LTP), and bundle storage and retrieval. This includes goals of software implementations that support multi-gigabit per second communications regardless of payload size. A discussion on the current software architecture and internal scheduling and routing is included. Interoperability with such extant DTN implementations as Interplanetary Overlay Network (ION) and DTN Marshall Enterprise Implementation (DTNME) are included. The research goals of the project are also listed, including Software-Defined Networking (SDN) and the theory of DTNs. A table-based filtration system for the Bundle Protocol (BP), called BP Filter, is also explored: this addition enables table-based policies within the context of a DTN for management purposes. Infusion begins with systems testing in the Johnson Space Center (JSC) Software Development and Integration Laboratory (SDIL), which supports International Space Station (ISS) Flight Software development, integration, and verification. Observations made from the results of testing in the SDIL and in flight testing are also discussed, pointing to a path for infusion into high data return low-earth orbit (LEO) missions. The paper concludes with areas for future work.

Delay Tolerant Networking↗
NASA NTRS1998

The Associate Principal Astronomer for AI Management of Automatic Telescopes

This research program in scheduling and management of automatic telescopes had the following objectives: 1. To field test the 1993 Automatic Telescope Instruction Set (ATIS93) programming language, which was specifically developed to allow real-time control of an automatic telescope via an artificial intelligence scheduler running on a remote computer. 2. To develop and test the procedures for two-way communication between a telescope controller and remote scheduler via the Internet. 3. To test various concepts in Al scheduling being developed at NASA Ames Research Center on an automatic telescope operated by Tennessee State University at the Fairborn Observatory site in southern Arizona. and 4. To develop a prototype software package, dubbed the Associate Principal Astronomer, for the efficient scheduling and management of automatic telescopes.

Henry, Gregory W.↗
NASA NTRS1989

AdaNET Dynamic Software Inventory (DSI) prototype component acquisition plan

A component acquisition plan contains the information needed to evaluate, select, and acquire software and hardware components necessary for successful completion of the AdaNET Dynamic Software Inventory (DSI) Management System Prototype. This plan will evolve and be applicable to all phases of the DSI prototype development. Resources, budgets, schedules, and organizations related to component acquisition activities are provided. A purpose and description of a software or hardware component which is to be acquired are presented. Since this is a plan for acquisition of all components, this section is not applicable. The procurement activities and events conducted by the acquirer are described and who is responsible is identified, where the activity will be performed, and when the activities will occur for each planned procurement. Acquisition requirements describe the specific requirements and standards to be followed during component acquisition. The activities which will take place during component acquisition are described. A list of abbreviations and acronyms, and a glossary are contained.

Hanley, Lionel↗
NASA NTRS1976

Standardized development of computer software. Part 1: Methods

This work is a two-volume set on standards for modern software engineering methodology. This volume presents a tutorial and practical guide to the efficient development of reliable computer software, a unified and coordinated discipline for design, coding, testing, documentation, and project organization and management. The aim of the monograph is to provide formal disciplines for increasing the probability of securing software that is characterized by high degrees of initial correctness, readability, and maintainability, and to promote practices which aid in the consistent and orderly development of a total software system within schedule and budgetary constraints. These disciplines are set forth as a set of rules to be applied during software development to drastically reduce the time traditionally spent in debugging, to increase documentation quality, to foster understandability among those who must come in contact with it, and to facilitate operations and alterations of the program as requirements on the program environment change.

Tausworthe, R. C.↗
NASA NTRS2020

X-HAB 2020: AR Field Treks Summary and Conclusions

As part of the FY20 X-Hab Challenge, BLiSS sought to create an Augmented Reality (AR) toolkit to help with analog field trek operations under the supervision of the Solar System Exploration Research Virtual Institute (SSERVI). These treks are operational and technical demonstrations at space-like destinations on Earth to test current extra-vehicular activity (EVA) techniques. While BLiSS as an organization has experience studying operational tasks such as this, it has never developed AR software at this scale. For that reason, another team at the University was brought on to work in parallel. The Collaborative Lab for Advancing Work in Space (CLAWS) is a veteran group of the NASA Spacesuit User Interface Technologies for Students (SUITS) challenge in which Hololens displays for astronauts are created within a year. The operational and technological pairing was ideally suited for tackling this problem. The team divided its responsibilities so that BLiSS would handle the research required to shape the project. As this deliverable had an end user, it was decided that interviewing these field geologists and operations specialists would provide the best insight. These interviews paired with literature review would reveal niche applications for AR that remained within feasible bounds. These science-driven EVAs in unknown terrain require more flexible tools than the current generation of EVA assistants. Rather than focus on sequential instructions, there instead needs to be a broad toolkit that's only called upon in specific instances. This AR Toolkit for Lunar Astronauts and Scientists (ATLAS) became the development goal of the project: create a non-intrusive assembly of tools that could be accessed in AR on the field. The current ATLAS design makes use of a geospatially and temporally annotated eld note system called GeoNotes. This allows for data to be collected and coordinated in a way that's synchronized across time, space, and different users. A Mission Control Center (MCC) and Mobile Support Equipment (MSE) were all needed to transport the AR headset into the field with the user. A network infrastructure was designed and set up within the University to enable this functionality. The software is based on a Protocol-Module structure that allows for modular development of each capability. A Protocol Manager coordinates different protocols that make use of modules. Each module tackles a different individual task while the protocol puts each one to use. The protocol manager coordinates when these are called to be used. This software is hosted on a head-mounted display (HMD) with the MCC acting as support from afar. While the software would be unit-tested at each level and each hardware component verified, a final demonstration would serve to prove the system's capabilities: an analog field trek. The team would prepare to support a user in a remote location from the MCC back at the University. A local area near campus would be tested before going out to do sample field geology further away. This unfortunately became impossible with the arrival of COVID-19. Access to all of the facilities to complete the project as planned were shut down. Our team was scattered across the globe and forced to complete the rest virtually. Adjustments were made to produce a small virtual concept in Adobe XD in the meantime. Even digital surveys were created based on the NASA task-load index (TLX) originally intended for testing actual users. The goal shifted towards completing software and getting feedback on the user interfaces (UI) and user experiences (UX). This team has reformed in response to COVID and its focus has shifted to what can be done remotely. There is still an intention to finish the original deliverable described in this report. The work has been expanded beyond the original X-Hab challenge and has instead become its own research e ort to be continued afterwards. This report collects the processes and knowledge gained from a year of studying and working at this problem with two teams. It should preserve it for the time until the world returns to normal and work can resume. CLAWS will be taking over full responsibility from that point forward, eventually surpassing the original needs of the project. While this document captures the work done towards an eventual end, the CLAWS team has written their own proposal alongside it. It outlines a new future for ATLAS beyond X-Hab, BLiSS, and hopefully beyond COVID-19. This project began as a vague goal hoping to place a new technology into the unique setting of exploration science. The project has since comfortably taken root and will hopefully bloom over the next year.

Alex Sena↗
NASA NTRS2013

Software Tools to Support the Assessment of System Health

This presentation provides an overview of three software tools that were developed by the NASA Glenn Research Center to support the assessment of system health: the Propulsion Diagnostic Method Evaluation Strategy (ProDIMES), the Systematic Sensor Selection Strategy (S4), and the Extended Testability Analysis (ETA) tool. Originally developed to support specific NASA projects in aeronautics and space, these software tools are currently available to U.S. citizens through the NASA Glenn Software Catalog. The ProDiMES software tool was developed to support a uniform comparison of propulsion gas path diagnostic methods. Methods published in the open literature are typically applied to dissimilar platforms with different levels of complexity. They often address different diagnostic problems and use inconsistent metrics for evaluating performance. As a result, it is difficult to perform a one ]to ]one comparison of the various diagnostic methods. ProDIMES solves this problem by serving as a theme problem to aid in propulsion gas path diagnostic technology development and evaluation. The overall goal is to provide a tool that will serve as an industry standard, and will truly facilitate the development and evaluation of significant Engine Health Management (EHM) capabilities. ProDiMES has been developed under a collaborative project of The Technical Cooperation Program (TTCP) based on feedback provided by individuals within the aircraft engine health management community. The S4 software tool provides a framework that supports the optimal selection of sensors for health management assessments. S4 is structured to accommodate user ]defined applications, diagnostic systems, search techniques, and system requirements/constraints. One or more sensor suites that maximize this performance while meeting other user ]defined system requirements that are presumed to exist. S4 provides a systematic approach for evaluating combinations of sensors to determine the set or sets of sensors that optimally meet the performance goals and the constraints. It identifies optimal sensor suite solutions by utilizing a merit (i.e., cost) function with one of several available optimization approaches. As part of its analysis, S4 can expose fault conditions that are difficult to diagnose due to an incomplete diagnostic philosophy and/or a lack of sensors. S4 was originally developed and applied to liquid rocket engines. It was subsequently used to study the optimized selection of sensors for a simulation ]based aircraft engine diagnostic system. The ETA Tool is a software ]based analysis tool that augments the testability analysis and reporting capabilities of a commercial ]off ]the ]shelf (COTS) package. An initial diagnostic assessment is performed by the COTS software using a user ]developed, qualitative, directed ]graph model of the system being analyzed. The ETA Tool accesses system design information captured within the model and the associated testability analysis output to create a series of six reports for various system engineering needs. These reports are highlighted in the presentation. The ETA Tool was developed by NASA to support the verification of fault management requirements early in the Launch Vehicle process. Due to their early development during the design process, the TEAMS ]based diagnostic model and the ETA Tool were able to positively influence the system design by highlighting gaps in failure detection, fault isolation, and failure recovery.

Melcher, Kevin J.↗