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 271 records · Page 15
All sourcesNASA NTRSDOE OSTI
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↗
NASA NTRS2008

The Analysis of Image Segmentation Hierarchies with a Graph-based Knowledge Discovery System

Currently available pixel-based analysis techniques do not effectively extract the information content from the increasingly available high spatial resolution remotely sensed imagery data. A general consensus is that object-based image analysis (OBIA) is required to effectively analyze this type of data. OBIA is usually a two-stage process; image segmentation followed by an analysis of the segmented objects. We are exploring an approach to OBIA in which hierarchical image segmentations provided by the Recursive Hierarchical Segmentation (RHSEG) software developed at NASA GSFC are analyzed by the Subdue graph-based knowledge discovery system developed by a team at Washington State University. In this paper we discuss out initial approach to representing the RHSEG-produced hierarchical image segmentations in a graphical form understandable by Subdue, and provide results on real and simulated data. We also discuss planned improvements designed to more effectively and completely convey the hierarchical segmentation information to Subdue and to improve processing efficiency.

Tilton, James C.↗
NASA NTRS2018

GOES-16 ABI Navigation Assessment

The US Geostationary Operational Environmental Satellite – R Series (GOES-R) was launched on November 19, 2016and was designated GOES-16 upon reaching geostationary orbit ten days later. After checkout and calibration, GOES-16 was relocated to its operational location of 75.2 degrees west and officially became GOES East on December 18, 2017. The Advanced Baseline Imager (ABI) is the primary instrument on the GOES-R series for imaging Earth's surface and atmosphere to significantly improve the detection and observation of severe environmental phenomena. A team supporting the GOES-R Flight Project at NASA's Goddard Space Flight Center developed algorithms and software for independent verification of ABI Image Navigation and Registration (INR), which became known as the INR Performance Assessment Tool Set (IPATS). In this paper, we will briefly describe IPATS on top concept level, and then introduce the Landsat chips, chip registration algorithms, and how IPATS measurements are filtered. We present GOES-16 navigation (NAV) errors from flight data from January 2017 to May 2018. The results show a) IPATS characterized INR variations throughout the post-launch test phase; and b) ABI INR has improved over time as post-launch tests were performed and corrections applied. Finally, we will describe how estimated NAV errors have been used to assess and understand satellite attitude anomalies and scale errors etc. This paper shows that IPATS is an effective tool for assessing and improving GOES-16 ABI INR and is also useful for INR long-term monitoring.

GOES-R↗
NASA NTRSDate not supplied

An Agile-Like Approach to Hardware Development: The Ejectable Data Recorder (EDR) for Orion's Ascent Abort 2 (AA-2) Test Flight

On July 2, 2019, the Ascent Abort 2 (AA-2) Flight Test Vehicle was launched from Cape Canaveral, with the goal of demonstrating the performance of Orion’s Launch Abort System (LAS) and collecting data from hundreds of sensors throughout the vehicle. The data collected during this test flight is of paramount importance, as it will be used to certify the Orion vehicle for human spaceflight. Originally, the data was to be downlinked via a single string network of antennas on the LAS, with the associated risk of potential data dropouts, as well as loss of data once the LAS was jettisoned. Thus, additional antennas were added onto the crew module (CM) to support data downlink post-LAS jettison, a buffer rebroadcast capability was added to fill in any gaps in data downlink transmissions, and an ejectable data recorder (EDR) subsystem was added to the CM as a redundant measure to collect all the instrumentation data. The EDR subsystem was added to the project about one year after the project commenced, which significantly reduced the available development time when compared with the other subsystems of the AA-2 Test Flight. The project was further accelerated by six months, around the critical design review gate. Due to the schedule compression challenge and the fact that the EDR subsystem was a backup system and not flight critical, the EDR subsystem was further challenged to find a new and more efficient way to develop hardware. Thus, the EDR subsystem experimented with different management and systems engineering processes, team sizes, communication methods, and tools. Some examples are novel uses of SharePoint as a Data-centric Project Management & Systems Engineering environment, a continuous testing approach through the lifecycle, and a Skunkworks approach to managing the team. The EDR subsystem blended Commercial Off The Shelf (COTS) hardware with in-house developed hardware and software to create a novel data retrieval capability. The capability evolved rapidly through a hardware in the loop simulation environment that enabled incremental component updates for not only the EDR subsystem but across the entire Crew Module. This paper will present an overview of how the EDR subsystem was managed and compare it to an Agile approach to managing projects. The paper will further provide a recommended approach to future Agile-like hardware development that incorporates lessons learned from the EDR experience.

