Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software testing”

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 181 records · Page 10

Advanced communications technology satellite high burst rate link evaluation terminal communication protocol software user's guide, version 1.0

The Communication Protocol Software was developed at the NASA Lewis Research Center to support the Advanced Communications Technology Satellite High Burst Rate Link Evaluation Terminal (ACTS HBR-LET). The HBR-LET is an experimenters terminal to communicate with the ACTS for various experiments by government, university, and industry agencies. The Communication Protocol Software is one segment of the Control and Performance Monitor (C&PM) Software system of the HBR-LET. The Communication Protocol Software allows users to control and configure the Intermediate Frequency Switch Matrix (IFSM) on board the ACTS to yield a desired path through the spacecraft payload. Besides IFSM control, the C&PM Software System is also responsible for instrument control during HBR-LET experiments, uplink power control of the HBR-LET to demonstrate power augmentation during signal fade events, and data display. The Communication Protocol Software User's Guide, Version 1.0 (NASA CR-189162) outlines the commands and procedures to install and operate the Communication Protocol Software. Configuration files used to control the IFSM, operator commands, and error recovery procedures are discussed. The Communication Protocol Software Maintenance Manual, Version 1.0 (NASA CR-189163, to be published) is a programmer's guide to the Communication Protocol Software. This manual details the current implementation of the software from a technical perspective. Included is an overview of the Communication Protocol Software, computer algorithms, format representations, and computer hardware configuration. The Communication Protocol Software Test Plan (NASA CR-189164, to be published) provides a step-by-step procedure to verify the operation of the software. Included in the Test Plan is command transmission, telemetry reception, error detection, and error recovery procedures.

Reinhart, Richard C.↗

Implementation of a maximum likelihood convolutional decoder in the DSN

The development status of the decoder and the factors which were considered in defining the specific functional requirements are described. The design is discussed to the block diagram level. A description of the detailed design is provided, along with a description of the test software developed and a brief summary of the performance evaluation testing completed so far.

Alberda, M. E.↗

Concept of a programmable maintenance processor applicable to multiprocessing systems

A programmable maintenance processor concept applicable to multiprocessing systems has been developed at the NASA Ames Research Center's Dryden Flight Research Facility. This stand-alone-processor is intended to provide support for system and application software testing as well as hardware diagnostics. An initial machanization has been incorporated into the extended aircraft interrogation and display system (XAIDS) which is multiprocessing general-purpose ground support equipment. The XAIDS maintenance processor has independent terminal and printer interfaces and a dedicated magnetic bubble memory that stores system test sequences entered from the terminal. This report describes the hardware and software embodied in this processor and shows a typical application in the check-out of a new XAIDS.

Glover, Richard D.↗

Test oracle automation for V&V of an autonomous spacecraft's planner

We built automation to assist the software testing efforts associated with the Remote Agent experiment. In particular, our focus was upon introducing test oracles into the testing of the planning and scheduling system component. This summary is intended to provide an overview of the work.

testing test oracles verification validation analy↗

Solar dynamic heat rejection technology. Task 2: Heat pipe radiator development

This report covers the design, fabrication, and test of several dual slot heat pipe engineering development units. The following dual-slot heat pipes were fabricated and tested: two 6-ft. aluminum heat pipes; a 20-ft. aluminum heat pipe; and a 20-ft. aluminum heat pipe with a four-leg evaporator section. The test results of all four test articles are presented and compared to the performance predicted by the design software. Test results from the four-leg article are incomplete. The methodology for fabricating stainless steel dual slot heat pipes was also studied by performing a tool life test with different single point cutters, and these results are also presented. Although the dual-slot heat pipe has demonstrated the potential to meet the requirements for a high capacity radiator system, uncertainties with the design still exist. The startup difficulties with the aluminum test articles must be solved, and a stainless steel/methanol heat pipe should be built and tested.

League, Mark↗

An overview of the mathematical and statistical analysis component of RICIS

Mathematical and statistical analysis components of RICIS (Research Institute for Computing and Information Systems) can be used in the following problem areas: (1) quantification and measurement of software reliability; (2) assessment of changes in software reliability over time (reliability growth); (3) analysis of software-failure data; and (4) decision logic for whether to continue or stop testing software. Other areas of interest to NASA/JSC where mathematical and statistical analysis can be successfully employed include: math modeling of physical systems, simulation, statistical data reduction, evaluation methods, optimization, algorithm development, and mathematical methods in signal processing.

