SEARCH · Engineering Papers

Results for “Software Test Report”

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

SourceResearch connectionFrom yearThrough year

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

At least 235 records · Page 13

All sources NASA NTRS DOE OSTI

NASA NTRS1990

Photovoltaic array space power plus diagnostics experiment

The objective is to summarize the five years of hardware development and fabrication represented by the Photovoltaic Array Space Power Plus Diagnostics (PASP Plus) Instrument. The original PASP Experiment requirements and background is presented along with the modifications which were requested to transform the PASP Experiment into the PASP Plus Instrument. The PASP Plus hardware and software is described. Test results for components and subsystems are given as well as final system tests. Also included are appendices which describe the major subsystems and present supporting documentation such as block diagrams, schematics, circuit board artwork, drawings, test procedures and test reports.

Burger, D. R.↗

NASA NTRS1995

A relational metric, its application to domain analysis, and an example analysis and model of a remote sensing domain

An objective and quantitative method has been developed for deriving models of complex and specialized spheres of activity (domains) from domain-generated verbal data. The method was developed for analysis of interview transcripts, incident reports, and other text documents whose original source is people who are knowledgeable about, and participate in, the domain in question. To test the method, it is applied here to a report describing a remote sensing project within the scope of the Earth Observing System (EOS). The method has the potential to improve the designs of domain-related computer systems and software by quickly providing developers with explicit and objective models of the domain in a form which is useful for design. Results of the analysis include a network model of the domain, and an object-oriented relational analysis report which describes the nodes and relationships in the network model. Other products include a database of relationships in the domain, and an interactive concordance. The analysis method utilizes a newly developed relational metric, a proximity-weighted frequency of co-occurrence. The metric is applied to relations between the most frequently occurring terms (words or multiword entities) in the domain text, and the terms found within the contexts of these terms. Contextual scope is selectable. Because of the discriminating power of the metric, data reduction from the association matrix to the network is simple. In addition to their value for design. the models produced by the method are also useful for understanding the domains themselves. They can, for example, be interpreted as models of presence in the domain.

Mcgreevy, Michael W.↗

NASA NTRS1975

Apollo experience report guidance and control systems: Lunar module abort guidance system

The history of a unique development program that produced an operational fixed guidance system of inertial quality is presented. Each phase of development, beginning with requirement definition and concluding with qualification and testing, is addressed, and developmental problems are emphasized. Software generation and mission operations are described, and specifications for the inertial reference unit are included, as are flight performance results. Significant program observations are noted.

Kurten, P. M.↗

NASA NTRS1995

SSME Post Test Diagnostic System: Systems Section

An assessment of engine and component health is routinely made after each test firing or flight firing of a Space Shuttle Main Engine (SSME). Currently, this health assessment is done by teams of engineers who manually review sensor data, performance data, and engine and component operating histories. Based on review of information from these various sources, an evaluation is made as to the health of each component of the SSME and the preparedness of the engine for another test or flight. The objective of this project - the SSME Post Test Diagnostic System (PTDS) - is to develop a computer program which automates the analysis of test data from the SSME in order to detect and diagnose anomalies. This report primarily covers work on the Systems Section of the PTDS, which automates the analyses performed by the systems/performance group at the Propulsion Branch of NASA Marshall Space Flight Center (MSFC). This group is responsible for assessing the overall health and performance of the engine, and detecting and diagnosing anomalies which involve multiple components (other groups are responsible for analyzing the behavior of specific components). The PTDS utilizes several advanced software technologies to perform its analyses. Raw test data is analyzed using signal processing routines which detect features in the data, such as spikes, shifts, peaks, and drifts. Component analyses are performed by expert systems, which use 'rules-of-thumb' obtained from interviews with the MSFC data analysts to detect and diagnose anomalies. The systems analysis is performed using case-based reasoning. Results of all analyses are stored in a relational database and displayed via an X-window-based graphical user interface which provides ranked lists of anomalies and observations by engine component, along with supporting data plots for each.

