Results for “background software” — Page 17

NASA NTRS2012

Recovering Swift-XRT Energy Resolution through CCD Charge Trap Mapping

The X-ray telescope on board the Swift satellite for gamma-ray burst astronomy has been exposed to the radiation of the space environment since launch in November 2004. Radiation causes damage to the detector, with the generation of dark current and charge trapping sites that result in the degradation of the spectral resolution and an increase of the instrumental background. The Swift team has a dedicated calibration program with the goal of recovering a significant proportion of the lost spectroscopic performance. Calibration observations of supernova remnants with strong emission lines are analysed to map the detector charge traps and to derive position-dependent corrections to the measured photon energies. We have achieved a substantial recovery in the XRT resolution by implementing these corrections in an updated version of the Swift XRT gain file and in corresponding improvements to the Swift XRT HEAsoft software. We provide illustrations of the impact of the enhanced energy resolution, and show that we have recovered most of the spectral resolution lost since launch

Pagani, C.↗

NASA NTRSDate not supplied

Adding a Verification View for Autonomous Real-Time Architecture

Spacecraft software systems continue to increase in complexity and must frequently operate autonomously for extended periods. Thus, the consequences of software flaws are increasing and it is necessary to improve development methods to minimize the risk of latent flaws in the operational software. Traditional software architectures place verification as one element in the development architectural view and treat verification as a later lifecycle activity that is considered complete when the system is certified for flight. The Gateway Vehicle System Manager team, recognizing the importance of verification throughout the system lifecycle, is treating verification as an additional architectural view that receives continuous attention from the requirements analysis phase and continuing for the life of the operational system. The verification view consists of two viewpoints: development and operational. We present background on the verification view and discuss the approaches the Vehicle System Manager team is taking.

James B Dabney↗

NASA NTRSDate not supplied

An Intern Experience with NASA’s Artemis Program

“3...2...1...Go For Launch”. Nasa’s Kennedy Space Center is projected to launch the first mission of theArtemis Program by the end of this year, 2021. I have had the opportunity to contribute directly to this mission through my internship with their Engineering organization from January to August of 2021.Within their Engineering organization, I am an intern for the Avionics branch. Throughout this experience I have completed two projects with one project still in progress. These projects allowed me to work directly with the Orion vehicle’s software and hardware power ups, checkouts, and tests. I became familiarized with the engineering concepts that allowed this advanced technology to perform as intended.In addition, I became acquainted with the operations and tasks that are completed during a LaunchCountdown, both at a detailed level as well as a higher managerial level. Lastly, I worked directly with the software algorithm that detects and responds to onboard faults and failures. I have analyzed and made conclusions based on data and documentation, allowing my team to benefit from a condensed, centralized informational file. In addition to my technical experience, I have learned a significant amount about how the Kennedy Space Center operates, it’s history, and the history of the agency. The education I received from the Engineering department at Texas A&M University not only allowed me to obtain this internship, but provided me with the required background in computer and electrical engineering principles to be successful in this organization.

Sarah Bianco↗

NASA NTRS1992

The EXOSAT database and archive

The EXOSAT database provides on-line access to the results and data products (spectra, images, and lightcurves) from the EXOSAT mission as well as access to data and logs from a number of other missions (such as EINSTEIN, COS-B, ROSAT, and IRAS). In addition, a number of familiar optical, infrared, and x ray catalogs, including the Hubble Space Telescope (HST) guide star catalog are available. The complete database is located at the EXOSAT observatory at ESTEC in the Netherlands and is accessible remotely via a captive account. The database management system was specifically developed to efficiently access the database and to allow the user to perform statistical studies on large samples of astronomical objects as well as to retrieve scientific and bibliographic information on single sources. The system was designed to be mission independent and includes timing, image processing, and spectral analysis packages as well as software to allow the easy transfer of analysis results and products to the user's own institute. The archive at ESTEC comprises a subset of the EXOSAT observations, stored on magnetic tape. Observations of particular interest were copied in compressed format to an optical jukebox, allowing users to retrieve and analyze selected raw data entirely from their terminals. Such analysis may be necessary if the user's needs are not accommodated by the products contained in the database (in terms of time resolution, spectral range, and the finesse of the background subtraction, for instance). Long-term archiving of the full final observation data is taking place at ESRIN in Italy as part of the ESIS program, again using optical media, and ESRIN have now assumed responsibility for distributing the data to the community. Tests showed that raw observational data (typically several tens of megabytes for a single target) can be transferred via the existing networks in reasonable time.

