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 919 records · Page 51

Pre-Flight Testing and Performance of a Ka-Band Software Defined Radio

National Aeronautics and Space Administration (NASA) has developed a space-qualified, reprogrammable, Ka-band Software Defined Radio (SDR) to be utilized as part of an on-orbit, reconfigurable testbed. The testbed will operate on the truss of the International Space Station beginning in late 2012. Three unique SDRs comprise the testbed, and each radio is compliant to the Space Telecommunications Radio System (STRS) Architecture Standard. The testbed provides NASA, industry, other Government agencies, and academic partners the opportunity to develop communications, navigation, and networking applications in the laboratory and space environment, while at the same time advancing SDR technology, reducing risk, and enabling future mission capability. Designed and built by Harris Corporation, the Ka-band SDR is NASA's first space-qualified Ka-band SDR transceiver. The Harris SDR will also mark the first NASA user of the Ka-band capabilities of the Tracking Data and Relay Satellite System (TDRSS) for on-orbit operations. This paper describes the testbed's Ka-band System, including the SDR, travelling wave tube amplifier (TWTA), and antenna system. The reconfigurable aspects of the system enabled by SDR technology are discussed and the Ka-band system performance is presented as measured during extensive pre-flight testing.

Downey, Joseph A.↗

Flight software development for the isothermal dendritic growth experiment

The Isothermal Dendritic Growth Experiment (IDGE) is a microgravity materials science experiment scheduled to fly in the cargo bay of the shuttle on the United States Microgravity Payload (USMP) carrier. The experiment will be operated by real-time control software which will not only monitor and control onboard experiment hardware, but will also communicate, via downlink data and uplink commands, with the Payload Operations Control Center (POCC) at NASA George C. Marshall Space Flight Center (MSFC). The software development approach being used to implement this system began with software functional requirements specification. This was accomplished using the Yourdon/DeMarco methodology as supplemented by the Ward/Mellor real-time extensions. The requirements specification in combination with software prototyping was then used to generate a detailed design consisting of structure charts, module prologues, and Program Design Language (PDL) specifications. This detailed design will next be used to code the software, followed finally by testing against the functional requirements. The result will be a modular real-time control software system with traceability through every phase of the development process.

Levinson, Laurie H.↗

Flight software development for the isothermal dendritic growth experiment

The Isothermal Dendritic Growth Experiment (IDGE) is a microgravity materials science experiment scheduled to fly in the cargo bay of the shuttle on the United States Microgravity Payload (USMP) carrier. The experiment will be operated by real-time control software which will not only monitor and control onboard experiment hardware, but will also communicate, via downlink data and unlink commands, with the Payload Operations Control Center (POCC) at NASA George C. Marshall Space Flight Center (MSFC). The software development approach being used to implement this system began with software functional requirements specification. This was accomplished using the Yourdon/DeMarco methodology as supplemented by the Ward/Mellor real-time extensions. The requirements specification in combination with software prototyping was then used to generate a detailed design consisting of structure charts, module prologues, and Program Design Language (PDL) specifications. This detailed design will next be used to code the software, followed finally by testing against the functional requirements. The result will be a modular real-time control software system with traceability through every phase of the development process.

Levinson, Laurie H.↗

Simulating Mars: Enabling Testing of the Perseverance Rover Sampling and Caching Subsystem on Earth

The development of the Sampling and Caching Subsystem (SCS) on the JPL Perseverance Rover lies at the intersection of testing, robotics, and geology. The SCS team established three primary system test campaigns and venues to aid in the development of SCS through verification and validation testing – Qualification Model Dirty Testing (QMDT) to provide a venue for testing in a Martian environment, Vehicle System Testbed (VSTB) for testing while integrated with the mobility subsystem on Martian-like terrain, and the Flight Software Testbed (FSWTB) for conducting tests using the flight motor controllers and software system on a hexapod which had the ability to simulate rover tilt. Each venue contributed a vital piece to the SCS building blocks. However, the QMDT venue operating within a 10-ft diameter Thermal Vacuum chamber to simulate Martian environment provided a sui generis opportunity to fine tune the entire sampling and caching process while building the team’s knowledge base about rock drillability, system life, and target selection. On Earth, because Martian rocks are not readily available, the development team must utilize geoanalogs to the rocks and regolith on Mars. Geologists on the team helped establish a set of standard rock types to use for Mars missions, like Basalt, Sandstone, Mudstone, Gypsum, and other related geoanalogs. These geoanalogs are characterized with a standard suite of tests for density, compressibility, and other characteristics to categorize potential drillability. This concept of drillability is what links the geoanalogs on Earth to the samples we collect on Mars. With the simulant characteristics defined, these geoanalog rocks are ready to be drilled into as we do on the Martian surface. A key aspect of interacting with the surface on Mars is rock target identification and selection. The Perseverance robotic system uses the on-board cameras, instrumentation, and software to collect enough information to identify potential scientific targets. With the targets identified, SCS can place the Corer and abrade the surface or collect a sample. For a ground test activity like QMDT, the test team did not have all of the camera and instrumentation systems that the rover does, so the team developed ground test equivalents to process a rock, build a target map, and define the target. The team constructed a Rock Scanning Station to build a 3D point cloud of the rock. This point cloud was then processed and evaluated with predefined and programmed criteria in a Target Downselect Tool. A primary output of the Target Downselect Tool is a defined target that can be uploaded directly to the robotic software system to simulate and build the robotic sequences used in tests. With these insights and programmatic definition of targets, the QMDT test team was able to make the same decisions that the Perseverance surface operations team does. In addition, valuable lessons learned from developing the target selection ground tools and using them were implemented into the tools used for surface operations.