Bickmore, Timothy↗

NASA NTRS2003

Experiences with Testing the Largest Ground System NASA Has Ever Built

In the 1980s, the National Aeronautics and Space Administration (NASA) embarked upon a major Earth-focused program called Mission to Planet Earth. The Goddard Space Flight Center (GSFC) was selected to manage and develop a key component - the Earth Observing System (EOS). The EOS consisted of four major missions designed to monitor the Earth. The missions included 4 spacecraft. Terra (launched December 1999), Aqua (launched May 2002), ICESat (Ice, Cloud, and Land Elevation Satellite, launched January 2003), and Aura (scheduled for launch January 2004). The purpose of these missions was to provide support for NASA s long-term research effort for determining how human-induced and natural changes affect our global environment. The EOS Data and Information System (EOSDIS), a globally distributed, large-scale scientific system, was built to support EOS. Its primary function is to capture, collect, process, and distribute the most voluminous set of remotely sensed scientific data to date estimated to be 350 Gbytes per day. The EOSDIS is composed of a diverse set of elements with functional capabilities that require the implementation of a complex set of computers, high-speed networks, mission-unique equipment, and associated Information Technology (IT) software along with mission-specific software. All missions are constrained by schedule, budget, and staffing resources, and rigorous testing has been shown to be critical to the success of each mission. This paper addresses the challenges associated with the planning, test definition. resource scheduling, execution, and discrepancy reporting involved in the mission readiness testing of a ground system on the scale of EOSDIS. The size and complexity of the mission systems supporting the Aqua flight operations, for example, combined with the limited resources available, prompted the project to challenge the prevailing testing culture. The resulting success of the Aqua Mission Readiness Testing (MRT) program was due in no small measure to re-structuring the traditional programmatic and technical approach to a more efficient and robust program. Programmatically, it meant gaining the endorsement, commitment, and cooperation of the numerous subsystem element managers and other stakeholder organizations. Technically, it required an MRT program that was agile, could rapidly adapt to requirements changes, and was flexible in its overall approach. Furthermore, this paper addresses the following questions: 1. What are the key ingredients (e.g., test tools, organization) needed to conduct a successful MRT program? 2. What distinguishes EOS MRT from the traditional system testing approach? 3. Where should the focus of testing be since it is infeasible to test every element or subsystem? 4. How can MRT be applied effectively to other systems or missions? To provide answers to these questions, this paper relies heavily on real-life, hands-on experiences ("lessons learned") gained during mission readiness testing of the Terra ground system and, most recently, the Aqua and ICESat missions. Moreover, this paper explores how lessons learned were turned into lessons applied for the upcoming Aura mission. Although derived from the EOS missions, MRT techniques and strategies can be applied to enhance the testing of other missions.

Lehtonen, Ken↗

NASA NTRS1990

What FM can offer DFCS design

The results of aircrafts and spacecrafts flight tests are reported. It is shown that the problems of Digital Flight Control Systems (DFCS) are the problems of systems whose complexity has exceeded the reach of the intellectual tools employed. It is also shown that intuition, experience, and techniques derived from mechanical and analog systems are insufficient for complex, integrated, digital systems. Formal Methods (FM) of computer science can offer DFCS systematic techniques for the construction of trustworthy software, including: techniques for the precise specification of requirements and the development of designs; systematic approaches to the design and structuring of distributed and concurrent systems; fault tolerance algorithms; and systematic methods of testing and analytic methods of verification.

Rushby, John↗

NASA NTRS2009

Development and Evaluation of Sensor Concepts for Ageless Aerospace Vehicles: Report 5 - Phase 2 Implementation of the Concept Demonstrator