Reynolds, A. P.↗

NASA NTRS2004

Comparison of Two Digital Stethoscopes with the Traditional Stethoscope Used on International Space Station

A traditional stethoscope is currently flown on the International Space Station (ISS). The background noise on the ISS is much higher than a normal exam room, and the literature shows that traditional stethoscopes are unable to function effectively in high noise environments. Digital stethoscopes provide amplification which improves the audibility in a quiet environment. This study is designed to determine if digital stethoscopes offer any advantage over traditional stethoscopes in being able to identify normal and abnormal sounds in the ISS noise environment. Methods: An ISS noise simulation facility was created to reproduce ISS noise profiles by modifying pink noise with a software-based graphic equalizer. The files were played in a continuous loop on a computer, amplified through a high-end stereo system and adjusted using a sound level meter. Nine caregiver analogues were given the same auscultation lesson received by astronauts. They began testing by becoming familiar with normal and abnormal sounds on a Student Auscultation Manikin . They then used two digital stethoscopes and a traditional stethoscope identical to the one flown on the ISS to auscultate the manikin sounds in the noise facility. They identified the sounds on a questionnaire and picked which of the three stethoscopes they preferred. Results: Evaluators displayed equivalent accuracy in sound identification when using either the 3M model 4000 digital stethoscope or traditional stethoscope. However, the 3M was preferred 2 to 1 by the evaluators, primarily because of additional amplification of the sounds. Discussion: Although our results show that the current ISS stethoscope and the "best-of-breed" digital stethoscope provide essentially the same auscultation utility, the latter has the advantage of recording and transmitting sounds to a remote physician. Since the astronaut caregivers are non-physiCians, this capability may be worth the additional expense and effort needed to certify the digital stethoscope for flight.

Rasbury, Jack↗

NASA NTRSDate not supplied

Comparison of Artemis 2 and Artemis 5 Model Outcomes Using the Impact Probabilistic Risk Assessment Tool

BACKGROUND The Artemis campaign is a Moon exploration program with a series of six planned missions, five of which will be crewed. These five crewed missions will contain a single mission segment (space flight), or multiple mission segments involving space flight (Orion), lunar landing (LTV) and/or space habitat (Gateway). Each crewed segment faces the risk of unique medical conditions, necessitating medical sets/kits tailored to those specificities. To support and enable a data-driven and evidence-based decision-making process through out a mission’s life cycle, a software tool called IMPACT was developed. Using probabilistic risk assessment (PRA) methodologies, IMPACT (Informing Mission Planning via Analysis of Complex Tradespaces) is a novel tool built for analyzing the possibility of encountering complex medical risks during space flight, and for identifying the medical resources and capabilities needed to treat those potential at-risk medical conditions. This presentation will seek to compare IMPACT’s computational results upon potential complex space medical conditions (e.g., sprain/strain back or sleep disturbance) using IMPACT’s risk metrics and the associated optimized medical sets/kits between two Artemis missions: single segment Artemis 2 and multi-segmented Artemis 5. OVERVIEW By identifying potential medical conditions in space using input criteria such as crew quantity and composition, certain crew physical characteristics, mission duration and mission activities, IMPACT can produce analyses on the type of medical resources and capabilities needed to produce an optimized medical set/kit to address those medical conditions. IMPACT achieves this by performing hundreds of thousands of Monte Carlo simulations of missions to build aggregate pictures of medical risk. IMPACT’s risk metrics include loss of crew life (LOCL) – a measure of crew mortality due to medical conditions in space, return to definitive care (RTDC) – the need to perform crew evacuation, and task time lost (TTL) – a measure of the inability to perform activities due to crew disability. These risk metrics are applied to every medical condition identified by IMPACT’s computation analyses for every segment of the mission. Medical sets/kits are optimized to address these medical conditions but must fit within the stated Artemis Design Reference Mission (DRM) request for mass and volume physical size constraints. ANTICIPATED ANALYSIS AND CONCLUSION Using two Artemis missions, Artemis 2 and Artemis 5, IMPACT will provide the analyses for comparison of medical set/kit contents based upon mass and/or volume requirements and identify the at-risk medical conditions within both missions. This paper serves as an initial exploration of probabilistic risk assessment (PRA) medical risk calculations between two crewed Artemis missions and is not intended to be deemed the official medical response for the Artemis campaign.