Hallum, Cecil R.↗

TRMM Re-Entry Planning: Attitude Determination and Control During Thruster Modes

The Tropical Rainfall Measuring Mission (TRMM) spacecraft has been undergoing design for a controlled re-entry to Earth. During simulation of the re-entry plan, there was evidence of errors in the attitude determination algorithms during thruster modes. These errors affected the bum efficiency, and thus planning, during re-entry. During thruster modes, the spacecraft attitude is controlled off of integrated Gyro Error Angles that were designed to closely follow the nominal spacecraft pointing frame (Tip Frame). These angles, however, were not exactly mapped to the Tip Frame from the Body Frame. Additionally, in the initial formulation of the thruster mode attitude determination algorithms, several assumptions and approximations were made to conserve processor speed. These errors became noticeable and significant when simulating bums of much longer duration (-10 times) than had been produced in flight. A solution is proposed that uses attitude determination information from a propagated extended Kalman filter that already exists in the TRMM thruster modes. This attitude information is then used to rotate the Gyro Error Angles into the Tip Frame. An error analysis is presented that compares the two formulations. The new algorithm is tested using the TRMM High-Fidelity Simulator and verified with the TRMM Software Testing and Training Facility. Simulation results for both configurations are also presented.

DeWeese, Keith↗

Spacecraft attitude control using a smart control system

Traditionally, spacecraft attitude control has been implemented using control loops written in native code for a space hardened processor. The Naval Research Lab has taken this approach during the development of the Attitude Control Electronics (ACE) package. After the system was developed and delivered, NRL decided to explore alternate technologies to accomplish this same task more efficiently. The approach taken by NRL was to implement the ACE control loops using systems technologies. The purpose of this effort was to: (1) research capabilities required of an expert system in processing a classic closed-loop control algorithm; (2) research the development environment required to design and test an embedded expert systems environment; (3) research the complexity of design and development of expert systems versus a conventional approach; and (4) test the resulting systems against the flight acceptance test software for both response and accuracy. Two expert systems were selected to implement the control loops. Criteria used for the selection of the expert systems included that they had to run in both embedded systems and ground based environments. Using two different expert systems allowed a comparison of the real-time capabilities, inferencing capabilities, and the ground-based development environment. The two expert systems chosen for the evaluation were Spacecraft Command Language (SCL), and NEXTPERT Object. SCL is a smart control system produced for the NRL by Interface and Control Systems (ICS). SCL was developed to be used for real-time command, control, and monitoring of a new generation of spacecraft. NEXPERT Object is a commercially available product developed by Neuron Data. Results of the effort were evaluated using the ACE test bed. The ACE test bed had been developed and used to test the original flight hardware and software using simulators and flight-like interfaces. The test bed was used for testing the expert systems in a 'near-flight' environment. The technical approach, the system architecture, the development environments, knowledge base development, and results of this effort are detailed.

Buckley, Brian↗

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto- Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner-TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders.

Plattsmier, George↗

The State of NOS3

The NASA Operational Simulator for Small Satellites (NOS3) showcases some of the Jon McBride Software Testing and Research (JSTAR) laboratories technologies on an open-source platform. NOS3 is a software digital twin providing a virtualized platform inside which you have your traditional flight software, ground software, environmental simulators, and middleware to keep all pieces in sync. NOS3 leverages the core Flight System (cFS), OpenC3 COSMOS, and NASA GSFC’s 42 software as the baseline to which additional research technologies can be developed. Current technologies to be demonstrated include NOS3 Igniter, constellation support, NASA JPL’s SYNOPSIS integration, and NASA GSFC’s OnAir. NOS3 Igniter is a GUI in which you can configure, build, and run your simulation. This along with improvements to the documentation and training available open source aims to reduce the ramp up time with new users and improve accessibility. As constellations introduce another level of complexity, it is important to ensure the baseline design reference mission covers all the basics required and allows users to experiment, understand, and test at all levels of the system. The Science Yield improvement via Onboard Prioritization and Summary of Information Systems (SYNOPSIS) is an open-source tool developed by NASA JPL to enable data prioritization and planning. GSFC’s Onboard Artificial Intelligence Research (OnAIR) enables custom algorithm development written in python to interface with the flight software allowing scientists to develop what they need for the next generation of missions and easily interface back to the traditional flight software. During the presentation, a review and demonstration of the above technologies is planned along with a roadmap.