Agile↗
NASA NTRS2010

Evaluating the Medical Kit System for the International Space Station(ISS) - A Paradigm Revisited

Medical capabilities aboard the International Space Station (ISS) have been packaged to help astronaut crew medical officers (CMO) mitigate both urgent and non-urgent medical issues during their 6-month expeditions. Two ISS crewmembers are designated as CMOs for each 3-crewmember mission and are typically not physicians. In addition, the ISS may have communication gaps of up to 45 minutes during each orbit, necessitating medical equipment that can be reliably operated autonomously during flight. The retirement of the space shuttle combined with ten years of manned ISS expeditions led the Space Medicine Division at the NASA Johnson Space Center to reassess the current ISS Medical Kit System. This reassessment led to the system being streamlined to meet future logistical considerations with current Russian space vehicles and future NASA/commercial space vehicle systems. Methods The JSC Space Medicine Division coordinated the development of requirements, fabrication of prototypes, and conducted usability testing for the new ISS Medical Kit System in concert with implementing updated versions of the ISS Medical Check List and associated in-flight software applications. The teams constructed a medical kit system with the flexibility for use on the ISS, and resupply on the Russian Progress space vehicle and future NASA/commercial space vehicles. Results Prototype systems were developed, reviewed, and tested for implementation. Completion of Preliminary and Critical Design Reviews resulted in a streamlined ISS Medical Kit System that is being used for training by ISS crews starting with Expedition 27 (June 2011). Conclusions The team will present the process for designing, developing, , implementing, and training with this new ISS Medical Kit System.

Hailey, Melinda J.↗
NASA NTRS1999

The Design of a Fault-Tolerant COTS-Based Bus Architecture

In this paper, we report our experiences and findings on the design of a fault-tolerant bus architecture comprised of two COTS buses, the IEEE 1394 and the 12C. This fault-tolerant bus is the backbone system bus for the avionics architecture of the X2000 program at the Jet Propulsion Laboratory. COTS buses are attractive because of the availability of low cost commercial products. However, they are not specifically designed for highly reliable applications such as long-life deep-space missions. The X2000 design team has devised a multi-level fault tolerance approach to compensate for this shortcoming of COTS buses. First, the approach enhances the fault tolerance capabilities of the IEEE 1394 and 12 C buses by adding a layer of fault handling hardware and software. Second, algorithms are developed to enable the IEEE 1394 and the 12 C buses assist each other to isolate and recovery from faults. Third, the set of IEEE 1394 and 12 C buses is duplicated to further enhance system reliability. The X2000 design team has paid special attention to guarantee that all fault tolerance provisions will not cause the bus design to deviate from the commercial standard specifications. Otherwise, the economic attractiveness of using COTS will be diminished. The hardware and software design of the X2000 fault-tolerant bus are being implemented and flight hardware will be delivered to the ST4 and Europa Orbiter missions.

Chau, Savio N.↗
NASA NTRSDate not supplied

Alternating Between Software Models and Real Hardware in the System Integration Lab for theIncremental Development of the Space Launch System Program Avionics