probabilistic risk assessment↗

NASA NTRSDate not supplied

In-Depth Modeling and Simulation Analysis of Artemis Missions Using the Impact Probabilistic Risk Assessment Tool

BACKGROUND The Artemis campaign is a Moon exploration program with a series of six planned missions, five of which will be crewed. These five crewed missions will contain a single mission segment (space flight), or multiple mission segments involving space flight (Orion), lunar landing (LTV) and/or space habitat (Gateway). Each crewed segment faces the risk of unique medical conditions, necessitating medical sets/kits tailored to those specificities. To support and enable a data-driven and evidence-based decision-making process through out a mission’s life cycle, a software tool called IMPACT was developed. Using probabilistic risk assessment (PRA) methodologies, IMPACT (Informing Mission Planning via Analysis of Complex Tradespaces) is a novel tool built for analyzing the possibility of encountering complex medical risks during space flight, and for identifying the medical resources and capabilities needed to treat those potential at-risk medical conditions. IMPACT achieves this by performing hundreds of thousands of Monte Carlo simulations of missions to build aggregate pictures of medical risk. During an extended simulation modeling phase, IMPACT generated analytical results for medical risks, and the medical resources and capabilities to address those risks, for every segment of every crewed Artemis mission. This presentation will highlight the reliability, consistency and validity of IMPACT’s computational modeling techniques and will showcase the library of analytical outcomes generated for the Artemis missions. OVERVIEW During the early stages of IMPACT’s design, architecture and technical requirements collection, “scenarios” (use cases) - achievement goals required for acceptance testing, were identified by stakeholders. IMPACT successfully completed the scenario testing requirements and undertook an extensive operational run phase utilizing a wide range of input combinations with a goal of delivering a cohesive, trustworthy, reliable, vast, and diverse body of evidence. The intent of these modeling runs was to validate consistency in output, ensure solidity of executable operations and to streamline processes by identifying areas requiring efficiency improvements. Using the many missions of Artemis, IMPACT ran variations of operational runs to assess the output for acceptable, as well as unusual characteristics. This rigorous long-term “shakedown” analysis was implemented to help build a collective body of evidence to aid in securing a high level of confidence, reliability, and validity in the output, whether from the applicational components of IMPACT, or the entirety of the operational process. ANTICIPATED ANALYSIS AND CONCLUSION This presentation will discuss the various categories of input criteria; the comparisons in the application of these input criteria to various Artemis missions; the preparation and collection of the body of evidence, and reliability of the computational modeling techniques. This paper serves as an initial analytical overview of IMPACT’s probabilistic risk assessment (PRA) medical risk outputs covering Artemis missions and is not intended to be deemed the official medical response for the Artemis campaign.

Crew Composition↗

NASA NTRS2009

The SOFIA/SAFIRE Far-Infrared Spectrometer: Highlighting Submillimeter Astrophysics and Technology