Kim, Junggon↗

Intelligent fault management for the Space Station active thermal control system

The Thermal Advanced Automation Project (TAAP) approach and architecture is described for automating the Space Station Freedom (SSF) Active Thermal Control System (ATCS). The baseline functionally and advanced automation techniques for Fault Detection, Isolation, and Recovery (FDIR) will be compared and contrasted. Advanced automation techniques such as rule-based systems and model-based reasoning should be utilized to efficiently control, monitor, and diagnose this extremely complex physical system. TAAP is developing advanced FDIR software for use on the SSF thermal control system. The goal of TAAP is to join Knowledge-Based System (KBS) technology, using a combination of rules and model-based reasoning, with conventional monitoring and control software in order to maximize autonomy of the ATCS. TAAP's predecessor was NASA's Thermal Expert System (TEXSYS) project which was the first large real-time expert system to use both extensive rules and model-based reasoning to control and perform FDIR on a large, complex physical system. TEXSYS showed that a method is needed for safely and inexpensively testing all possible faults of the ATCS, particularly those potentially damaging to the hardware, in order to develop a fully capable FDIR system. TAAP therefore includes the development of a high-fidelity simulation of the thermal control system. The simulation provides realistic, dynamic ATCS behavior and fault insertion capability for software testing without hardware related risks or expense. In addition, thermal engineers will gain greater confidence in the KBS FDIR software than was possible prior to this kind of simulation testing. The TAAP KBS will initially be a ground-based extension of the baseline ATCS monitoring and control software and could be migrated on-board as additional computation resources are made available.

Hill, Tim↗

NASA's Space Launch System: Systems Engineering Approach for Affordability and Mission Success

NASA is working toward the first launch of a new, unmatched capability for deep space exploration, with launch readiness planned for 2018. The initial Block 1 configuration of the Space Launch System will more than double the mass and volume to Low Earth Orbit (LEO) of any launch vehicle currently in operation - with a path to evolve to the greatest capability ever developed. The program formally began in 2011. The vehicle successfully passed Preliminary Design Review (PDR) in 2013, Key Decision Point C (KDPC) in 2014 and Critical Design Review (CDR) in October 2015 - nearly 40 years since the last CDR of a NASA human-rated rocket. Every major SLS element has completed components of test and flight hardware. Flight software has completed several development cycles. RS-25 hotfire testing at NASA Stennis Space Center (SSC) has successfully demonstrated the space shuttle-heritage engine can perform to SLS requirements and environments. The five-segment solid rocket booster design has successfully completed two full-size motor firing tests in Utah. Stage and component test facilities at Stennis and NASA Marshall Space Flight Center are nearing completion. Launch and test facilities, as well as transportation and other ground support equipment are largely complete at NASA's Kennedy, Stennis and Marshall field centers. Work is also underway on the more powerful Block 1 B variant with successful completion of the Exploration Upper Stage (EUS) PDR in January 2017. NASA's approach is to develop this heavy lift launch vehicle with limited resources by building on existing subsystem designs and existing hardware where available. The systems engineering and integration (SE&I) of existing and new designs introduces unique challenges and opportunities. The SLS approach was designed with three objectives in mind: 1) Design the vehicle around the capability of existing systems; 2) Reduce work hours for nonhardware/ software activities; 3) Increase the probability of mission success by focusing effort on more critical activities.

Hutt, John J.↗

Thomas Leps Internship Abstract