The MSFC System Integration Lab (SIL) supports avionics development of NASA’s Space Launch System—a new U.S. heavy-lift launch vehicle for NASA’s next generation of human space exploration beyond low-Earth orbit. The SIL facility allows for the incremental development of system components by either hosting real hardware in the loop and/or software models of those components. Through this functionality test teams are able to evaluate overall system performance as components are designed, built and modified. Early hardware/software integration and testing reduces risks and saves overall cost and schedule throughout a program/project life cycle. By performing early hardware/software integration, potential architecture and interface-related problems can be identified, and thus reduce associated risk as early in the design cycle as possible when problems are the least expensive to resolve while also improving the design and requirements. This presentation will illustrate the power of employing a hardware in the loop simulation system for the development of novel spacecraft avionics.

Space Launch System↗
NASA NTRS1981

IGDS/TRAP Interface Program (ITIP). Software User Manual (SUM)

This specification establishes the requirements, concepts, and preliminary design for a set of software known as the IGDS/TRAP Interface Program (ITIP). This software provides the capability to develop at an Interactive Graphics Design System (IGDS) design station process flow diagrams for use by the NASA Coal Gasification Task Team. In addition, ITIP will use the Data Management and Retrieval System (DMRS) to maintain a data base from which a properly formatted input file to the Time-Line and Resources Analysis Program (TRAP) can be extracted. This set of software will reside on the PDP-11/70 and will become the primary interface between the Coal Gasification Task Team and IGDS, DMRS, and TRAP. The user manual for the computer program is presented.

Jefferys, S.↗
NASA NTRSDate not supplied

Stochastic Verification by Analysis for Autonomous Systems Management Architecture (ASMA)

The Gateway Vehicle Systems Manager (VSM) is the top-level of a distributed, hierarchical software control system. VSM is data-driven and will make decisions related to mission, fault, resource management and vehicle control. These attributes combined with a high degree of autonomy make it susceptible to emergent behavior. In order to achieve the high level of confidence needed in this critical system, the VSM team has developed a multifaceted verification strategy employing traditional verification techniques, simulation, model checking, and runtime verification. Individual algorithms are verified using conventional testing and model checking using assume-guarantee contracts. A discrete event-based simulation approach is being developed to verify timelines. This presentation describes an enhancement to the verification approach using analysis to enhance system robustness by detecting and resolving the potential for emergent behavior. The verification by analysis employs a Software in the Loop (SITL) environment with real flight software executing on emulated processors, simulations of vehicle subsystems, flight dynamics, and human inputs. Since the possible input space and configuration data set are too large for exhaustive testing, a Monte Carlo approach is used to cover feasible scenarios, augmented with corner cases and known higher-risk scenarios. A key problem in using Monte Carlo-based system verification is evaluating test results to ensure that system behavior is correct. The presentation describes the approach the VSM team uses to monitor behavior for compliance with predetermined boundaries and to identify anomalous behavior for further analysis. This presentation describes the multi-level systems approach to verification, and the simulation-based layer that covers the feasible state space: 1. Overview of the Gateway VSM 2. Special challenges due to heterogeneous, hierarchical architecture 3. Modeling and simulation environment using flight software and system simulations 4. Developing input sets to ensure state-space coverage 5. Developing model and data configuration sets to ensure model coverage 6. Interpreting results without predetermined outcomes 7. Lessons learned and future work

Verification and Validation↗
NASA NTRSDate not supplied

Precipitation Science at NASA MSFC

The Precipitation Research Group in NASA MSFC’s Earth Science Branch (ST-11) focuses on observations of precipitation (rain, snow, and hail) from a variety of perspectives: ground-based radars, surface gauge networks, airborne instruments, and spaceborne measurements from onboard satellites. Current work includes identifying signatures of hail and strong thunderstorms from spaceborne measurements and assessing those signatures against multiple satellite datasets and ground-based radar observations. The Precipitation Team is also involved in the development and maintenance of NASA’s global-gridded multi-satellite precipitation product (IMERG) and operating and maintaining the GPM Validation Network (VN): a software package that geometrically matches the reference ground-based weather radar observations with GPM satellite observations in 3D. The team is also responsible for the Advanced Microwave Precipitation Radiometer (AMPR) used in airborne field campaign research, which recently was used to collect data on thunderstorms that produce terrestrial gamma-ray flashes (TGFs) in the Airborne Lightning Observatory for FEGS and TGFs (ALOFT) field campaign. While the Precipitation Group largely supports NASA’s Global Precipitation Measurement (GPM) mission and Precipitation Science Team, the team also looks to the future Precipitation Measurement Mission (PMM) and Investigation of Convective Updrafts (INCUS) missions.

