Results for “Software Testing” — Page 49

NASA NTRS1976

Analysis of test data on the simplex strapdown navigation system

The results of a study of test data taken on the simplex strapdown navigation system were presented. That system consisted of the following components: strapdown platform, altimeter, digital computer, tape recorder, typewriter, and power source. The objective of these tests was to isolate error sources which may cause degradation of the system's accuracy and to recommend appropriate changes to the system test procedures or computer software. The following recommendations were made: (1) addition of a gyro compassing alignment program into the navigation program, (2) addition of line drivers at the signal processor end of the transmission line, (3) need for extensive laboratory testing to determine sensor misalignments, biases, and scale factors, (4) need to stabilize the power source to prevent transients during power transfer, (5) need to isolate and eliminate the source of the large noise inputs.

Source record↗

NASA NTRS1989

Hardware impacts to software development strategies - The history of the development of the Mars Observer Payload Data Subsystem embedded real-time software

Ways in which parallel hardware development and high level requirements changes have influenced Mars Observer Payload Data Subsystem (PDS) flight software development are discussed. Particular attention is given to ways in which the evolving hardware product and changing requirements have led to repeated modification to software requirements, design, code, and test tools and a delay in the closure of corresponding phases of the software development life cycle. Design and implementation problems which were encountered during the PDS software development effort are described.

Elson, Anne B.↗

NASA NTRS1976

Time Series Analysis in Flight Flutter Testing at the Air Force Flight Test Center: Concepts and Results

The Air Force Flight Test Center (AFFTC) flight flutter facility is described. Concepts of using a minicomputer-based time series analyzer and a modal analysis software package for flight flutter testing are examined. The results of several evaluations of the software package are given. The reasons for employing a minimum phase concept in analyzing response only signals are discussed. The use of a Laplace algorithm is shown to be effective for the modal analysis of time histories in flutter testing. Sample results from models and flight tests are provided. The limitations inherent in time series analysis methods are discussed, and the need for effective noise reduction techniques is noted. The use of digital time series analysis techniques in flutter testing is shown to be fast, accurate, and cost effective.

Lenz, R. W.↗

NASA NTRS1994

A study of a multi-pinned phase CCD detector for use as a star tracker