An optical navigation system is being flown as the backup system to the primary Deep Space Network telemetry for navigation and guidance purposes on Orion. This is required to ensure Orion can recover from a loss of communication, which would simultaneously cause a loss of DSN telemetry. Images taken of the Moon and Earth are used to give range and position information to the navigation computer for trajectory calculations and maneuver execution. To get telemetry data from these images, the size and location of the moon need to be calculated with high accuracy and precision. The reentry envelope for the Orion EM-1 mission requires the centroid and radius of the moon images to be determined within 1/3 of a pixel 3 sigma. In order to ensure this accuracy and precision can be attained, I was tasked with building precise dot grid images for camera calibration as well as building a hardware in the loop test stand for flight software and hardware proofing. To calibrate the Op-Nav camera a dot grid is imaged with the camera, the error between the image dot location and the actual dot location can be used to build a distortion map of the camera and lens system so that images can be fixed to display truth locations. To build the dot grid images I used the Electro Optics Lab optical bench Bright Object Simulator System, and gimbal. The gimbal was slewed to a series of elevations and azimuths. An image of the collimated single point light source was then taken at each position. After a series of 99 images were taken at different locations the single light spots were extracted from each image and added to a composite image containing all 99 points. During the development of these grids it was noticed that an intermittent error in the artificial "star" locations occurred. Prior to the summer this error was attributed to the gimbal having glitches in it's pointing direction and was going to be replaced, however after further examining the issue I determined it to be a software issue. I have since narrowed the likely source of the error down to a Software Development Kit released by the camera supplier PixeLink. I have since developed a workaround in order to build star grids for calibration until the software bug can be isolated and fixed. I was also tasked with building a Hardware in the Loop test stand in order to test the full Op-Nav system. A 4k screen displays simulated Lunar and Terrestrial images from a possible Orion trajectory. These images are then projected through a collimator and then captured with an Op-Nav camera controlled by an Intel NUC computer running flight software. The flight software then analyzes the images to determine attitude and position, this data is then reconstructed into a trajectory and matched to the simulated trajectory in order to determine the accuracy of the attitude and position estimates. In order for the system to work it needs to be precisely and accurately aligned. I developed an alignment procedure that allows the screen, collimator and camera to be squared, centered and collinear with each other within a micron spatially and 5 arcseconds in rotation. I also designed a rigid mount for the screen that was machined on site in Building 10 by another intern. While I was working in the EOL we received a $500k Orion startracker for alignment procedure testing. Due to my prior experience in electronics development, as an ancillary duty, I was tasked with building the cables required to operate and power the startracker. If any errors are made building these cables the startracker would be destroyed, I was honored that the director of the lab entrusted such a critical component with me. This internship has cemented my view on public space exploration. I always preferred public sector to privatization because, as a scientist, the most interesting aspects of space for me are not necessarily the most profitable. I was concerned that the public sector was faltering however, and that in order to improve human space exploration I would be forced into private sector. I now know that, at least at JSC, human spaceflight is still progressing, and exciting work is still being done. I am now actively seeking employment at JSC after I complete my Ph.D and have met with my branch chiefs and mentor to discuss transitioning to a grad Co-op position.

Leps, Thomas↗

Spack-Manager

SAND2022-3282 O Spack-Manager is a lightweight wrapper for streamlining the software development and deployment cycle using Spack. Spack-Manager creates a uniform framework for developing, testing, and deploying specific software stacks for projects across multiple platforms while utilizing Spack as much as possible. It organizes Spack extensions, machine configurations, project customizations, and tools for features that are mostly project specific. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Sakievich, Philip↗

STS-51 pad abort. OV103-engine 2033 (ME-2) fuel flowmeter sensor open circuit