This report describes the second phase of the implementation of the Concept Demonstrator experimental test-bed system containing sensors and processing hardware distributed throughout the structure, which uses multi-agent algorithms to characterize impacts and determine a suitable response to these impacts. This report expands and adds to the report of the first phase implementation. The current status of the system hardware is that all 192 physical cells (32 on each of the 6 hexagonal prism faces) have been constructed, although only four of these presently contain data-acquisition sub-modules to allow them to acquire sensor data. Impact detection.. location and severity have been successfully demonstrated. The software modules for simulating cells and controlling the test-bed are fully operational. although additional functionality will be added over time. The visualization workstation displays additional diagnostic information about the array of cells (both real and simulated) and additional damage information. Local agent algorithms have been developed that demonstrate emergent behavior of the complex multi-agent system, through the formation of impact damage boundaries and impact networks. The system has been shown to operate well for multiple impacts. and to demonstrate robust reconfiguration in the presence of damage to numbers of cells.

Batten, Adam↗

NASA NTRS2003

Unexplained Discontinuity in the US Radiosonde Temperature Data: Stratosphere - Part 2

In part I of this paper, the United States (US) radiosonde temperature data are shown to have significant and unexplained inhomogeneities in the mid-troposphere. This part discusses the differences between observations taken at 0 and 12 UTC especially in the stratosphere by the Vaisala RS80 radiosondes that are integrated within the National Weather Service's (NWS) Micro-ART system. The results show that there is a large maxima in the horizontal distribution of the monthly means of the 0/12 UTC differences over the central US that is absent over Canada and this maxima is as large as 5 C at 10 hPa. The vertical profiles of the root-mean-square of the monthly means are much larger in the US than those else where. The data clearly shows that the 0/12 UTC differences are largely artificial especially over the central US and originate in the post processing software at observing stations, thus confirming the findings in part I. Special flight data from the NWS's test facility at Sterling, Va. have been obtained. This data can be used to deduce the bias correction applied by Vaisala's post processing system. By analyzing the correction data, it can be shown that the inconsistencies with non-US Vaisala RS80 data as well as most of the large 0/12 UTC differences over the US can be accounted for by multiplying the reported elapsed time (i.e. time since launch) by the factor which is incorrectly applied by the post processing software. After being presented with the findings in this paper, Vaisala further isolated the source of the inconsistencies to a software coding error in the radiation bias correction scheme. The error effects only the software installed at US stations.

Redder, Christopher R.↗

NASA NTRS2003

Development of Algorithms for Control of Humidity in Plant Growth Chambers

Algorithms were developed to control humidity in plant growth chambers used for research on bioregenerative life support at Kennedy Space Center. The algorithms used the computed water vapor pressure (based on measured air temperature and relative humidity) as the process variable, with time-proportioned outputs to operate the humidifier and de-humidifier. Algorithms were based upon proportional-integral-differential (PID) and Fuzzy Logic schemes and were implemented using I/O Control software (OPTO-22) to define and download the control logic to an autonomous programmable logic controller (PLC, ultimate ethernet brain and assorted input-output modules, OPTO-22), which performed the monitoring and control logic processing, as well the physical control of the devices that effected the targeted environment in the chamber. During limited testing, the PLC's successfully implemented the intended control schemes and attained a control resolution for humidity of less than 1%. The algorithms have potential to be used not only with autonomous PLC's but could also be implemented within network-based supervisory control programs. This report documents unique control features that were implemented within the OPTO-22 framework and makes recommendations regarding future uses of the hardware and software for biological research by NASA.

Costello, Thomas A.↗

NASA NTRS2000

The Ceres S'COOL Project: Two Years After First Launch