NOS3↗

Autonomous Real Time Requirements Tracing

One of the more challenging aspects of software development is the ability to verify and validate the functional software requirements dictated by the Software Requirements Specification (SRS) and the Software Detail Design (SDD). Insuring the software has achieved the intended requirements is the responsibility of the Software Quality team and the Software Test team. The utilization of Timeliner-TLX(sup TM) Auto-Procedures for relocating ground operations positions to ISS automated on-board operations has begun the transition that would be required for manned deep space missions with minimal crew requirements. This transition also moves the auto-procedures from the procedure realm into the flight software arena and as such the operational requirements and testing will be more structured and rigorous. The autoprocedures would be required to meet NASA software standards as specified in the Software Safety Standard (NASASTD- 8719), the Software Engineering Requirements (NPR 7150), the Software Assurance Standard (NASA-STD-8739) and also the Human Rating Requirements (NPR-8705). The Autonomous Fluid Transfer System (AFTS) test-bed utilizes the Timeliner-TLX(sup TM) Language for development of autonomous command and control software. The Timeliner- TLX(sup TM) system has the unique feature of providing the current line of the statement in execution during real-time execution of the software. The feature of execution line number internal reporting unlocks the capability of monitoring the execution autonomously by use of a companion Timeliner-TLX(sup TM) sequence as the line number reporting is embedded inside the Timeliner-TLX(sup TM) execution engine. This negates I/O processing of this type data as the line number status of executing sequences is built-in as a function reference. This paper will outline the design and capabilities of the AFTS Autonomous Requirements Tracker, which traces and logs SRS requirements as they are being met during real-time execution of the targeted system. It is envisioned that real time requirements tracing will greatly assist the movement of autoprocedures to flight software enhancing the software assurance of auto-procedures and also their acceptance as reliable commanders

Plattsmier, George I.↗

The Mars Global Surveyor Spacecraft Test Laboratory

The spacecraft testbed is a crucial part of the spacecraft development and operations phase. Given the aggressive schedule of the Mars Global Surveyor spacecraft, the Spacecraft Test Laboratory will play a crucial part during the MGS development phase in support of flight software testing, fault protection testing, sequence testing, and other areas to meet the November, 1996 launch date.

MGS↗

Evolution of the Hubble Space Telescope Safing Systems

The Hubble Space Telescope (HST) was launched on April 24 1990, with an expected lifespan of 15 years. Central to the spacecraft design was the concept of a series of on-orbit shuttle servicing missions permitting astronauts to replace failed equipment, update the scientific instruments and keep the HST at the forefront of astronomical discoveries. One key to the success of the Hubble mission has been the robust Safing systems designed to monitor the performance of the observatory and to react to keep the spacecraft safe in the event of equipment anomaly. The spacecraft Safing System consists of a range of software tests in the primary flight computer that evaluate the performance of mission critical hardware, safe modes that are activated when the primary control mode is deemed inadequate for protecting the vehicle, and special actions that the computer can take to autonomously reconfigure critical hardware. The HST Safing System was structured to autonomously detect electrical power system, data management system, and pointing control system malfunctions and to configure the vehicle to ensure safe operation without ground intervention for up to 72 hours. There is also a dedicated safe mode computer that constantly monitors a keep-alive signal from the primary computer. If this signal stops, the safe mode computer shuts down the primary computer and takes over control of the vehicle, putting it into a safe, low-power configuration. The HST Safing system has continued to evolve as equipment has aged, as new hardware has been installed on the vehicle, and as the operation modes have matured during the mission. Along with the continual refinement of the limits used in the safing tests, several new tests have been added to the monitoring system, and new safe modes have been added to the flight software. This paper will focus on the evolution of the HST Safing System and Safing tests, and the importance of this evolution to prolonging the science operations of the telescope.

Pepe, Joyce↗

Verification and validation testing and tools: comparison between MCNP code versions and nuclear data libraries [Slides]

