Search NASA⌕ Search

SEARCH · Search NASA

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 505 records · Page 28

SpaceHab 1 maintenance experiment

The SpaceHab 1 flight on STS-57 served as a test platform for evaluation of two space station payloads. The first payload evaluated a space station maintenance concept using a sweep signal generator and a 48-channel logic analyzer to perform fault detection and isolation. Crew procedures files, test setup diagram files, and software to configure the test equipment were created on the ground and uplinked on the astronauts' voice communication circuit to perform tests in flight. In order to use these files, the portable computer was operated in a multi-window configuration. The test data transmitted to the ground allowing the ground staff to identify the cause of the fault and provide the crew with the repair procedures and diagrams. The crew successfully repaired the system under test. The second payload investigated hand soldering and de-soldering of standard components on printed circuit (PC) boards in zero gravity. It also used a new type of intra-vehicular foot restraints which uses the neutral body posture in zero-g to provide retention of the crew without their conscious attention.

Bohannon, Jackie W.↗

System for Automated Calibration of Vector Modulators

Vector modulators are used to impose baseband modulation on RF signals, but non-ideal behavior limits the overall performance. The non-ideal behavior of the vector modulator is compensated using data collected with the use of an automated test system driven by a LabVIEW program that systematically applies thousands of control-signal values to the device under test and collects RF measurement data. The technology innovation automates several steps in the process. First, an automated test system, using computer controlled digital-to-analog converters (DACs) and a computer-controlled vector network analyzer (VNA) systematically can apply different I and Q signals (which represent the complex number by which the RF signal is multiplied) to the vector modulator under test (VMUT), while measuring the RF performance specifically, gain and phase. The automated test system uses the LabVIEW software to control the test equipment, collect the data, and write it to a file. The input to the Lab - VIEW program is either user-input for systematic variation, or is provided in a file containing specific test values that should be fed to the VMUT. The output file contains both the control signals and the measured data. The second step is to post-process the file to determine the correction functions as needed. The result of the entire process is a tabular representation, which allows translation of a desired I/Q value to the required analog control signals to produce a particular RF behavior. In some applications, corrected performance is needed only for a limited range. If the vector modulator is being used as a phase shifter, there is only a need to correct I and Q values that represent points on a circle, not the entire plane. This innovation has been used to calibrate 2-GHz MMIC (monolithic microwave integrated circuit) vector modulators in the High EIRP Cluster Array project (EIRP is high effective isotropic radiated power). These calibrations were then used to create correction tables to allow the commanding of the phase shift in each of four channels used as a phased array for beam steering of a Ka-band (32-GHz) signal. The system also was the basis of a breadboard electronic beam steering system. In this breadboard, the goal was not to make systematic measurements of the properties of a vector modulator, but to drive the breadboard with a series of test patterns varying in phase and amplitude. This is essentially the same calibration process, but with the difference that the data collection process is oriented toward collecting breadboard performance, rather than the measurement of output from a network analyzer.

Lux, James↗

Intern Abstract for Spring 2016