This grant has supported studies of the use of charge coupled devices (CCD's) in star trackers in a number of different areas. Among the tasks we have pursued are the following: (1) radiation modeling and the increase in noise equivalent angle as a result of exposure to protons and bremsstrahlung gamma rays; (2) the development of pattern matching software to identify field locations from a CCD image and a pre-existing map of the local area; (3) observations of various stellar fields from the 24 inch telescope at the Offit Observatory at JHU, primarily to test the pattern matching software (these included crowded fields as well as moving objects, like comets); and (4) tracking of very faint objects to determine the faint limit of the CCD system.

Friedman, Scott D.↗

NASA NTRS2016

Liquid Oxygen/Liquid Methane Integrated Power and Propulsion

The proposed paper will cover ongoing work at the National Aeronautics and Space Administration (NASA) Johnson Space Center (JSC) on integrated power and propulsion for advanced human exploration. Specifically, it will present findings of the integrated design, testing, and operational challenges of a liquid oxygen / liquid methane (LOx/LCH4) propulsion brassboard and Solid Oxide Fuel Cell (SOFC) system. Human-Mars architectures point to an oxygen-methane economy utilizing common commodities, scavenged from the planetary atmosphere and soil via In-Situ Resource Utilization (ISRU), and common commodities across sub-systems. Due to the enormous mass gear-ratio required for human exploration beyond low-earth orbit, (for every 1 kg of payload landed on Mars, 226 kg will be required on Earth) increasing commonality between spacecraft subsystems such as power and propulsion can result in tremendous launch mass and volume savings. Historically, propulsion and fuel cell power subsystems have had little interaction outside of the generation (fuel cell) and consumption (propulsion) of electrical power. This was largely due to a mismatch in preferred commodities (hypergolics for propulsion; oxygen & hydrogen for fuel cells). Although this stove-piped approach benefits from simplicity in the design process, it means each subsystem has its own tanks, pressurization system, fluid feed system, etc. increasing overall spacecraft mass and volume. A liquid oxygen / liquid methane commodities architecture across propulsion and power subsystems would enable the use of common tankage and associated pressurization and commodity delivery hardware for both. Furthermore, a spacecraft utilizing integrated power and propulsion could use propellant residuals - propellant which could not be expelled from the tank near depletion due to hydrodynamic considerations caused by large flow demands of a rocket engine - to generate power after all propulsive maneuvers are complete thus utilizing previously wasted mass. Such is the case for human and robotic planetary landers. Although many potential benefits through integrated power & propulsion exist, integrated operations have yet to be successfully demonstrated and many challenges have already been identified the most obvious of which is the large temperature gradient. SOFC chemistry is exothermic with operating temperatures in excess of 1,000 K; however, any shared commodities will be undoubtedly stored at cryogenic temperatures (90-112 K) for mass efficiency reasons. Spacecraft packaging will drive these two subsystems in close proximity thus heat leak into the commodity tankage must be minimized and/or mitigated. Furthermore, commodities must be gasified prior to consumption by the SOFC. Excess heat generated by the SOFC could be used to perform this phase change; however, this has yet to be demonstrated. A further identified challenge is the ability of the SOFC to handle the sudden power spikes created by the propulsion system. A power accumulator (battery) will likely be necessary to handle these sudden demands while the SOFC thermally adjusts. JSC's current SOFC test system consists of a 1 kW fuel cell designed by Delphi. The fuel cell is currently undergoing characterization testing at the NASA JSC Energy Systems Test Area (ESTA) after which a Steam Methane Reformer (SMR) will be integrated and the combined system tested in closed-loop. The propulsion brassboard is approximately the size of what could be flown on a sounding rocket. It consists of one 100 lbf thrust "main" engine developed for NASA by Aerojet and two 10 lbf thrusters to simulate a reaction control system developed at NASA JSC. This system is also under development and initial testing at ESTA. After initial testing, combined testing will occur which will provide data on the fuel cell's ability to sufficiently handle the power spikes created by the propulsion system. These two systems will also be modeled using General-Use Nodal Network Solver (GUNNS) software. Once anchored with test data, this model will be used to extrapolate onto other firing profiles and used to size the power accumulator.

Banker, Brian↗

NASA NTRS2016

Experimenting Galileo on Board the International Space Station

The SCaN Testbed is an advanced integrated communications system and laboratory facility installed on the International Space Station (ISS) in 2012. The testbed incorporates a set of new generation of Software Defined Radio (SDR) technologies intended to allow researchers to develop, test, and demonstrate new communications, networking, and navigation capabilities in the actual environment of space. Qascom, in cooperation with ESA and NASA, is designing a Software Defined Radio GalileoGPS Receiver capable to provide accurate positioning and timing to be installed on the ISS SCaN Testbed. The GalileoGPS waveform will be operated in the JPL SDR that is constituted by several hardware components that can be used for experimentations in L-Band and S-Band. The JPL SDR includes an L-Band Dorne Margolin antenna mounted onto a choke ring. The antenna is connected to a radio front end capable to provide one bit samples for the three GNSS frequencies (L1, L2 and L5) at 38 MHz, exploiting the subharmonic sampling. The baseband processing is then performed by an ATMEL AT697 processor (100 MIPS) and two Virtex 2 FPGAs. The JPL SDR supports the STRS (Space Telecommunications Radio System) that provides common waveform software interfaces, methods of instantiation, operation, and testing among different compliant hardware and software products. The standard foresees the development of applications that are modular, portable, reconfigurable, and reusable. The developed waveform uses the STRS infrastructure-provided application program interfaces (APIs) and services to load, verify, execute, change parameters, terminate, or unload an application. The project is divided in three main phases. 1)Design and Development of the GalileoGPS waveform for the SCaN Testbed starting from Qascom existing GNSS SDR receiver. The baseline design is limited to the implementation of the single frequency Galileo and GPS L1E1 receiver even if as part of the activity it will be to assess the feasibility of a dual frequency implementation (L1E1+L5E5a) in the same SDR platform.2)Qualification and test the GalileoGPS waveform using ground systems available at the NASA Glenn Research Center. Experimenters can have access to two SCaN Testbed ground based systems for development and verification: the Experimenter Development System (EDS) that is intended to provide initial opportunity for software testing and basic functional validation and the Ground Integration Unit (GIU) that is a high fidelity version of the SCaN Testbed flight system and is therefore used for more controlled final development testing and verification testing.3)Perform in-orbit validation and experimentation: The experimentation phase will consists on the collection of raw measurements (pseudorange, Carrier phase, CN0) in space, assessment on the quality of the measurements and the receiver performances in terms of signal acquisition, tracking, etc. Finally computation of positioning in space (Position, Velocity and time) and assessment of its performance.(Complete abstract in attached document).

Galileo↗

NASA NTRS2016

Experimenting Galileo on Board the International Space Station