The idea for the Students' Cloud Observations OnLine (S'COOL) project as an outreach and education element of NASA's Clouds and the Earth's Radiant Energy System (CERES) research program was conceived in late 1996 during a conversation with a middle school science teacher. S'COOL was implemented in a series of increasingly developed test phases during 1997, as the launch of the first CERES instrument approached. Even before launch, the reception of the project in schools far exceeded expectations. After several delays the first instrument, on the Tropical Rainfall Measuring Mission (TRMM) spacecraft, was launched on Thanksgiving Day, 1997. Since the first launch, development and expansion of the project has continued with expectations for launch of Terra carrying two CERES instruments into a polar orbit in mid-1998. That launch is now expected in fall 1999, and will finally provide overflight of all participating schools. In two years, the project has grown from three initial test participants to over 300 schools now participating in 23 countries on five continents. Students from first grade through university level are involved (most participants are ages 10-15). S'COOL is also being used by a few education professors to teach about Internet use in the classroom. The project continues to grow through word of mouth, presentations at teacher workshops, and now increasingly through teachers who find it during web searches. Participants in the S'COOL project are part of the CERES validation team. They provide ground truth measurements at the time the CERES instrument flies over their location, to be compared with the retrieval of cloud properties by remote sensing from CERES. Quantities reported include cloud type, height, fraction and opacity; information on contrails; surface temperature, pressure and relative humidity; and ground cover (snow/ice, wet, dry; leaves on trees or not). in addition, a comment field on the report form serves as a catch-all for all kinds of interesting observations, including similes written by some classes to describe more exactly the clouds they see. Several not totally unexpected complications with the CERES instrument and processing software mean that the CERES team has not yet reached the point of computing the cloud properties, a high level product at the end of the processing stream. However, progress is being made and we anticipate that we will soon be populating the S'COOL database with a large number of satellite retrievals for comparison with the students' observations. Some satellite retrievals from the initial test phases are already available in the database, The CERES instruments are planned to operate at least through 2006, and the S'COOL Project is planned to continue at least that long, providing motivational learning to as many students as possible. This paper reports on the first several years of the S'CCOL project. It further reports on some of the noteworthy observations and comparisons made possible by this project. Schools are often located in interesting places, in terms of the clouds found there and the satellite's ability to observe these clouds. The paper also reports on the learning opportunities delivered by this project, and on new questions about the planet and its climate which arise in the students' minds as a result of their active participation.

Chambers, Lin H.↗

NASA NTRS2004

Daytime Water Detection by Fusing Multiple Cues for Autonomous Off-Road Navigation

Detecting water hazards is a significant challenge to unmanned ground vehicle autonomous off-road navigation. This paper focuses on detecting the presence of water during the daytime using color cameras. A multi-cue approach is taken. Evidence of the presence of water is generated from color, texture, and the detection of reflections in stereo range data. A rule base for fusing water cues was developed by evaluating detection results from an extensive archive of data collection imagery containing water. This software has been implemented into a run-time passive perception subsystem and tested thus far under Linux on a Pentium based processor.

COMPONENT REPORTS↗

NASA NTRS2024

Multidisciplinary Analytics, Visualization, and Reporting Interface for Integrated Countermeasures

Exploration class missions will have communication latency requiring crew members to make decisions more autonomously, with less support from ground personnel. Therefore, new software is needed to provide crew the ability to not only visualize their countermeasures data, but to also derive comprehensive, nuanced, and multidisciplinary insights regarding the health and performance informatics throughout a mission. The Multidisciplinary Analytics, Visualization, and Reporting Interface for Integrated Countermeasures (MAVRIIC) software seeks to establish a centralized approach to countermeasure data visualization that will facilitate a more holistic understanding of crew members' well-being and performance and enable the development of informed and autonomous decision-making support systems aligned with the evolving requirements of Exploration missions. The culmination of MAVRIIC phase 1 (end of FY23) marked the release of a full-stack, cloud-based ground tool displaying visualizations of in-flight exercise data, exercise ground testing, and exercise MEDB reports. Phase 2 of MAVRIIC (FY24) focuses on beginning the expansion of data contents to domains outside of exercise, including functional fitness, sensorimotor, food/nutrition, radiation, bone, and cardio/vision. Phase 3 and phase 4 will comprise enhanced analytics integration and initiation of flight tool development for infusion into the Artemis Program and eventually the Mars Transit Habitat.

Kent Lawrence Kalogera↗

NASA NTRS2009

Connecting Research and Practice: An Experience Report on Research Infusion with SAVE