Sarah D Bang↗
NASA NTRS1992

Artificial intelligence support for scientific model-building

Scientific model-building can be a time-intensive and painstaking process, often involving the development of large and complex computer programs. Despite the effort involved, scientific models cannot easily be distributed and shared with other scientists. In general, implemented scientific models are complex, idiosyncratic, and difficult for anyone but the original scientific development team to understand. We believe that artificial intelligence techniques can facilitate both the model-building and model-sharing process. In this paper, we overview our effort to build a scientific modeling software tool that aids the scientist in developing and using models. This tool includes an interactive intelligent graphical interface, a high-level domain specific modeling language, a library of physics equations and experimental datasets, and a suite of data display facilities.

Keller, Richard M.↗
NASA NTRS2008

Logistics Modeling for Lunar Exploration Systems

The extensive logistics required to support extended crewed operations in space make effective modeling of logistics requirements and deployment critical to predicting the behavior of human lunar exploration systems. This paper discusses the software that has been developed as part of the Campaign Manifest Analysis Tool in support of strategic analysis activities under the Constellation Architecture Team - Lunar. The described logistics module enables definition of logistics requirements across multiple surface locations and allows for the transfer of logistics between those locations. A key feature of the module is the loading algorithm that is used to efficiently load logistics by type into carriers and then onto landers. Attention is given to the capabilities and limitations of this loading algorithm, particularly with regard to surface transfers. These capabilities are described within the context of the object-oriented software implementation, with details provided on the applicability of using this approach to model other human exploration scenarios. Some challenges of incorporating probabilistics into this type of logistics analysis model are discussed at a high level.

Andraschko, Mark R.↗
NASA NTRS1994

Precision orbit determination for TOPEX/POSEIDON

The TOPEX/POSEIDON mission objective requires that the radial position of the spacecraft be determined with an accuracy better than 13 cm RMS (root mean square). This stringent requirement is an order of magnitude below the accuracy achieved for any altimeter mission prior to the definition of the TOPEX/POSEIDON mission. To satislfy this objective, the TOPEX Precision Orbit determination (POD) Team was established as a joint effort between the NASA Goddard Space Flight Center and the University of Texas at Austin, with collaboration from the University of Colorado and the Jet Propulsion Laboratory. During the prelaunch development and the post launch verification phases, the POD team improved, calibrated, and validated the precision orbit determination computer software systems. The accomplishments include (1) increased accuracy of the gravity and surface force models and (2) improved peformance of both laser ranging and Doppler tracking systems. The result of these efforts led to orbit accuracies for TOPEX/POSEIDON which are significantly better than the original mission requirement. Tests based on data fits, covariance analysis, and orbit comparisons indicate that the radial component of the TOPEX/POSEIDON spacecraft is determined, relative to the Earth's mass center, with an root mean square (RMS) error in the range of 3 to 4 cm RMS. This orbit accuracy, together with the near continuous dual-frequency altimetry from this mission, provides the means to determine the ocean's dynamic topography with an unprecedented accuracy.

Tapley, B. D.↗
NASA NTRS2003

Human Factors Engineering Requirements for the International Space Station - Successes and Challenges

