Search NASA⌕ Search

SEARCH · Search NASA

Results for “Team software development”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Clinical Decision Support For Exploration Space Flight: Software Augmentation To Enhance Progressively Earth-Independent Medical Operations

This panel identifies the challenges of supporting medical events in deep space using integrated systems software to augment existing capabilities during increasingly Earth-independent missions where an asynchronous communication environment becomes routine. An interdisciplinary team of software designers, physicians, human factors engineers, and computational modelers applied their respective expertise to develop a roadmap for supporting the crew making medical decisions in more autonomous fashion with time-delayed ground support. The first presentation describes predictive modeling implemented to assist medical system design and address risk reduction using robust clinical decision support software. The second presentation details how operational and environmental challenges guide assumptions and, in turn, by what means requirements for medical decision-making in deep space are derived. The third presentation describes and defines the skills and capabilities an exploration spaceflight medical officer will need to perform effectively during extended-duration spaceflight missions. The fourth presentation covers the potential models and function of the software element for supporting clinical decisions. The final presentation covers how these elements may work together with ground support to provide comprehensive care despite deep space travel's extreme challenges and limitations.

Dana Levin↗
NASA NTRSDate not supplied

Conducting Feasibility Studies in a Virtual World: Lessons Learned and Emerging Best Practices from the NASA DEVELOP Program

In response to new workplace realities, the NASA DEVELOP National Program pivoted from co-locating students, emerging professionals, and science advisors to bringing together virtual teams from across the United States. In its spring 2020 term, rapidly evolving circumstances required an ad-hoc roll-out of a virtual approach to complete the spring projects. Based on the experience from the spring term and a few weeks of planning, DEVELOP then conducted a fully virtual summer term with features such as 1) online collaboration tools, 2) virtual machines for analysis, and 3) streamed training offerings, including DEVELOP’s first ever program-wide Software Carpentry workshop. This full term of bringing together remote actors to select, build, and manage teams brought many challenges. Summer feedback has influenced planning for the fall 2020 term and process improvement is ongoing. This presentation will highlight lessons learned throughout this period of rapid change. Feedback from spring and summer terms and the Software Carpentry workshop will be summarized. Beyond participant impacts, there will also be discussion of effects on project results and partner experience. Final takeaways will focus on best practices that have been distilled for virtually-conducted feasibility studies.

NASA DEVELOP↗
NASA NTRS2018

Using the cFS Command and Data Dictionary (CCDD) to Automate Software Development on Habulous