NASA systems need to be highly dependable to avoid catastrophic mission failures. This calls for rigorous engineering processes including meticulous validation and verification. However, NASA systems are often highly distributed and overwhelmingly complex, making the software portion of these systems challenging to understand, maintain, change, reuse, and test. NASA's systems are long-lived and the software maintenance process typically constitutes 60-80% of the total cost of the entire lifecycle. Thus, in addition to the technical challenges of ensuring high life-time quality of NASA's systems, the post-development phase also presents a significant financial burden. Some of NASA's software-related challenges could potentially be addressed by some of the many powerful technologies that are being developed in software research laboratories. Many of these research technologies seek to facilitate maintenance and evolution by for example architecting, designing and modeling for quality, flexibility, and reuse. Other technologies attempt to detect and remove defects and other quality issues by various forms of automated defect detection, architecture analysis, and various forms of sophisticated simulation and testing. However promising, most such research technologies nevertheless do not make the transition from the research lab to the software lab. One reason the transition from research to practice seldom occurs is that research infusion and technology transfer is difficult. For example, factors related to the technology are sometimes overshadowed by other types of factors such as reluctance to change and therefore prohibits the technology from sticking. Successful infusion might also take very long time. One famous study showed that the discrepancy between the conception of the idea and its practical use was 18 years plus or minus three. Nevertheless, infusing new technology is possible. We have found that it takes special circumstances for such research infusion to succeed: 1) there must be evidence that the technology works in the practitioner's particular domain, 2) there must be a potential for great improvements and enhanced competitive edge for the practitioner, 3) the practitioner has to have strong individual curiosity and continuous interest in trying out new technologies, 4) the practitioner has to have support on multiple levels (i.e. from the researchers, from management, from sponsors etc), and 5) to remain infused, the new technology has to be integrated into the practitioner's processes so that it becomes a natural part of the daily work. NASA IV&V's Research Infusion initiative sponsored by NASA's Office of Safety & Mission Assurance (OSMA) through the Software Assurance Research Program (SARP), strives to overcome some of the problems related to research infusion.

Lindvall, Mikael↗

NASA NTRS1992

Software Engineering Laboratory Ada performance study: Results and implications

The SEL is an organization sponsored by NASA/GSFC to investigate the effectiveness of software engineering technologies applied to the development of applications software. The SEL was created in 1977 and has three organizational members: NASA/GSFC, Systems Development Branch; The University of Maryland, Computer Sciences Department; and Computer Sciences Corporation, Systems Development Operation. The goals of the SEL are as follows: (1) to understand the software development process in the GSFC environments; (2) to measure the effect of various methodologies, tools, and models on this process; and (3) to identify and then to apply successful development practices. The activities, findings, and recommendations of the SEL are recorded in the Software Engineering Laboratory Series, a continuing series of reports that include the Ada Performance Study Report. This paper describes the background of Ada in the Flight Dynamics Division (FDD), the objectives and scope of the Ada Performance Study, the measurement approach used, the performance tests performed, the major test results, and the implications for future FDD Ada development efforts.

Booth, Eric W.↗

NASA NTRS2001

A Genuine TEAM Player

Qualtech Systems, Inc. developed a complete software system with capabilities of multisignal modeling, diagnostic analysis, run-time diagnostic operations, and intelligent interactive reasoners. Commercially available as the TEAMS (Testability Engineering and Maintenance System) tool set, the software can be used to reveal unanticipated system failures. The TEAMS software package is broken down into four companion tools: TEAMS-RT, TEAMATE, TEAMS-KB, and TEAMS-RDS. TEAMS-RT identifies good, bad, and suspect components in the system in real-time. It reports system health results from onboard tests, and detects and isolates failures within the system, allowing for rapid fault isolation. TEAMATE takes over from where TEAMS-RT left off by intelligently guiding the maintenance technician through the troubleshooting procedure, repair actions, and operational checkout. TEAMS-KB serves as a model management and collection tool. TEAMS-RDS (TEAMS-Remote Diagnostic Server) has the ability to continuously assess a system and isolate any failure in that system or its components, in real time. RDS incorporates TEAMS-RT, TEAMATE, and TEAMS-KB in a large-scale server architecture capable of providing advanced diagnostic and maintenance functions over a network, such as the Internet, with a web browser user interface.