The Human Interface Branch - EV3 - is evaluating Organic lighting-emitting diodes (OLEDs) as an upgrade for current displays on future spacecraft. OLEDs have many advantages over current displays. Conventional displays require constant backlighting which draws a lot of power, but with OLEDs they generate light themselves. OLEDs are lighter, and weight is always a concern with space launches. OLEDs also grant greater viewing angles. OLEDs have been in the commercial market for almost ten years now. What is not known is how they will perform in a space-like environment; specifically deep space far away from the Earth's magnetosphere. In this environment, the OLEDs can be expected to experience vacuum and galactic radiation. The intern's responsibility has been to prepare the OLED for a battery of tests. Unfortunately, it will not be ready for testing at the end of the internship. That being said much progress has been made: a) Developed procedures to safely disassemble the tablet. b) Inventoried and identified critical electronic components. c) 3D printed a testing apparatus. d) Wrote software in Python that will test the OLED screen while being radiated. e) Built circuits to restart the tablet and the test pattern, and ensure it doesn't fall asleep during radiation testing. f) Built enclosure that will house all of the electronics Also, the intern has been working on a way to take messages from a simulated Caution and Warnings system, process said messages into packets, send audio packets to a multicast address that audio boxes are listening to, and output spoken audio. Currently, Cautions and Warnings use a tone to alert crew members of a situation, and then crew members have to read through their checklists to determine what the tone means. In urgent situations, EV3 wants to deliver concise and specific alerts to the crew to facilitate any mitigation efforts on their part. Significant progress was made on this project: a) Open channel with the simulated Caution and Warning system to acquire messages. b) Configure audio boxes. c) Grab pre-recorded audio files. d) Packetize the audio stream. A third project that was assigned to implement LED indicator modules for an Omnibus project. The Omnibus project is investigating better ways designing lighting for the interior of spacecraft-both spacecraft lighting and avionics box status lighting indication. The current scheme contains too much of the blue light spectrum that disrupts the sleep cycle. The LED indicator modules are to simulate the indicators running on a spacecraft. Lighting data will be gathered by human factors personal and use in a model underdevelopment to model spacecraft lighting. Significant progress was made on this project: Designed circuit layout a) Tested LEDs at LETF. b) Created GUI for the indicators. c) Created code for the Arduino to run that will illuminate the indicator modules.

Gibson, William↗

Fitting Leak Test Report: Ground-Based Cryogenic Leak Test of Fittings for Cryogenic Fluid Management

EXECUTIVE SUMMARY Mechanically connected joints used in cryogenic fluid lines as part of space flight elements need to survive launch vibrations and remain leak-free to minimize the loss of on-board commodity and hazardous gas accumulation. In 2020, a cryogenic test apparatus was developed which can evaluate the leak performance of pressurized threaded fluid fittings. The fittings were mounted in the TVAC and cooled to cryogenic test temperature and pressurized with helium while the leak rate was measured using a calibrated GHe leak detector. The test articles for the initial proof of concept testing were ¼ and 1 inch Swagelok VCR fittings with three different types of seal rings copper, nickel, and Ni. Each fitting configuration (size/seal material) was subjected to two consecutive cryogenic thermal cycles, followed by exposure to a launch vibration profile at ambient temperature, after which two additional TVAC cycle tests were performed. The testing reported here is a continuation of the 2020 tests with a statistically significant large number of samples and test runs. Three Swagelok VCR fitting sizes were tested ¼, ½ and 1 inch, and five (5) samples of each fitting size, each sample was tested with SST and Ni seal rings (Total of 30 unique test articles). Each test article was subjected to four (4) thermal cycles. Half of these cycles were performed before vibration testing and half were performed after vibration testing. The vibration testing was performed to evaluate the ability of the fittings to survive launch-type vibration profiles and remain leak-free. Leak checking of each fitting was completed at temperatures between 20K – 30K. The test procedure in Section 8.0 was designed to facilitate a qualification test program by allowing a higher test throughput rate coupled with repeatable test profiles. Results were very positive and show that out of the 30 samples they all passed with leak rates a factor of 2-3 lower than the established 10-6sccs GHe leak threshold. The result showed the Ni seals had lower leak rate, but the SST was more rugged. There were two deviations where damage to the Ni seal ring during assembly resulted in a leaky fitting, this is discussed in Section 10.7 Test Deviations. These fittings show great promise for space flight use and further testing is recommended to fully qualify the fittings per the ASTM F1387-19 and/or other relevant NASA specifications. The test equipment hardware and software capability developed for this testing is generic and not restricted to VCR fittings. It can be employed to evaluate/qualify the leak performance of other types of fittings and a wide range of other cryogenic fluid components such as valves, gages, connectors, etc.

Cryogenic↗

Digital flight control for the NASA 737 airplane

A brief description of the hardware and software for the digital flight control computers for the NASA 737 airplane is given. Software modules include the basic executive, scheduler, redundancy management, software signal selection, system test, mode logic, pitch axis flight control program and the lateral axis flight control program. A more detailed description of the software development effort is given for the digital flight control software. The software development tasks discussed are: software requirements, development, documentation, control, lab evaluation and formal lab tests. The software development costs are identified and conclusions are drawn concerning the software development effort required to support digital flight control for commercial jet transport applications.