The Submillimeter and Far-InfraRed Experiment (SAFIRE) on the SOFIA airborne observatory is an imaging spectrometer for wavelengths between 28 microns and 440 microns. Our design is a dual-band long-slit grating spectrometer, which provides broadband (approx. 4000 km/s) observations in two lines simultaneously over a field of view roughly 10" wide by 320" long. The low backgrounds in spectroscopy require very sensitive detectors with noise equivalent powers of order 10(exp -18) W/square root of Hz. We are developing a kilopixel, filled detector array for SAFIRE in a 32 x 40 format. The detector consists of a transition edge sensor (TES) bolometer array, a per-pixel broadband absorbing backshort array, and a NIST SQUID multiplexer readout array. This general type of array has been used successfully in the GISMO instrument, so we extrapolate to the sensitivity needed for airborne spectroscopy. Much of the cryogenic, electronics, and software infrastructure for SAFIRE have been developed. I provide here an overview of the progress on SAFIRE.

Benford, Dominic J.↗

NASA NTRS1997

An Approach to Building a Traceability Tool for Software Development

It is difficult in a large, complex computer program to ensure that it meets the specified requirements. As the program evolves over time, a11 program constraints originally elicited during the requirements phase must be maintained. In addition, during the life cycle of the program, requirements typically change and the program must consistently reflect those changes. Imagine the following scenario. Company X wants to develop a system to automate its assembly line. With such a large system, there are many different stakeholders, e.g., managers, experts such as industrial and mechanical engineers, and end-users. Requirements would be elicited from all of the stake holders involved in the system with each stakeholder contributing their point of view to the requirements. For example, some of the requirements provided by an industrial engineer may concern the movement of parts through the assembly line. A point of view provided by the electrical engineer may be reflected in constraints concerning maximum power usage. End-users may be concerned with comfort and safety issues, whereas managers are concerned with the efficiency of the operation. With so many points of view affecting the requirements, it is difficult to manage them, communicate information to relevant stakeholders. and it is likely that conflicts in the requirements will arise. In the coding process, the implementors will make additional assumptions and interpretations on the design and the requirements of the system. During any stage of development, stakeholders may request that a requirement be added or changed. In such a dynamic environment, it is difficult to guarantee that the system will preserve the current set of requirements. Tracing, the mapping between objects in the artifacts of the system being developed, addresses this issue. Artifacts encompass documents such as the system definition, interview transcripts, memoranda, the software requirements specification, user's manuals, the functional specifications, design reports, and system code. Tracing helps 1) validate system features against, the requirement specification, 2) identify error sources and, most importantly, 3) manage change. With so many people involved in the development of the system, it becomes necessary to identify the reasons behind the design requirements or the implementation decisions. This paper is concerned with an approach that maps documents to constraints that capture properties of and relationships between the objects being modeled by the program. Section 2 provides the reader with a background on traceability tools. Section 3 gives a brief description of the context monitoring system on which the approach suggested in this paper is based. Section 4 presents an overview of our approach to providing traceability. The last section presents our future direction of research.

Delgado, Nelly↗

NASA NTRS2023

Modeling and Simulation of the Angel Upper Limb Offload Device: Branching Into New Methods