The STS-51 initial launch attempt of Discovery (OV-103) was terminated on KSC launch pad 39B on 12 Aug. 1993 at 9:12 AM E.S.T. due to a sensor redundancy failure in the liquid hydrogen system of ME-2 (Engine 2033). The event description and time line are summarized. Propellant loading was initiated on 12 Aug. 1993 at 12:00 AM EST. All space shuttle main engine (SSME) chill parameters and Launch Commit Criteria (LCC) were nominal. At engine start plus 1.34 seconds a Failure Identification (FID) was posted against Engine 2033 for exceeding the 1800 spin intra-channel (A1-A2) Fuel Flowrate sensor channel qualification limit. The engine was shut down at 1.50 seconds followed by Engines 2032 and 2030. All shut down sequences were nominal and the mission was safely aborted. SSME Avionics hardware and software performed nominally during the incident. A review of vehicle data table (VDT) data and controller software logic revealed no failure indications other than the single FID 111-101, Fuel Flowrate Intra-Channel Test Channel A disqualification. Software logic was executed according to requirements and there was no anomalous controller software operation. Immediately following the abort, a Rocketdyne/NASA failure investigation team was assembled. The team successfully isolated the failure cause to an open circuit in a Fuel Flowrate Sensor. This type of failure has occurred eight previous times in ground testing. The sensor had performed acceptably on three previous flights of the engine and SSME flight history shows 684 combined fuel flow rate sensor channel flights without failure. The disqualification of an Engine 2 (SSME No. 2033) Fuel Flowrate sensor channel was a result of an instrumentation failure and not engine performance. All other engine operations were nominal. This disqualification resulted in an engine shutdown and safe sequential shutdown of all three engines prior to ignition of the solid boosters.

Source record↗

Improving the Software Development Process Using Testability Research

Software testability is the the tendency of code to reveal existing faults during random testing. This paper proposes to take software testability predictions into account throughout the development process. These predictions can be made from formal specifications, design documents, and the code itself. The insight provided by software testability is valuable during design, coding, testing, and quality assurance. We further believe that software testability analysis can play a crucial role in quantifying the likelihood that faults are not hiding after testing does not result in any failures for the current version.

Voas, Jeffrey M.↗

ARC Software Validation Work for the FFTF Reactor

Extensive efforts have been carried out at ANL for the verification and validation of the Argonne Reactor Codes (ARC) software package currently used for the design of Versatile Test Reactor (VTR). The ARC software package consists of steady state neutronics and thermal hydraulics modeling capabilities which are being used by the VTR program to develop most of the VTR reactor design details which will be part of the licensing application. It is anticipated that this software will continue to be used for the design work and for initial operations although additional software may be introduced at a later time. The validation work was focused primarily on obtaining validation data consistent with VTR and usable for the ARC software. Because no critical facilities or operating fast spectrum reactors are available to do experiments for the VTR, the next best option is to identify historical experimental data that can be used as validation data. Early on in VTR, the ZPPR-15 set of experiments was identified as good validation data because of 1) the availability and quality of the data, 2) existing staff that are already familiar with the experimental machine and measurements, 3) most of the ZPPR-15 loadings of interest have already been processed into ARC models, and 4) a full uncertainty quantification has already been done for several loadings of ZPPR-15. The FFTF startup and operations data was identified as the most consistent reactor type that has validation data usable for VTR. Finally, the EBR-II fuel depletion measurements were identified as the best available validation data for VTR. It is important to note that both the FFTF and EBR-II reactors typically come with higher uncertainties than the ZPPR. In the frame of the discussed verification and validation efforts, the present document discusses the analysis of selected FFTF measurements included in the benchmark specifications of the International Reactor Physics Experiment (IRPhE) handbook. The FFTF reactor core configurations from the benchmark specification are presented in Section 2. The analysis is performed with the use of the ARC code suite available at ANL for fast reactor studies and is discussed in Section 3. The reactor parameters from the benchmark include criticality, neutron spectra, effective delayed neutron spectra, control rod worth, isothermal temperature coefficient and low energy gamma-ray spectra. The calculated values and the comparison with the experimental data is discussed in Sections 4 to 9 for each considered reactor parameter. Finally, conclusions are presented in Section 10.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Integrated System Test Approaches for the NASA Ares I Crew Launch Vehicle

The Ares I Crew Launch Vehicle (CLV) is being developed by the U.S. National Aeronautics and Space Administration (NASA) to provide crew access to the International Space Station (ISS) and, together with the Ares V Cargo Launch Vehicle (CaLV), serves as one component of a future launch capability for human exploration of the Moon. During the system requirements definition process and early design cycles, NASA defined and began implementing plans for integrated ground and flight testing necessary to achieve the first human launch of Ares I. The individual Ares I flight hardware elements: the first stage five segment booster (FSB), upper stage, and J-2X upper stage engine, will undergo extensive development, qualification, and certification testing prior to flight. Key integrated system tests include the Main Propulsion Test Article (MPTA), acceptance tests of the integrated upper stage and upper stage engine assembly, a full-scale integrated vehicle dynamic test (IVDT), aerodynamic testing to characterize vehicle performance, and integrated testing of the avionics and software components. The Ares I-X development flight test will provide flight data to validate engineering models for aerodynamic performance, stage separation, structural dynamic performance, and control system functionality. The Ares I-Y flight test will validate ascent performance of the first stage, stage separation functionality, and a highaltitude actuation of the launch abort system (LAS) following separation. The Orion-1 flight test will be conducted as a full, un-crewed, operational flight test through the entire ascent flight profile prior to the first crewed launch.