Malcom, L. G.↗

Application of industry-standard guidelines for the validation of avionics software

The application of industry standards to the development of avionics software is discussed, focusing on verification and validation activities. It is pointed out that the procedures that guide the avionics software development and testing process are under increased scrutiny. The DO-178A guidelines, Software Considerations in Airborne Systems and Equipment Certification, are used by the FAA for certifying avionics software. To investigate the effectiveness of the DO-178A guidelines for improving the quality of avionics software, guidance and control software (GCS) is being developed according to the DO-178A development method. It is noted that, due to the extent of the data collection and configuration management procedures, any phase in the life cycle of a GCS implementation can be reconstructed. Hence, a fundamental development and testing platform has been established that is suitable for investigating the adequacy of various software development processes. In particular, the overall effectiveness and efficiency of the development method recommended by the DO-178A guidelines are being closely examined.

Hayhurst, Kelly J.↗

An experiment in software reliability

The results of a software reliability experiment conducted in a controlled laboratory setting are reported. The experiment was undertaken to gather data on software failures and is one in a series of experiments being pursued by the Fault Tolerant Systems Branch of NASA Langley Research Center to find a means of credibly performing reliability evaluations of flight control software. The experiment tests a small sample of implementations of radar tracking software having ultra-reliability requirements and uses n-version programming for error detection, and repetitive run modeling for failure and fault rate estimation. The experiment results agree with those of Nagel and Skrivan in that the program error rates suggest an approximate log-linear pattern and the individual faults occurred with significantly different error rates. Additional analysis of the experimental data raises new questions concerning the phenomenon of interacting faults. This phenomenon may provide one explanation for software reliability decay.

Dunham, J. R.↗

Collected software engineering papers, volume 3

Topics addressed include: software technology evaluation programs; collection of valid software engineering data; test processes using structural coverage; prototype expert system for software engineering management; use of an environment characteristic software metric set; software modulation; software development by analysis of change; and independent verification and validation.

Source record↗

TAXI Direct-to-Disk Interface Demultiplexes Proprietarily Formatted Data

The TAXI Direct-to-Disk interface is a special-purpose interface circuit for demultiplexing of data from a Racal Storeplex (or equivalent) multichannel recorder onto one or more hard disks that reside in, and/or are controlled by, a personal computer (PC). (The name TAXI as used here is derived from the acronym TAXI, which signifies transparent asynchronous transceiver interface.) The TAXI Direct-to-Disk interface was developed for original use in capturing data from instrumentation on a test stand in a NASA rocket-testing facility. The control, data-recording, and data-postprocessing equipment of the facility are located in a control room at a safe distance from the test stand. Heretofore, the transfer of data from the instrumentation to the postprocessing equipment has entailed post-test downloading via software, requiring many hours to days of post-test reduction before the data could be viewed in a channelized format. The installation of the TAXI Direct-to-Disk interface, in conjunction with other modifications, causes the transfer of data to take place in real time, so that the data are immediately available for review during or after the test. The instrumentation is connected to the input terminals of the signal-processing unit of multichannel recorder by standard coaxial cables. The coaxial output of the signal processing unit is converted to fiber-optic output by means of a commercial coaxial-cable/fiber-optic converter (that is, a fiber-optic transceiver) designed specifically for this application. The fiber-optic link carries the data signals to an identical fiber-optic transceiver in the control room. On the way to the TAXI Direct-to-Disk interface that is the focus of this article, the data signals are processed through a companion special purpose circuit denoted by the similar name parallel TAXI interface.

Newnan, Bruce G.↗

Optical Testing and Verification Methods for the James Webb Space Telescope Integrated Science Instrument Module Element