This presentation discusses the primary goal of software testing which is to test the code for correctness. It also discusses the results for individual suites and the role of validation and verification also referred to in the presentation as V&V. In summation, the V&V framework enables easy comparison between calculations performed with different code versions and/or nuclear data libraries. This entire framework will be distributed with the upcoming MCNP6.3 release. V&V test suites shown and several that were not (Criticality, LAQGSM, Lockwood) will be distributed in the new framework.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

A Statistical Testing Approach for Quantifying Software Reliability; Application to an Example System

The U.S. Nuclear Regulatory Commission (NRC) encourages the use of probabilistic risk assessment (PRA) technology in all regulatory matters, to the extent supported by the state-of-the-art in PRA methods and data. Although much has been accomplished in the area of risk-informed regulation, risk assessment for digital systems has not been fully developed. The NRC established a plan for research on digital systems to identify and develop methods, analytical tools, and regulatory guidance for (1) including models of digital systems in the PRA's of nuclear power plants (NPPs), and, (2) incorporating digital systems in the NRC's risk-informed licensing and oversight activities. Under NRC's sponsorship, Brookhaven National Laboratory (BNL) explored approaches for addressing the failures of digital instrumentation and control (I and C) systems in the current NPP PRA framework. Specific areas investigated included PRA modeling digital hardware , development of a philosophical basis for defining software failure , and identification of desirable attributes of quantitative software reliability methods . Based on the earlier research, statistical testing is considered a promising method for quantifying software reliability. It is widely recognized that software failures are due to the triggering of pre-existing defects by the software's operational environment. Software defects can arise from errors made in user requirements or coding errors introduced during the developmental process. The software's operational environment includes factors such as the time history of digital system inputs, communication interfaces, the internal state of the digital system, and external conditions. Thus, software reliability is a function of both the number of pre-existing defects and the presence of a triggering condition caused by the manner in which the software is used. In this paper, we describe a statistical software-testing approach for quantifying software reliability and applied it to the loop-operating control system (LOCS) of an experimental loop of the Advanced Test Reactor (ATR) at Idaho National Laboratory (INL). The work involved collaboration between BNL and INL. The objectives of the study include: (1) Development of a statistical testing approach for estimating software failure probability on demand, the results of which are suitable for including in a probabilistic risk assessment (PRA); and, (2) Application of the approach to the LOCS to estimate its failure probability, and obtain insights into the feasibility, practicality, and usefulness of the estimation in models of digital systems for inclusion in nuclear power plants' PRAs. (authors)

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Post-test navigation data analysis techniques for the shuttle ALT

Postflight test analysis data processing techniques for shuttle approach and landing tests (ALT) navigation data are defined. Postfight test processor requirements are described along with operational and design requirements, data input requirements, and software test requirements. The postflight test data processing is described based on the natural test sequence: quick-look analysis, postflight navigation processing, and error isolation processing. Emphasis is placed on the tradeoffs that must remain open and subject to analysis until final definition is achieved in the shuttle data processing system and the overall ALT plan. A development plan for the implementation of the ALT postflight test navigation data processing system is presented. Conclusions are presented.

Source record↗

A Model for Assessing the Liability of Seemingly Correct Software

Current research on software reliability does not lend itself to quantitatively assessing the risk posed by a piece of life-critical software. Black-box software reliability models are too general and make too many assumptions to be applied confidently to assessing the risk of life-critical software. We present a model for assessing the risk caused by a piece of software; this model combines software testing results and Hamlet's probable correctness model. We show how this model can assess software risk for those who insure against a loss that can occur if life-critical software fails.

Voas, Jeffrey M.↗

Investigation of Integrated Vehicle Health Management Approaches

This report is to present the work that was performed during the summer in the Advance Computing Application office. The NFFP (NASA Faculty Fellow Program) had ten summer faculty members working on IVHM (Integrated Vehicle Health Management) technologies. The objective of this project was two-fold: 1) to become familiar with IVHM concepts and key demonstrated IVHM technologies; and 2) to integrate the research that has been performed by IVHM faculty members into the MASTLAB (Marshall Avionic Software Test Lab). IVHM is a NASA-wide effort to coordinate, integrate and apply advanced software, sensors and design technologies to increase the level of intelligence, autonomy, and health state of future vehicles. IVHM is an important concept because it is consistent with the current plan for NASA to go to the moon, mars, and beyond. In order for NASA to become more involved in deep exploration, avionic systems will need to be highly adaptable and autonomous.

Paris, Deidre↗