BACKGROUND: The Active Response Gravity Offload System (ARGOS) provides an analog environment for extravehicular activity (EVA) testing and training. Discomfort has been observed during longer suited test sessions. While the subject’s core is offloaded during surface EVA evaluations, his/her arms experience full Earth gravity and can become overly fatigued, especially during suited tests which involve reaching and prolonged arm extensions. A device (ARGOS Negation of Gravitational Effects on the Limbs: ANGEL) to offload the weight of the arms and suit sleeves is being developed by JSC’s Flight Systems Branch of the Software, Robotics, and Simulation Division. Previously we have shared preliminary modeling of that device and kinematics based on motion capture data. Here we present an alternative approach to determine device kinematics by calculating ANGEL component angles with an OpenSim plugin. We compare calculated angles to inverse kinematics (IK) derived ones with the goal of validating the model. This new method can be further informative for device design and analytically testing different configurations to achieve desired reduced gravity conditions (e.g., lunar gravity (Lg) or Martian gravity (Mg)). We have compared calculated angles with IK-derived angles in tests with a shirt-sleeve subject positioned in a test stand with a Mark-III Hard Upper Torso (HUT) and Portable Life Support System (PLSS) mockup and arm weights to emulate the weight of the suit sleeve as well as a suited subject in ARGOS with a Mark-III suit. A variety of upper body tasks were completed in the former and full-body tasks in the latter. METHODS AND RESULTS: To model the offload device, we augment the OpenSim human model topology with the offload mechanism components and joints, using CAD models to represent the mechanism graphically. The joint angles of the device are calculated in the OpenSim plugin by modeling how the components configure themselves under the offloading spring tension given a particular IK-derived arm position. There are four ANGEL components with a total of 5 degrees of freedom (DOFs), each component has a single DOF except for the cuff which is modeled as 2 DOFs. The sickle/yaw bracket and cuff rotation angles are determined statically based on the assumptions that the sickle will track the attachment point of the cuff and that the cuff will rotate such that the attachment point is at its highest point. The cuff tilt, linker and V-bracket angles are then determined by optimizing their positions to approach a mechanical equilibrium. The calculated linker angle is compared to three different methods of determining the linker line-of-force kinematically (from V-bracket to center-cuff, cuff highest point or marker-derived position). Given the joint angles of the device, the spring force and resulting force on the arm is computed by the plugin and applied as an external load in inverse dynamics (ID) to enable study of overall shoulder joint torques as well as offload achieved. We verify the calculated joint angles by using the inverse kinematic data. The average difference in angles is the smallest for the V-bracket and linker, around 1 to 5 degrees for most trials. The resulting offload and shoulder torque are comparable between calculated and IK-derived angles. In summary, we have developed a method to calculate the joint angles of an exoskeleton-like upper limb offloading device currently in development. We have also developed a custom plugin which will be a valuable tool to optimize device configurations for a desired gravitational environment, probe the offload achieved for motions recorded outside of our test suite, and inform future design improvements.

L B Nilsson↗

NASA NTRS2023

Modeling and Simulation of The Angel Upper Limb Offload Device: Branching into New Methods

BACKGROUND: The Active Response Gravity Offload System (ARGOS) provides an analog environment for extravehicular activity (EVA) testing and training. Discomfort has been observed during longer suited test sessions. While the subject’s core is offloaded during surface EVA evaluations, his/her arms experience full Earth gravity and can become overly fatigued, especially during suited tests which involve reaching and prolonged arm extensions. A device (ARGOS Negation of Gravitational Effects on the Limbs: ANGEL) to offload the weight of the arms and suit sleeves is being developed by JSC’s Flight Systems Branch of the Software, Robotics, and Simulation Division. Previously we have shared preliminary modeling of that device and kinematics based on motion capture data. Here we present an alternative approach to determine device kinematics by calculating ANGEL component angles with an OpenSim plugin. We compare calculated angles to inverse kinematics (IK) derived ones with the goal of validating the model. This new method can be further informative for device design and analytically testing different configurations to achieve desired reduced gravity conditions (e.g., lunar gravity (Lg) or Martian gravity (Mg)). We have compared calculated angles with IK-derived angles in tests with a shirt-sleeve subject positioned in a test stand with a Mark-III Hard Upper Torso (HUT) and Portable Life Support System (PLSS) mockup and arm weights to emulate the weight of the suit sleeve as well as a suited subject in ARGOS with a Mark-III suit. A variety of upper body tasks were completed in the former and full-body tasks in the latter. METHODS AND RESULTS: To model the offload device, we augment the OpenSim human model topology with the offload mechanism components and joints, using CAD models to represent the mechanism graphically. The joint angles of the device are calculated in the OpenSim plugin by modeling how the components configure themselves under the offloading spring tension given a particular IK-derived arm position. There are four ANGEL components with a total of 5 degrees of freedom (DOFs), each component has a single DOF except for the cuff which is modeled as 2 DOFs. The sickle/yaw bracket and cuff rotation angles are determined statically based on the assumptions that the sickle will track the attachment point of the cuff and that the cuff will rotate such that the attachment point is at its highest point. The cuff tilt, linker and V-bracket angles are then determined by optimizing their positions to approach a mechanical equilibrium. The calculated linker angle is compared to three different methods of determining the linker line-of-force kinematically (from V-bracket to center-cuff, cuff highest point or marker-derived position). Given the joint angles of the device, the spring force and resulting force on the arm is computed by the plugin and applied as an external load in inverse dynamics (ID) to enable study of overall shoulder joint torques as well as offload achieved. We verify the calculated joint angles by using the inverse kinematic data. The average difference in angles is the smallest for the V-bracket and linker, around 1 to 5 degrees for most trials. The resulting offload and shoulder torque are comparable between calculated and IK-derived angles. In summary, we have developed a method to calculate the joint angles of an exoskeleton-like upper limb offloading device currently in development. We have also developed a custom plugin which will be a valuable tool to optimize device configurations for a desired gravitational environment, probe the offload achieved for motions recorded outside of our test suite, and inform future design improvements.