NASA's James Webb Space Telescope (JWST) is a 6.6m diameter, segmented, deployable telescope for cryogenic IR space astronomy (~40K). The JWST Observatory includes the Optical Telescope Element (OTE) and the Integrated Science Instrument Module (ISIM) that contains four science instruments (SI) and the fine guider. The SIs are mounted to a composite metering structure. The SI and guider units were integrated to the ISIM structure and optically tested at the NASA Goddard Space Flight Center as a suite using the Optical Telescope Element SIMulator (OSIM). OSIM is a full field, cryogenic JWST telescope simulator. SI performance, including alignment and wave front error, were evaluated using OSIM. We describe test and analysis methods for optical performance verification of the ISIM Element, with an emphasis on the processes used to plan and execute the test. The complexity of ISIM and OSIM drove us to develop a software tool for test planning that allows for configuration control of observations, associated scripts, and management of hardware and software limits and constraints, as well as tools for rapid data evaluation, and flexible re-planning in response to the unexpected. As examples of our test and analysis approach, we discuss how factors such as the ground test thermal environment are compensated in alignment. We describe how these innovative methods for test planning and execution and post-test analysis were instrumental in the verification program for the ISIM element, with enough information to allow the reader to consider these innovations and lessons learned in this successful effort in their future testing for other programs.

spaceborne telescopes↗

Acoustic Emission Analysis Applet (AEAA) Software

NASA Glenn Research and NASA White Sands Test Facility have developed software supporting an automated pressure vessel structural health monitoring (SHM) system based on acoustic emissions (AE). The software, referred to as the Acoustic Emission Analysis Applet (AEAA), provides analysts with a tool that can interrogate data collected on Digital Wave Corp. and Physical Acoustics Corp. software using a wide spectrum of powerful filters and charts. This software can be made to work with any data once the data format is known. The applet will compute basic AE statistics, and statistics as a function of time and pressure (see figure). AEAA provides value added beyond the analysis provided by the respective vendors' analysis software. The software can handle data sets of unlimited size. A wide variety of government and commercial applications could benefit from this technology, notably requalification and usage tests for compressed gas and hydrogen-fueled vehicles. Future enhancements will add features similar to a "check engine" light on a vehicle. Once installed, the system will ultimately be used to alert International Space Station crewmembers to critical structural instabilities, but will have little impact to missions otherwise. Diagnostic information could then be transmitted to experienced technicians on the ground in a timely manner to determine whether pressure vessels have been impacted, are structurally unsound, or can be safely used to complete the mission.

Nichols, Charles T.↗

Seeing the Invisible: Embedding Tests in Code That Cannot be Modified

The difficulty of characterizing and observing valid software behavior during testing can be very difficult in flight systems. To address this issue, we evaluated several approaches to increasing test observability on the Shuttle Abort Flight Management (SAFM) system. To increase test observability, we added probes into the running system to evaluate the internal state and analyze test data. To minimize the impact of the instrumentation and reduce manual effort, we used Aspect-Oriented Programming (AOP) tools to instrument the source code. We developed and elicited a spectrum of properties, from generic to application specific properties, to be monitored via the instrumentation. To evaluate additional approaches, SAFM was ported to Linux, enabling the use of gcov for measuring test coverage, Valgrind for looking for memory usage errors, and libraries for finding non-normal floating point values. An in-house C++ source code scanning tool was also used to identify violations of SAFM coding standards, and other potentially problematic C++ constructs. Using these approaches with the existing test data sets, we were able to verify several important properties, confirm several problems and identify some previously unidentified issues.

O'Malley, Owen↗

Achieving dependability throughout the development process - A distributed software experiment

Distributed software engineering techniques and methods for improving the specification and testing phases are considered. With multiversion development, multiple implementations allow the use of an automated approach to testing called back-to-back (B/B) testing in which the outputs are compared to detect any discrepancies. However, a specification defect may lead to similar errors in the multiple versions and the underlying fault may not be detected with a B/B testing approach. The use of diverse formal specifications has been proposed as a solution to this problem, since defects in independently written specifications are likely to be different. To examine these issues, an experiment was performed using the design diversity approach in the specification, design, implementation, and testing of distributed software. In the experiment, three diverse formal specifications were used to produce multiple independent implementations of a distributed communication protocol in Ada. The problems encountered in building complex concurrent processing systems in Ada were also studied. Many pitfalls were discovered in mapping the formal specifications into Ada implementations.

Kelly, John P. J.↗

Automation of the Environmental Control and Life Support System