The SCaN Testbed is an advanced integrated communications system and laboratory facility installed on the International Space Station (ISS) in 2012. The testbed incorporates a set of new generation of Software Defined Radio (SDR) technologies intended to allow researchers to develop, test, and demonstrate new communications, networking, and navigation capabilities in the actual environment of space. Qascom, in cooperation with ESA and NASA, is designing a Software Defined Radio GalileoGPS Receiver capable to provide accurate positioning and timing to be installed on the ISS SCaN Testbed. The GalileoGPS waveform will be operated in the JPL SDR that is constituted by several hardware components that can be used for experimentations in L-Band and S-Band. The JPL SDR includes an L-Band Dorne Margolin antenna mounted onto a choke ring. The antenna is connected to a radio front end capable to provide one bit samples for the three GNSS frequencies (L1, L2 and L5) at 38 MHz, exploiting the subharmonic sampling. The baseband processing is then performed by an ATMEL AT697 processor (100 MIPS) and two Virtex 2 FPGAs. The JPL SDR supports the STRS (Space Telecommunications Radio System) that provides common waveform software interfaces, methods of instantiation, operation, and testing among different compliant hardware and software products. The standard foresees the development of applications that are modular, portable, reconfigurable, and reusable. The developed waveform uses the STRS infrastructure-provided application program interfaces (APIs) and services to load, verify, execute, change parameters, terminate, or unload an application. The project is divided in three main phases. 1)Design and Development of the GalileoGPS waveform for the SCaN Testbed starting from Qascom existing GNSS SDR receiver. The baseline design is limited to the implementation of the single frequency Galileo and GPS L1E1 receiver even if as part of the activity it will be to assess the feasibility of a dual frequency implementation (L1E1+L5E5a) in the same SDR platform.2)Qualification and test the GalileoGPS waveform using ground systems available at the NASA Glenn Research Center. Experimenters can have access to two SCaN Testbed ground based systems for development and verification: the Experimenter Development System (EDS) that is intended to provide initial opportunity for software testing and basic functional validation and the Ground Integration Unit (GIU) that is a high fidelity version of the SCaN Testbed flight system and is therefore used for more controlled final development testing and verification testing.3)Perform in-orbit validation and experimentation: The experimentation phase will consists on the collection of raw measurements (pseudorange, Carrier phase, CN0) in space, assessment on the quality of the measurements and the receiver performances in terms of signal acquisition, tracking, etc. Finally computation of positioning in space (Position, Velocity and time) and assessment of its performance.(Complete abstract in attached document).

GPS↗

NASA NTRS2013

Final Report - Regulatory Considerations for Adaptive Systems

This report documents the findings of a preliminary research study into new approaches to the software design assurance of adaptive systems. We suggest a methodology to overcome the software validation and verification difficulties posed by the underlying assumption of non-adaptive software in the requirementsbased- testing verification methods in RTCA/DO-178B and C. An analysis of the relevant RTCA/DO-178B and C objectives is presented showing the reasons for the difficulties that arise in showing satisfaction of the objectives and suggested additional means by which they could be satisfied. We suggest that the software design assurance problem for adaptive systems is principally one of developing correct and complete high level requirements and system level constraints that define the necessary system functional and safety properties to assure the safe use of adaptive systems. We show how analytical techniques such as model based design, mathematical modeling and formal or formal-like methods can be used to both validate the high level functional and safety requirements, establish necessary constraints and provide the verification evidence for the satisfaction of requirements and constraints that supplements conventional testing. Finally the report identifies the follow-on research topics needed to implement this methodology.

Wilkinson, Chris↗

NASA NTRS2007

Triaxial Probe Magnetic Data Analysis

The Triaxial Magnetic Moment Analysis software uses measured magnetic field test data to compute dipole and quadrupole moment information from a hardware element. It is used to support JPL projects needing magnetic control and an understanding of the spacecraft-generated magnetic fields. Evaluation of the magnetic moment of an object consists of three steps: acquisition, conditioning, and analysis. This version of existing software was extensively rewritten for easier data acquisition, data analysis, and report presentation, including immediate feedback to the test operator during data acquisition. While prior JPL computer codes provided the same data content, this program has a better graphic display including original data overlaid with reconstructed results to show goodness of fit accuracy and better appearance of the report graphic page. Data are acquired using three magnetometers and two rotations of the device under test. A clean acquisition user interface presents required numeric data and graphic summaries, and the analysis module yields the best fit (least squares) for the magnetic dipole and/or quadrupole moment of a device. The acquisition module allows the user to record multiple data sets, selecting the best data to analyze, and is repeated three times for each of the z-axial and y-axial rotations. In this update, the y-axial rotation starting position has been changed to an option, allowing either the x- or z-axis to point towards the magnetometer. The code has been rewritten to use three simultaneous axes of magnetic data (three probes), now using two "rotations" of the device under test rather than the previous three rotations, thus reducing handling activities on the device under test. The present version of the software gathers data in one-degree increments, which permits much better accuracy of the fit ted data than the coarser data acquisition of the prior software. The data-conditioning module provides a clean data set for the analysis module. For multiple measurements at a given degree, the first measurement is used. For omitted measurements, the missing field is estimated by linear interpolation between the two nearest measurements. The analysis module was rewritten for the dual rotation, triaxial probe measurement process and now has better moment estimation accuracy, based on the finer one degree of data acquisition resolution. The magnetic moments thus computed are used as an input to summarize the total spacecraft field.