Source record↗

NASA NTRS2011

Project Report: Automatic Sequence Processor Software Analysis

The Mission Planning and Sequencing (MPS) element of Multi-Mission Ground System and Services (MGSS) provides space missions with multi-purpose software to plan spacecraft activities, sequence spacecraft commands, and then integrate these products and execute them on spacecraft. Jet Propulsion Laboratory (JPL) is currently is flying many missions. The processes for building, integrating, and testing the multi-mission uplink software need to be improved to meet the needs of the missions and the operations teams that command the spacecraft. The Multi-Mission Sequencing Team is responsible for collecting and processing the observations, experiments and engineering activities that are to be performed on a selected spacecraft. The collection of these activities is called a sequence and ultimately a sequence becomes a sequence of spacecraft commands. The operations teams check the sequence to make sure that no constraints are violated. The workflow process involves sending a program start command, which activates the Automatic Sequence Processor (ASP). The ASP is currently a file-based system that is comprised of scripts written in perl, c-shell and awk. Once this start process is complete, the system checks for errors and aborts if there are any; otherwise the system converts the commands to binary, and then sends the resultant information to be radiated to the spacecraft.

sequencing↗

NASA NTRS1992

The Software Engineering Laboratory: An operational software experience factory

For 15 years, the Software Engineering Laboratory (SEL) has been carrying out studies and experiments for the purpose of understanding, assessing, and improving software and software processes within a production software development environment at NASA/GSFC. The SEL comprises three major organizations: (1) NASA/GSFC, Flight Dynamics Division; (2) University of Maryland, Department of Computer Science; and (3) Computer Sciences Corporation, Flight Dynamics Technology Group. These organizations have jointly carried out several hundred software studies, producing hundreds of reports, papers, and documents, all of which describe some aspect of the software engineering technology that was analyzed in the flight dynamics environment at NASA. The studies range from small, controlled experiments (such as analyzing the effectiveness of code reading versus that of functional testing) to large, multiple project studies (such as assessing the impacts of Ada on a production environment). The organization's driving goal is to improve the software process continually, so that sustained improvement may be observed in the resulting products. This paper discusses the SEL as a functioning example of an operational software experience factory and summarizes the characteristics of and major lessons learned from 15 years of SEL operations.

Basili, Victor R.↗

NASA NTRS1995

Follow-the-leader algorithm for the payload inspection and processing system

This report summarizes the author's summer 1995 work at NASA Kennedy Space Center in the Advanced System Division. The assignment was path planning for the Payload Inspection and Processing System (PIPS). PIPS is an automated system, programmed off-line for inspection of Space Shuttle payloads after integration and prior to launch. PIPS features a hyper-redundant 18-dof serpentine truss manipulator capable of snake-like motions to avoid obstacles. The path planning problem was divided into two segments: (1) determining an obstacle-free trajectory for the inspection camera at the manipulator tip to follow; and (2) development of a follow-the-leader (FTL) algorithm which ensures whole-arm collision avoidance by forcing ensuing links to follow the same tip trajectory. The summer 1995 work focused on the FTL algorithm. This report summarizes development, implementation, testing, and graphical demonstration of the FTL algorithm for prototype PIPS hardware. The method and code was developed in a modular manner so the final PIPS hardware may use them with minimal changes. The FTL algorithm was implemented using MATLAB software and demonstrated with a high-fidelity IGRIP model. The author also supported implementation of the algorithm in C++ for hardware control. The FTL algorithm proved to be successful and robust in graphical simulation. The author intends to return to the project in summer 1996 to implement path planning for PIPS.

Williams, Robert L., II↗