The objective of the Environmental Control and Life Support System (ECLSS) Advanced Automation Project is to recommend and develop advanced software for the initial and evolutionary Space Station Freedom (SSF) ECLS system which will minimize the crew and ground manpower needed for operations. Another objective includes capturing ECLSS design and development knowledge for future missions. This report summarizes our results from Phase I, the ECLSS domain analysis phase, which we broke down into three steps: 1) Analyze and document the baselined ECLS system, 2) envision as our goal an evolution to a fully automated regenerative life support system, built upon an augmented baseline, and 3) document the augmentations (hooks and scars) and advanced software systems which we see as necessary in achieving minimal manpower support for ECLSS operations. In addition, Phase I included development of an advanced software life cycle testing tools will be used in the development of the software. In this way, we plan in preparation for phase II and III, the development and integration phases, respectively. Automated knowledge acquisition, engineering, verification, and can capture ECLSS development knowledge for future use, develop more robust and complex software, provide feedback to the KBS tool community, and insure proper visibility of our efforts.

Dewberry, Brandon S.↗

System level verification applying the Space Shuttle experience to the Space Station

The applicability of the verification process for the Shuttle guidance, navigation and control (GNC) and data management system (DMS) for the development of the Space Station are described. Shuttle avionics hardware/software integration was delayed to finalize the hardware design before detailed definition and testing of the software. A block diagram is provided of the flight simulation laboratory used to test the GNC programs before flight data were available. The Station will have distributed computers, unlike the Orbiter, and will only be assembled fully in space. Standardized integration simulation test equipment are being defined to guide the development of hardware and software. The simulation capability may become part of nominal in-flight operations to initiate new capabilities as they are added to the Station. The Station GNC and DMS systems development will be somewhat simplified relative to those of the Shuttle because ascent and reentry will not be considered for the Station.

Gilbert, David W.↗

Software for Displaying High-Frequency Test Data

An easy-to-use, intuitive computer program was written to satisfy a need of test operators and data requestors to quickly view and manipulate high-frequency test data recorded at the East and West Test Areas at Marshall Space Flight Center. By enabling rapid analysis, this program makes it possible to reduce times between test runs, thereby potentially reducing the overall cost of test operations. The program can be used to perform quick frequency analysis, using multiple fast- Fourier-transform windowing and amplitude options. The program can generate amplitude-versus-time plots with full zoom capabilities, frequency-component plots at specified time intervals, and waterfall plots (plots of spectral intensity versus frequency at successive small time intervals, showing the changing frequency components over time). There are options for printing of the plots and saving plot data as text files that can be imported into other application programs. The program can perform all of the aforementioned plotting and plot-data-handling functions on a relatively inexpensive computer; other software that performs the same functions requires computers with large amounts of power and memory.

Elmore, Jason L.↗

Software design specification. Part 2: Orbital Flight Test (OFT) detailed design specification. Volume 3: Applications. Book 2: System management

The functions performed by the systems management (SM) application software are described along with the design employed to accomplish these functions. The operational sequences (OPS) control segments and the cyclic processes they control are defined. The SM specialist function control (SPEC) segments and the display controlled 'on-demand' processes that are invoked by either an OPS or SPEC control segment as a direct result of an item entry to a display are included. Each processing element in the SM application is described including an input/output table and a structured control flow diagram. The flow through the module and other information pertinent to that process and its interfaces to other processes are included.

Source record↗

Spacecraft Data Simulator for the test of level zero processing systems

The Microelectronic Systems Branch (MSB) at Goddard Space Flight Center (GSFC) has developed a Spacecraft Data Simulator (SDS) to support the development, test, and verification of prototype and production Level Zero Processing (LZP) systems. Based on a disk array system, the SDS is capable of generating large test data sets up to 5 Gigabytes and outputting serial test data at rates up to 80 Mbps. The SDS supports data formats including NASA Communication (Nascom) blocks, Consultative Committee for Space Data System (CCSDS) Version 1 & 2 frames and packets, and all the Advanced Orbiting Systems (AOS) services. The capability to simulate both sequential and non-sequential time-ordered downlink data streams with errors and gaps is crucial to test LZP systems. This paper describes the system architecture, hardware and software designs, and test data designs. Examples of test data designs are included to illustrate the application of the SDS.

Shi, Jeff↗