Shultz, Kimberly↗

NASA NTRS1998

Antiterrorist Software

In light of the escalation of terrorism, the Department of Defense spearheaded the development of new antiterrorist software for all Government agencies by issuing a Broad Agency Announcement to solicit proposals. This Government-wide competition resulted in a team that includes NASA Lewis Research Center's Computer Services Division, who will develop the graphical user interface (GUI) and test it in their usability lab. The team launched a program entitled Joint Sphere of Security (JSOS), crafted a design architecture (see the following figure), and is testing the interface. This software system has a state-ofthe- art, object-oriented architecture, with a main kernel composed of the Dynamic Information Architecture System (DIAS) developed by Argonne National Laboratory. DIAS will be used as the software "breadboard" for assembling the components of explosions, such as blast and collapse simulations.

Clark, David A.↗

DOE OSTI2024

Julienne v1.0.0

Julienne is a compiler-portable unit-testing framework for Fortran software projects, including those that use the parallel/accelerator-programming features of Fortran 2023. Julienne achieves portability across compilers through minimalism and isolation. The minimal design ensures that Julienne uses only features supported by the majority of Fortran compilers. The isolation through zero dependencies ensures that no other projects block Julienne from building with a particular compiler. Julienne also contains with additional services that support its unit-testing code. These include functions for manipulating strings, command lines and input/output format strings; and a user-defined collective subroutine for verifying that all processes pass a test in parallel testing. Julienne's name derives from the term for vegetables sliced into thin strings: julienne vegetables. Julienne captures the authors' most frequently used thin slice of the Veggies and Sourcery software repositories while avoiding certain compiler limitations of the those two packages.

Rouson, Damian↗

NASA NTRS1993

From requirements to acceptance tests

From user requirements definition to accepted software system, the software project management wants to be sure that the system will meet the requirements. For the development of a telecommunication satellites Control Centre, C.N.E.S. has used new rules to make the use of tracing matrix easier. From Requirements to Acceptance Tests, each item of a document must have an identifier. A unique matrix traces the system and allows the tracking of the consequences of a change in the requirements. A tool has been developed, to import documents into a relational data base. Each record of the data base corresponds to an item of a document, the access key is the item identifier. Tracing matrix is also processed, providing automatically links between the different documents. It enables the reading on the same screen of traced items. For example one can read simultaneously the User Requirements items, the corresponding Software Requirements items and the Acceptance Tests.

Baize, Lionel↗

NASA NTRS2007

Programs for Testing an SSME-Monitoring System

A suite of computer programs has been developed for special test equipment (STE) that is used in verification testing of the Health Management Computer Integrated Rack Assembly (HMCIRA), a ground-based system of analog and digital electronic hardware and software for "flight-like" testing for development of components of an advanced health-management system for the space shuttle main engine (SSME). The STE software enables the STE to simulate the analog input and the data flow of an SSME test firing from start to finish.

Lang, Andre↗

NASA NTRS2020

Integrated Demand Management: CTOP User Interface Enhancements

NASA's Integrated Demand Management research activity developed a concept for a novel use of the FAA's Collaborative Trajectory Options Program (CTOP) decision support software to support a particular type of traffic management use case. The research team used an emulation of CTOP software to prototype and test the concept, and developed several enhancements to the CTOP user interface that were well received by the stakeholder community. This document provides a detailed description of these enhancements and their operation that could be used to support their incorporation into the official CTOP software.

IDM↗

NASA NTRS1993

The infeasibility of quantifying the reliability of life-critical real-time software

This paper affirms that the quantification of life-critical software reliability is infeasible using statistical methods, whether these methods are applied to standard software or fault-tolerant software. The classical methods of estimating reliability are shown to lead to exorbitant amounts of testing when applied to life-critical software. Reliability growth models are examined and also shown to be incapable of overcoming the need for excessive amounts of testing. The key assumption of software fault tolerance - separately programmed versions fail independently - is shown to be problematic. This assumption cannot be justified by experimentation in the ultrareliability region, and subjective arguments in its favor are not sufficiently strong to justify it as an axiom. Also, the implications of the recent multiversion software experiments support this affirmation.