L B Nilsson↗

DOE OSTI2025

User Guide for BLADE_LC_processor.py

BLADE_LC_processor.py is an optional script within the BLADE (Bolide Light-curve Analysis and Discrimination Explorer) open-source software package. It converts per-event light curve CSVs plus a metadata table into maps, plots, a per-sample trajectory file, and an aggregate summary. It anchors each trajectory at peak brightness, assumes constant speed and entry angle across the event, and propagates altitude and ground track relative to that anchor. The script converts the input azimuth internally to a travel bearing for the map and trajectory. Outputs include event folders with figures and a consolidated CSV containing start, peak, and end altitudes and all original metadata, sorted newest to oldest. For further background, users are referred to the foundational publication: Silber, E. A., Sawal, V. (2025), “BLADE: An Automated Framework for Classifying Light Curves from the Center for Near-Earth Object Studies Fireball Database,” The Astronomical Journal, doi: 10.3847/1538-3881/adeb55.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2003

An Immunized Aircraft Maneuver Selection System

The objective of this project, as stated in the original proposal, was to develop an immunized aircraft maneuver selection (IAMS) system. The IAMS system was to be composed of computational and informational building blocks that resemble structures in natural immune systems. The ultimate goal of the project was to develop a software package that could be flight tested on aircraft models. This report describes the work performed in the first year of what was to have been a two year project. This report also describes efforts that would have been made in the final year to have completed the project, had it been continued for the final year. After introductory material is provided in Section 2, the end-of-year-one status of the effort is discussed in Section 3. The remainder of the report provides an accounting of first year efforts. Section 4 provides background information on natural immune systems while Section 5 describes a generic ar&itecture developed for use in the IAMS. Section 6 describes the application of the architecture to a system identification problem. Finally, Section 7 describes steps necessary for completing the project.

Karr, Charles L.↗

NASA NTRSDate not supplied

Transcriptomics Processing Pipelines for Space Biology: An Open Source and Consensus-Driven Approach

Transcriptomics holds significant value in elucidating the relationship between gene expression, experimental factors, biological factors, and various types of omics data. Enhancing our understanding of these connections is paramount for foundational biology, which plays a pivotal role in devising solutions for challenges pertinent to both space travel and terrestrial life. The NASA GeneLab project, part of the Open Science Data Repository (OSDR.nasa.gov), seeks to accelerate space biology research through cataloging and democratizing ‘omics data, including transcriptomics. Since raw omics data are largely inaccessible to non-bioinformaticians, GeneLab works with the scientific community via the Open Science Analysis Working Groups (AWGs) to develop standard processing pipelines to generate and publish processed data. Unlike raw data, processed data have greater immediate value to diverse users with varying technical backgrounds and computational capabilities. Standardizing processing workflows is essential to match the pace of raw data generation, ensure reproducibility, and enable standardized processed data for comparison across datasets. As of June 2023, transcriptomics studies comprise over half of GeneLab datasets hosted on the OSDR, including data from bulk RNA-seq and Affymetrix or Agilent 1-Channel DNA microarray assays. In collaboration with the AWGs, GeneLab developed consensus processing pipelines for these transcriptomics data types that includes quality control, background correction (microarray only), data normalization and quantification, culminating in the detection and annotation of differentially expressed genes. The work presented here describes Nextflow implementations of GeneLab’s consensus transcriptomics pipelines that automates and accelerates processing of these datasets. In addition to the core data processing, these workflows also include raw data staging and a robust verification and validation program to identify errors in real-time, stop additional downstream computation, and preserve computational resources. These workflows are used to generate GeneLab processed data hosted on the OSDR, and are publicly available as open source software for others to use at: https://github.com/nasa/GeneLab_Data_Processing.