Advanced technology coupled with the desire to explore space has resulted in increasingly longer human space missions. Indeed, any exploration mission outside of Earth's neighborhood, in other words, beyond the moon, will necessarily be several months or even years. The International Space Station (ISS) serves as an important advancement toward executing a successful human space mission that is longer than a standard trip around the world or to the moon. The ISS, which is a permanently occupied microgravity research facility orbiting the earth, will support missions four to six months in duration. In planning for the ISS, the NASA developed an agency-wide set of human factors standards for the first time in a space exploration program. The Man-Systems Integration Standard (MSIS), NASA-STD-3000, a multi-volume set of guidelines for human-centered design in microgravity, was developed with the cooperation of human factors experts from various NASA centers, industry, academia, and other government agencies. The ISS program formed a human factors team analogous to any major engineering subsystem. This team develops and maintains the human factors requirements regarding end-to-end architecture design and performance, hardware and software design requirements, and test and verification requirements. It is also responsible for providing program integration across all of the larger scale elements, smaller scale hardware, and international partners.

Whitmore, M.↗
NASA NTRS2001

Requirements, Verification, and Compliance (RVC) Database Tool

This paper describes the development, design, and implementation of the Requirements, Verification, and Compliance (RVC) database used on the International Space Welding Experiment (ISWE) project managed at Marshall Space Flight Center. The RVC is a systems engineer's tool for automating and managing the following information: requirements; requirements traceability; verification requirements; verification planning; verification success criteria; and compliance status. This information normally contained within documents (e.g. specifications, plans) is contained in an electronic database that allows the project team members to access, query, and status the requirements, verification, and compliance information from their individual desktop computers. Using commercial-off-the-shelf (COTS) database software that contains networking capabilities, the RVC was developed not only with cost savings in mind but primarily for the purpose of providing a more efficient and effective automated method of maintaining and distributing the systems engineering information. In addition, the RVC approach provides the systems engineer the capability to develop and tailor various reports containing the requirements, verification, and compliance information that meets the needs of the project team members. The automated approach of the RVC for capturing and distributing the information improves the productivity of the systems engineer by allowing that person to concentrate more on the job of developing good requirements and verification programs and not on the effort of being a "document developer".

Rainwater, Neil E., II↗
NASA NTRSDate not supplied

Streamlining GNC Architecture Development and FSW Integration forthe Mars Ascent Vehicle

The Mars Ascent Vehicle (MAV) will be the first vehicle to perform an ascent from the surface ofanother atmospheric planetary body outside of the Earth-Moon system. Significant light-time delayrequires complete autonomy of flight throughout ascent, and naturally a high level of reliability isdesired in both MAV’s hardware and software subsystems. The MAV Guidance, Navigation and Controls(GNC) team and the MAV Flight Software (FSW) team have partnered together to improve the efficiencyof algorithm integration onto the MAV flight processor, and to increase confidence that said integrationis successful and without human error. An interface architecture is proposed for the GNC suite thatallows both the guidance and navigation subsystems to provide code algorithms directly in C++, and thecontrols subsystem to provide MATLAB Simulink auto-coded algorithms. Several continuous integration/deployment (CI/CD) methodologies have been considered for ease of transition of algorithm code fromthe GNC team to the FSW team. The GNC/FSW teams also worked together to develop a cFS-friendlywrapper which abstracts the integration of the GNC algorithm code into an interface-level API that iscompatible with cFS. Several iterations of vehicle GNC code have been produced between the GNC/FSWteam’s partnership, and this strong interface between these two teams have allowed the GNC/FSWteams to greatly increase confidence of efficient and error-free implementation of the GNC code ontoMAV for a successful flight.

GNC↗
NASA NTRS2002

SIDS-toADF File Mapping Manual

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: 1) 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; 2) The Standard Interface Data Structures (SIDS), which specify the intellectual content of CFD data and the conventions governing naming and terminology; 3) 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 4) The CGNS Mid-level Library, which provides CFD-knowledgeable routines suitable for direct installation into application codes. The SIDS-toADF File Mapping Manual specifies the exact manner in which, under CGNS conventions, CFD data structures (the SIDS) are to be stored in (i.e., mapped onto) the file structure provided by the database manager (ADF). The result is a conforming CGNS database. Adherence to the mapping conventions guarantees uniform meaning and location of CFD data within ADF files, and thereby allows the construction of universal software to read and write the data.

McCarthy, Douglas↗