Butler, Ricky W.↗

NASA NTRS1991

The Infeasibility of Quantifying the Reliability of Life-Critical Real-Time Software

This paper affirms that the quantification of life-critical software reliability is infeasible using statistical methods whether applied to standard software or fault-tolerant software. The classical methods of estimating reliability are shown to lead to exhorbitant amounts of testing when applied to life-critical software. Reliability growth models are examined and also shown to be incapable of overcoming the need for excessive amounts of testing. The key assumption of software fault tolerance separately programmed versions fail independently is shown to be problematic. This assumption cannot be justified by experimentation in the ultrareliability region and subjective arguments in its favor are not sufficiently strong to justify it as an axiom. Also, the implications of the recent multiversion software experiments support this affirmation.

Butler, Ricky W.↗

NASA NTRS2010

NASA-DoD Lead-Free Electronics Project: Vibration Test

Vibration testing was conducted by Boeing Research and Technology (Seattle) for the NASA-DoD Lead-Free Electronics Solder Project. This project is a follow-on to the Joint Council on Aging Aircraft/Joint Group on Pollution Prevention (JCAA/JG-PP) Lead-Free Solder Project which was the first group to test the reliability of lead-free solder joints against the requirements of the aerospace/miLItary community. Twenty seven test vehicles were subjected to the vibration test conditions (in two batches). The random vibration Power Spectral Density (PSD) input was increased during the test every 60 minutes in an effort to fail as many components as possible within the time allotted for the test. The solder joints on the components were electrically monitored using event detectors and any solder joint failures were recorded on a Labview-based data collection system. The number of test minutes required to fail a given component attached with SnPb solder was then compared to the number of test minutes required to fail the same component attached with lead-free solder. A complete modal analysis was conducted on one test vehicle using a laser vibrometer system which measured velocities, accelerations, and displacements at one . hundred points. The laser vibrometer data was used to determine the frequencies of the major modes of the test vehicle and the shapes of the modes. In addition, laser vibrometer data collected during the vibration test was used to calculate the strains generated by the first mode (using custom software). After completion of the testing, all of the test vehicles were visually inspected and cross sections were made. Broken component leads and other unwanted failure modes were documented.

Woodrow, Thomas A.↗

DOE OSTI2025

Software Quality Assurance for the MOOSE-Based Open-Source Multiphysics Code Cardinal - An Expanded CI Testing Suite

Cardinal is a wrapping of the GPU-oriented spectral element Computational Fluid Dynamics (CFD) code NekRS and the Monte Carlo particle transport code OpenMC within the Multiphysics Object-Oriented Simulation Environment (MOOSE). Cardinal provides high-resolution thermal-hydraulics and/or radiation transport feedback to MOOSE multiphysics simulations. Multiphysics feedback is implemented in a geometry-agnostic manner which eliminates the need for rigid one-to-one mappings. A generic data transfer implementation also allows NekRS and OpenMC to couple to any MOOSE application, enabling a broad set of multiphysics capabilities. Cardinal simulations can also leverage combinations of MPI, OpenMP, and GPU resources. Cardinal continuous development and improvement efforts have led to the software being considered as a high-fidelity design and licensing tool for key areas of nuclear reactor relevant physics, including neutron transport, fluid flow, heat transfer, and mechanical processes. The fast development and expansion of the software from a pure R&D framework towards its application in the nuclear industry and regulation require a focus on developing, enhancing and, maintaining Cardinal’s software quality through strict adherence to a Software Quality Assurance (SQA) framework and SQA program. To facilitate compliance with SQA standards, the Cardinal SQA Program has been initiated during Fiscal Year 2023 (FY23). During the development of the Cardinal SQA Program, multiple gaps have been identified. These gaps are primarily related to model verification and code pedigree as they relate to the use of Cardinal as a safety analysis tool. These gaps have been captured in a report published in 2023. A second report highlighted the progress made during Fiscal Year 2024 (FY24) and described Argonne’s effort to document and integrate software verification within Cardinal’s software development process. This report documents a snapshot of the verification test cases currently available for Cardinal and NekRS in their assimilation into a Continuous Integration (CI) platform. Following the CI practice permits the integrating of source code changes frequently and ensuring that the integrated codebase clears the verification testing for the software. It should be noted that the SQA program itself, including the program plans, procedures, configuration management, and testing strategies, need to be developed in a future step of this task.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