Jonathan Oribello↗

NASA NTRS2007

Adaptive Modeling of the International Space Station Electrical Power System

Software simulations provide NASA engineers the ability to experiment with spacecraft systems in a computer-imitated environment. Engineers currently develop software models that encapsulate spacecraft system behavior. These models can be inaccurate due to invalid assumptions, erroneous operation, or system evolution. Increasing accuracy requires manual calibration and domain-specific knowledge. This thesis presents a method for automatically learning system models without any assumptions regarding system behavior. Data stream mining techniques are applied to learn models for critical portions of the International Space Station (ISS) Electrical Power System (EPS). We also explore a knowledge fusion approach that uses traditional engineered EPS models to supplement the learned models. We observed that these engineered EPS models provide useful background knowledge to reduce predictive error spikes when confronted with making predictions in situations that are quite different from the training scenarios used when learning the model. Evaluations using ISS sensor data and existing EPS models demonstrate the success of the adaptive approach. Our experimental results show that adaptive modeling provides reductions in model error anywhere from 80% to 96% over these existing models. Final discussions include impending use of adaptive modeling technology for ISS mission operations and the need for adaptive modeling in future NASA lunar and Martian exploration.

Thomas, Justin Ray↗

NASA NTRS1986

Interpreting forest and grassland biome productivity utilizing nested scales of image resolution and biogeographical analysis

Several hardware, software, and data collection problems encountered were conquered. The Geographic Information System (GIS) data from other systems were converted to ERDAS format for incorporation with the image data. Statistical analysis of the relationship between spectral values and productivity is being pursued. Several project sites, including Jackson, Pope, Boulder, Smokies, and Huntington Forest are evolving as the most intensively studied areas, primarily due to availability of data and time. Progress with data acquisition and quality checking, more details on experimental sites, and brief summarizations of research results and future plans are discussed. Material on personnel, collaborators, facilities, site background, and meetings and publications of the investigators are included.

Iverson, L. R.↗

NASA NTRS1992

Functional requirements document for NASA/MSFC Earth Science and Applications Division: Data and information system (ESAD-DIS). Interoperability, 1992

These Earth Science and Applications Division-Data and Information System (ESAD-DIS) interoperability requirements are designed to quantify the Earth Science and Application Division's hardware and software requirements in terms of communications between personal and visualization workstation, and mainframe computers. The electronic mail requirements and local area network (LAN) requirements are addressed. These interoperability requirements are top-level requirements framed around defining the existing ESAD-DIS interoperability and projecting known near-term requirements for both operational support and for management planning. Detailed requirements will be submitted on a case-by-case basis. This document is also intended as an overview of ESAD-DIs interoperability for new-comers and management not familiar with these activities. It is intended as background documentation to support requests for resources and support requirements.

Stephens, J. Briscoe↗

NASA NTRS1990

Analysis of faults detected in a large-scale multi-version software development experiment

In a multiversion software experiment, twenty programs were built to the same specification of an inertial navigation problem. The programs were then subjected to a three-phase testing and debugging process: an acceptance test, a certification test, and an operational test. Less than 20 percent of the faults discovered during the certification and operational testing were nonunique, i.e., the same or very similar faults would be found in more than one program. However, some of these common faults spanned as many as half of the versions. Faults discovered during the certification testing were due to specification errors and ambiguities, inadequate programmer background knowledge, insufficient programming experience, incomplete analysis, and insufficient acceptance testing. Faults discovered during the operational testing were of a more subtle nature, and were mostly due to various programmer knowledge defects and incomplete analysis errors. Techniques that might have prevented the observed faults are discussed.

Vouk, Mladen A.↗