Final paper is attached. The NASA developed Core Flight System (cFS) is a reusable software architecture that has been used on multiple spaceflight missions. By using this framework, missions are able to reuse code from other missions, as well as leverage deployment onto similar computer architectures (i.e. not "reinvent the wheel" on each new mission). The success in the cFS concept can be seen in the large number of projects using cFS at FSW-2018. The Habulous project is an Earth-based testbed, used for hardware and software that may one day be used on a future space habitat unit, with many participating groups from various NASA centers and aerospace organizations around the country. The distributed nature of the various teams mean that defining (and following) an interface definition is critical on the project. Additionally, since various groups use various types of computer hardware (32/64-bit, big/little endian, Linux/VxWorks/Windows) many additional complications exist in interfacing all the various components into a final integrated system. cFS is used on the majority the flight software (FSW) in running in Habulous. But some subsystems have elected to not use cFS, and use a software bridge (called SBN_lib) to interact with the other cFS nodes in Habulous. In order to most efficiently develop the FSW, a central database is used to define and store each message sent by cFS. A Command and Data Dictionary (CDD) is something nearly universal on spacecraft, but as a team we worked to develop the CDD before the SW development was complete, and not treat it like "as built" documentation. To manage the CDD, the cFS Command and Data Dictionary (CCDD) tool was chosen (available from NASA as open source software). The CCDD tool has successfully been used to automate/autocode a large amount of software used on Habulous, as we are hoping to use it to define even more items in the future (time-triggered Ethernet (TTE) network maps, CPU scheduling). Additionally, Habulous has been exploring the use of cFS on wildly heterogeneous CPUs, and how to coordinate all those various machines using/extending the software bus – network (SBN) application in cFS, as well as TTE to coordinate message passing between various synchronized machines. The major topics to be covered in the presentation are: (1) Updating to the CCSDS_v2 extended headers (and using CPU# as subsystem ID). (2) Managing all the message identification numbers for each cFS message sent/received on any of the various CPUs. (3) Using the CCDD information to automatically generate the C-header files that define the structure for all software bus (SB) commands/telemetry messages. (4) Using the CCDD to automatically generate XML Telemetry and Command Exchange (XTCE) files, which streams display production/integration/testing in a web based display architecture (5) Extending/customizing SBN to pass messages among computers on multiple networks. (6) Using "Protobetter" inside SBN to manage different endian-ness/architectures. (7) Using SBN_lib to allow non-cFS node to communicate with cFS nodes. (8) Developing TTE network and schedule tables for all the various CPUs to use.

Hirsh, Robert L.↗
NASA NTRS1986

NASA PC software evaluation project

The USL NASA PC software evaluation project is intended to provide a structured framework for facilitating the development of quality NASA PC software products. The project will assist NASA PC development staff to understand the characteristics and functions of NASA PC software products. Based on the results of the project teams' evaluations and recommendations, users can judge the reliability, usability, acceptability, maintainability and customizability of all the PC software products. The objective here is to provide initial, high-level specifications and guidelines for NASA PC software evaluation. The primary tasks to be addressed in this project are as follows: to gain a strong understanding of what software evaluation entails and how to organize a structured software evaluation process; to define a structured methodology for conducting the software evaluation process; to develop a set of PC software evaluation criteria and evaluation rating scales; and to conduct PC software evaluations in accordance with the identified methodology. Communication Packages, Network System Software, Graphics Support Software, Environment Management Software, General Utilities. This report represents one of the 72 attachment reports to the University of Southwestern Louisiana's Final Report on NASA Grant NGT-19-010-900. Accordingly, appropriate care should be taken in using this report out of context of the full Final Report.

Dominick, Wayne D.↗
NASA NTRS2006

Transforming Our SMEX Organization by Way of Innovation, Standardization, and Automation

NASA's Small Explorer (SMEX) Flight Operations Team (FOT) is currently tackling the challenge of supporting ground operations for several satellites that have surpassed their designed lifetime and have a dwindling budget. At Goddard Space Flight Center (GSFC), these missions are presently being reengineered into a fleet-oriented ground system. When complete, this ground system will provide command and control of four SMEX missions, and will demonstrate fleet automation and control concepts as a pathfinder for additional mission integrations. A goal of this reengineering effort is to demonstrate new ground-system technologies that show promise of supporting longer mission lifecycles and simplifying component integration. In pursuit of this goal, the SMEX organization has had to examine standardization, innovation, and automation. A core technology being demonstrated in this effort is the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC architecture focuses on providing standard interfaces for ground system applications to promote application interoperability. Building around commercial Message Oriented Middleware and providing a common messaging standard allows GMSEC to provide the capabilities necessary to support integration of new software components into existing missions and increase the level of interaction within the system. For SMS, GMSEC has become the technology platform to transform flight operations with the innovation and automation necessary to reduce operational costs. The automation technologies supported in SMEX are built upon capabilities provided by the GMSEC architecture that allows the FOT to further reduce the involvement of the console, operator. Initially, SMEX is automating only routine operations, such as safety and health monitoring, basic commanding, and system recovery. The operational concepts being developed here will reduce the need for staffed passes and are a necessity for future fleet management. As this project continues to evolve, additional innovations beyond GMSEC and automation have, and will continue to be developed. The team developed techniques for migrating ground systems of existing on-orbit assets. The tools necessary to monitor and control software failures were integrated and tailored for operational environments. All this was done with a focus of extending fleet operations to mission beyond SMU. The result of this work is the foundation for a broader fleet-capable ground system that will include several missions supported by the Space Science Mission Operations Project.

Madden, Maureen↗
NASA NTRS2019

Workforce for the Future Development of Space Access Vehicles

The development of advanced vehicles that will travel between planetary surfaces with atmospheres and space requires the availability of experimental and computational capabilities that accomplish the research leading to new technologies and the development, test, and evaluation (RDT&E) of new flight systems. The United States is at risk of not having the required RDT&E workforce – qualified and in sufficient numbers – in place and ready to meet the future market’s commercial and defense needs. Systemic challenges include uncertain Federal budgets that limit and interrupt government research and development, the projectized nature of new space access systems that drive boom/bust cycles, an aging aerospace workforce (compounded by a mid-age demographic gap), limited to declining investment in sustaining and advancing experimental and computational tools infrastructure, lack of standards for sharing (and leveraging) data, dramatically changing technologies, changing social norms, and potentially large increases in commercial market needs. Flight systems have mission-based trajectories to and from space and designers must ensure risk is properly assessed across the entire trajectory. Thus, physics questions must be answered at each stage of flight, which requires a suite of experimental and computational tools. The RDT&E workforce utilizing these tools include subject matter experts from the producers, interested in acquiring data and information on the product, and from the capabilities being utilized, interested in addressing the product customer’s needs (providing robust data collection techniques, data quality, timeliness – available when needed, efficient with cost management, and teaming on data analysis). This requires a range of skills – in addition to aerospace, other engineers, and software developers, a highly trained and certified craft and technician workforce is critical to future success. This paper will present a human resources construct that addresses the system of needs for people – including, but more than just technical skills and an application of that construct in the hypersonic Test and Evaluation (T&E) community. This is part of a larger AIAA effort to document challenges and associated best practices for the aerospace RDT&E workforce.

Steven C Dunn↗
NASA NTRS1993

DADiSP processing guide

A guide for DADiSP software, intended for use by the Lambda Point Experiment (LPE) Team during and after the United States Microgravity Payload (USMP)-1 mission, is presented. DADiSP is a Data Analysis and Display Software developed and marketed by DSP Development Corporation, Cambridge, Massachusetts. This guide is intended to be used in addition to the DADiSP Worksheet User Manual and Reference Manual which are supplied by the company with the software. Technical support for DADiSP is available from DSP at (617) 577-1133. Access to DADiSP on Acceleration Characterization and Analysis Project (ACAP) EGSE is being provided to the LPE team during USMP-1 for off-line processing of SAMS data.

Rogers, Melissa J. B.↗
NASA NTRS2004

The Development of Two Science Investigator-led Processing Systems (SIPS) for NASA's Earth Observation System (EOS)

In 2001, NASA Goddard Space Flight Center's Laboratory for Terrestrial Physics started the construction of a science Investigator-led Processing System (SIPS) for processing data from the Ozone Monitoring Instrument (OMI) which will launch on the Aura platform in mid 2004. The Ozone Monitoring Instrument (OMI) is a contribution of the Netherlands Agency for Aerospace Programs (NIVR) in collaboration with the Finnish Meteorological Institute (FMI) to the Earth Observing System (EOS) Aura mission. It will continue the Total Ozone Monitoring System (TOMS) record for total ozone and other atmospheric parameters related to ozone chemistry and climate. OMI measurements will be highly synergistic with the other instruments on the EOS Aura platform. The LTP previously developed the Moderate Resolution Imaging Spectrometer (MODIS) Data Processing System (MODAPS), which has been in full operations since the launches of the Terra and Aqua spacecrafts in December, 1999 and May, 2002 respectively. During that time, it has continually evolved to better support the needs of the MODIS team. We now run multiple instances of the system managing faster than real time reprocessings of the data as well as continuing forward processing. The new OMI Data Processing System (OMIDAPS) was adapted from the MODAPS. It will ingest raw data from the satellite ground station and process it to produce calibrated, geolocated higher level data products. These data products will be transmitted to the Goddard Distributed Active Archive Center (GDAAC) instance of the Earth Observing System (EOS) Data and Information System (EOSDIS) for long term archive and distribution to the public. The OMIDAPS will also provide data distribution to the OMI Science Team for quality assessment, algorithm improvement, calibration, etc. We have taken advantage of lessons learned from the MODIS experience and software already developed for MODIS. We made some changes in the hardware system organization, database and software to adapt the system for OMI. We replaced the fundamental database system, Sybase, with an Open Source RDBMS called PostgreSQL, and based the entire OMIDAPS on a cluster of Linux based commodity computers rather than the large SGI servers that MODAPS uses. Rather than relying on a central I/O server host, the new system distributes its data archive among multiple server hosts in the cluster. OMI is also customizing the graphical user interfaces and reporting structure to more closely meet the needs of the OMI Science Team. Prior to 2003, simulated OMI data and the science algorithms were not ready for production testing. We initially constructed a prototype system and tested using a 25 year dataset of Total Ozone Mapping Spectrometer (TOMS) and Solar Backscatter Ultraviolet Instrument (SBUV) data. This prototype system provided a platform to support the adaptation of the algorithms for OMI, and provided reprocessing of the historical data aiding in its analysis. In a recent reanalysis of the TOMS data, the OMIDAPS processed 108,000 full orbits of data through 4 processing steps per orbit, producing about 800,000 files (400 GiB) of level 2 and greater data files. More recently we have installed two instances of the OMIDAPS for integration and testing of OM1 science processes as they get delivered from the Science Team. A Test instance of the OMIDAPS has also supported a series of "Interface Confidence Tests" (ICTs) and End-to-End Ground System tests to ensure the launch readiness of the system. This paper will discuss the high-level hardware, software, and database organization of the OMIDAPS and how it builds on the MODAPS heritage system. It will also provide an overview of the testing and implementation of the production OMIDAPS.

Tilmes, Curt↗
NASA NTRS1992

A recent Cleanroom success story: The Redwing project

Redwing is the largest completed Cleanroom software engineering project in IBM, both in terms of lines of code and project staffing. The product provides a decision-support facility that utilizes artificial intelligence (AI) technology for predicting and preventing complex operating problems in an MVS environment. The project used the Cleanroom process for development and realized a defect rate of 2.6 errors/KLOC, measured from first execution. This represents the total amount of errors that were found in testing and installation at three field test sites. Development productivity was 486 LOC/PM, which included all development labor expended in design specification through completion of incremental testing. In short, the Redwing team produced a complex systems software product with an extraordinarily low error rate, while maintaining high productivity. All of this was accomplished by a project team using Cleanroom for the first time. An 'introductory implementation' of Cleanroom was defined and used on Redwing. This paper describes the quality and productivity results, the Redwing project, and how Cleanroom was implemented.

Hausler, Philip A.↗
NASA NTRS2002

Long Term Manipulations of Intact Microbial Mat Communities in a Greenhouse Collaboratory: Simulating Earth's Present and Past Field Environments

Photosynthetic microbial mat communities were obtained from marine hypersaline saltern ponds, maintained in a greenhouse facility, and examined for the effects of salinity variations. Because these microbial mats are considered to be useful analogs of equivalent ancient marine communities, they offer insights about evolutionary events during the greater than 3 billion year time interval wherein mats co-evolved with Earth's geosphere and atmosphere. Although photosynthetic mats can be highly dynamic and exhibit extremely high activity, the mats in the present study have been maintained for more than one year with relatively minor changes. The major groups of microorganisms, as assayed using microscopic, genetic, and biomarker methodologies, are essentially the same as those in the original field samples. Field and greenhouse mats were similar with respect to rates of exchange of oxygen and dissolved inorganic carbon across the mat-water interface, both during the day and at night. Field and greenhouse mats exhibited similar rates of efflux of methane and hydrogen. Manipulations of salinity in the water overlying the mats produced changes in the community that strongly resemble those observed in the field. A collaboratory testbed and an array of automated features are being developed to support remote scientific experimentation with the assistance of intelligent software agents. This facility will permit teams of investigators to explore ancient environmental conditions that are rare or absent today but might have influenced the early evolution of these photosynthetic ecosystems.

Bebout, Brad↗
NASA NTRS2022

Space ROS: Architecture Roadmap

Space ROS is a matured version of ROS 2 using flight software engineering practices to facilitate mission- and safety-critical applications. This roadmap was developed by the team to communicate the planned future evolution of Space ROS

Austin Probe↗
NASA NTRS1994

Generic trending and analysis system

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

Keehan, Lori↗
NASA NTRS1996

The shuttle main engine: A first look

Anyone entering the Space Shuttle Main Engine (SSME) team attends a two week course to become familiar with the design and workings of the engine. This course provides intensive coverage of the individual hardware items and their functions. Some individuals, particularly those involved with software maintenance and development, have felt overwhelmed by this volume of material and their lack of a logical framework in which to place it. To provide this logical framework, it was decided that a brief self-taught introduction to the overall operation of the SSME should be designed. To aid the people or new team members with an interest in the software, this new course should also explain the structure and functioning of the controller and its software. This paper presents a description of this presentation.

Schreur, Barbara↗
NASA NTRS2011

Implementation of Motion Simulation Software and Visual-Auditory Electronics for Use in a Low Gravity Robotic Testbed

The Jet Propulsion Laboratory (JPL) is developing the All-Terrain Hex-Limbed Extra-Terrestrial Explorer (ATHLETE) to assist in manned space missions. One of the proposed targets for this robotic vehicle is a near-Earth asteroid (NEA), which typically exhibit a surface gravity of only a few micro-g. In order to properly test ATHLETE in such an environment, the development team has constructed an inverted Stewart platform testbed that acts as a robotic motion simulator. This project focused on creating physical simulation software that is able to predict how ATHLETE will function on and around a NEA. The corresponding platform configurations are calculated and then passed to the testbed to control ATHLETE's motion. In addition, imitation attitude, imitation attitude control thrusters were designed and fabricated for use on ATHLETE. These utilize a combination of high power LEDs and audio amplifiers to provide visual and auditory cues that correspond to the physics simulation.

gravity↗
NASA NTRS1998

NASA Lewis' Telescience Support Center Supports Orbiting Microgravity Experiments

The Telescience Support Center (TSC) at the NASA Lewis Research Center was developed to enable Lewis-based science teams and principal investigators to monitor and control experimental and operational payloads onboard the International Space Station. The TSC is a remote operations hub that can interface with other remote facilities, such as universities and industrial laboratories. As a pathfinder for International Space Station telescience operations, the TSC has incrementally developed an operational capability by supporting space shuttle missions. The TSC has evolved into an environment where experimenters and scientists can control and monitor the health and status of their experiments in near real time. Remote operations (or telescience) allow local scientists and their experiment teams to minimize their travel and maintain a local complement of expertise for hardware and software troubleshooting and data analysis. The TSC was designed, developed, and is operated by Lewis' Engineering and Technical Services Directorate and its support contractors, Analex Corporation and White's Information System, Inc. It is managed by Lewis' Microgravity Science Division. The TSC provides operational support in conjunction with the NASA Marshall Space Flight Center and NASA Johnson Space Center. It enables its customers to command, receive, and view telemetry; monitor the science video from their on-orbit experiments; and communicate over mission-support voice loops. Data can be received and routed to experimenter-supplied ground support equipment and/or to the TSC data system for display. Video teleconferencing capability and other video sources, such as NASA TV, are also available. The TSC has a full complement of standard services to aid experimenters in telemetry operations.

Hawersaat, Bob W.↗
NASA NTRSDate not supplied

Advancements in Remote Ground Control Station Operator Pilot in Command Training Program for Beyond Visual Line of Sight Flight Operations

The training program for a Remote Ground Control Station Operator Pilot in Command (R-GCSO PIC) at NASA Langley Research Center marks a pivotal evolution in preparing operators for Beyond Visual Line of Sight (BVLOS) operations. This program, developed within the Advanced Air Mobility (AAM) project High Density Vertiplex (HDV) subproject, was crafted to bridge the gap between traditional Ground Control Station Operators (GCSO) and R-GCSO PICs, focusing on uncrewed aircraft systems (UAS). It encompassed extensive theoretical and practical training, including hands-on experience with advanced simulators and live flight operations, while ensuring a deep understanding of BVLOS complexities. The training leveraged NASA technologies like the MPATH (Measuring Performance for Autonomy Teaming with Humans) ground control station software and incorporated human factors principles to enhance operational readiness. This paper details the program's development, execution, and the critical insights gained, emphasizing the necessity of continuous adaptation in training methodologies to meet the evolving demands of UAS operations in the National Airspace System.

Ground control station operator↗
NASA NTRS1998

CGNS Mid-Level Software Library and Users Guide

The "CFD General Notation System" (CGNS) consists of a collection of conventions, and conforming software, for the storage and retrieval of Computational Fluid Dynamics (CFD) data. It facilitates the exchange of data between sites and applications, and helps stabilize the archiving of aerodynamic data. This effort was initiated in order to streamline the procedures in exchanging data and software between NASA and its customers, but the goal is to develop CGNS into a National Standard for the exchange of aerodynamic data. The CGNS development team is comprised of members from Boeing Commercial Airplane Group, NASA-Ames, NASA-Langley, NASA-Lewis, McDonnell-Douglas Corporation (now Boeing-St. Louis), Air Force-Wright Lab., and ICEM-CFD Engineering. The elements of CGNS address all activities associated with the storage of data on external media and its movement to and from application programs. These elements include: - The Advanced Data Format (ADF) Database manager, consisting of both a file format specification and its I/O software, which handles the actual reading and writing of data from and to external storage media; - The Standard Interface Data Structures (SIDS), which specify the intellectual content of CFD data and the conventions governing naming and terminology; - The SIDS-to-ADF File Mapping conventions, which specify the exact location where the CFD data defined by the SIDS is to be stored within the ADF file(s); and - The CGNS Mid-level Library, which provides CFD-knowledgeable routines suitable for direct installation into application codes. The CGNS Mid-level Library was designed to ease the implementation of CGNS by providing developers with a collection of handy I/O functions. Since knowledge of the ADF core is not required to use this library, it will greatly facilitate the task of interfacing with CGNS. There are currently 48 user callable functions that comprise the Mid-level library and are described in the Users Guide. The library is written in C, but each function has a FORTRAN counterpart.

Poirier, Diane↗
NASA NTRS2008

Challenges and Demands on Automated Software Revision

In the past three decades, automated program verification has undoubtedly been one of the most successful contributions of formal methods to software development. However, when verification of a program against a logical specification discovers bugs in the program, manual manipulation of the program is needed in order to repair it. Thus, in the face of existence of numerous unverified and un- certified legacy software in virtually any organization, tools that enable engineers to automatically verify and subsequently fix existing programs are highly desirable. In addition, since requirements of software systems often evolve during the software life cycle, the issue of incomplete specification has become a customary fact in many design and development teams. Thus, automated techniques that revise existing programs according to new specifications are of great assistance to designers, developers, and maintenance engineers. As a result, incorporating program synthesis techniques where an algorithm generates a program, that is correct-by-construction, seems to be a necessity. The notion of manual program repair described above turns out to be even more complex when programs are integrated with large collections of sensors and actuators in hostile physical environments in the so-called cyber-physical systems. When such systems are safety/mission- critical (e.g., in avionics systems), it is essential that the system reacts to physical events such as faults, delays, signals, attacks, etc, so that the system specification is not violated. In fact, since it is impossible to anticipate all possible such physical events at design time, it is highly desirable to have automated techniques that revise programs with respect to newly identified physical events according to the system specification.

Bonakdarpour, Borzoo↗