Cockrell, Charles E., Jr.↗

Integrated Testing Approaches for the NASA Ares I Crew Launch Vehicle

The Ares I crew launch vehicle is being developed by the U.S. National Aeronautics and Space Administration (NASA) to provide crew and cargo access to the International Space Station (ISS) and, together with the Ares V cargo launch vehicle, serves as a critical component of NASA's future human exploration of the Moon. During the preliminary design phase, NASA defined and began implementing plans for integrated ground and flight testing necessary to achieve the first human launch of Ares I. The individual Ares I flight hardware elements - including the first stage five segment booster (FSB), upper stage, and J-2X upper stage engine - will undergo extensive development, qualification, and certification testing prior to flight. Key integrated system tests include the upper stage Main Propulsion Test Article (MPTA), acceptance tests of the integrated upper stage and upper stage engine assembly, a full-scale integrated vehicle ground vibration test (IVGVT), aerodynamic testing to characterize vehicle performance, and integrated testing of the avionics and software components. The Ares I-X development flight test will provide flight data to validate engineering models for aerodynamic performance, stage separation, structural dynamic performance, and control system functionality. The Ares I-Y flight test will validate ascent performance of the first stage, stage separation functionality, validate the ability of the upper stage to manage cryogenic propellants to achieve upper stage engine start conditions, and a high-altitude demonstration of the launch abort system (LAS) following stage separation. The Orion 1 flight test will be conducted as a full, un-crewed, operational flight test through the entire ascent flight profile prior to the first crewed launch.

Taylor, James L.↗

Open Architecture Standard for NASA's Software-Defined Space Telecommunications Radio Systems

NASA is developing an architecture standard for software-defined radios used in space- and ground-based platforms to enable commonality among radio developments to enhance capability and services while reducing mission and programmatic risk. Transceivers (or transponders) with functionality primarily defined in software (e.g., firmware) have the ability to change their functional behavior through software alone. This radio architecture standard offers value by employing common waveform software interfaces, method of instantiation, operation, and testing among different compliant hardware and software products. These common interfaces within the architecture abstract application software from the underlying hardware to enable technology insertion independently at either the software or hardware layer. This paper presents the initial Space Telecommunications Radio System (STRS) Architecture for NASA missions to provide the desired software abstraction and flexibility while minimizing the resources necessary to support the architecture.

Reinhart, Richard C.↗

Space Telecommunications Radio System (STRS) Architecture Standard. Release 1.02.1

This document contains the NASA architecture standard for software defined radios used in space- and ground-based platforms to enable commonality among radio developments to enhance capability and services while reducing mission and programmatic risk. Transceivers (or transponders) with functionality primarily defined in software (e.g., firmware) have the ability to change their functional behavior through software alone. This radio architecture standard offers value by employing common waveform software interfaces, method of instantiation, operation, and testing among different compliant hardware and software products. These common interfaces within the architecture abstract application software from the underlying hardware to enable technology insertion independently at either the software or hardware layer.

Reinhart, Richard C.↗

Space station operating system study

The current phase of the Space Station Operating System study is based on the analysis, evaluation, and comparison of the operating systems implemented on the computer systems and workstations in the software development laboratory. Primary emphasis has been placed on the DEC MicroVMS operating system as implemented on the MicroVax II computer, with comparative analysis of the SUN UNIX system on the SUN 3/260 workstation computer, and to a limited extent, the IBM PC/AT microcomputer running PC-DOS. Some benchmark development and testing was also done for the Motorola MC68010 (VM03 system) before the system was taken from the laboratory. These systems were studied with the objective of determining their capability to support Space Station software development requirements, specifically for multi-tasking and real-time applications. The methodology utilized consisted of development, execution, and analysis of benchmark programs and test software, and the experimentation and analysis of specific features of the system or compilers in the study.

Horn, Albert E.↗

REDESIGNING A PERFORMANCE MONITORING SOFTWARE FOR SUPERCOMPUTERS

The objective of this project was to improve upon the existing Watchr software that charts performance test metrics from the Trilinos project run on supercomputers at Sandia and elsewhere across the DOE complex. Software was iteratively designed and developed using Python Pandas and Dash data visualization to improve the extensibility and user experience of Watchr. Documentation is being maintained for future developers who want to extend the application.

Camacho, Dane Joseph [Sandia National Laboratories↗