SEARCH · Search NASA
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.
A Data Bus Evaluation Laboratory (DBEL) facility has been established to test and evaluate space shuttle data bus hardware. Performance testing conducted on an in-house developed multiplex interface adapter for the purpose of evaluating DBEL test procedures, test hardware, and test software in a realistic test environment is described. Results are presented.
The four major topics of discussion included: the NASA Software Engineering Laboratory, software testing, human factors in software engineering and software quality assessment. As in the past years, there were 12 position papers presented (3 for each topic) followed by questions and very heavy participation by the general audience.
Preliminary design developed for validation experiment that addresses problems unique to assuring extremely high quality of multiple-version programs in process-control software. Approach takes into account inertia of controlled system in sense it takes more than one failure of control program to cause controlled system to fail. Verification procedure consists of two steps: experimentation (numerical simulation) and computation, with Markov model for each step.
The paper will present a brief background of the previous data acquisition system at the National Transonic Facility (NTF) and the reasoning and goals behind the upgrade to the current Test SLATE (Test Software Laboratory and Automated Testing Environments) data acquisition system. The components, performance characteristics, and layout of the Test SLATE system within the NTF control room will be discussed. The development, testing, and integration of Test SLATE within NTF operations will be detailed. The operational capabilities of the system will be outlined including: test setup, instrumentation calibration, automatic test sequencer setup, data recording, communication between data and facility control systems, real time display monitoring, and data reduction. The current operational status of the Test SLATE system and its performance during recent NTF testing will be highlighted including high-speed, frame-by-frame data acquisition with conditional sampling post-processing applied. The paper concludes with current development work on the system including the capability for real-time conditional sampling during data acquisition and further efficiency enhancements to the wind tunnel testing process.
The National Aeronautics and Space Administration (NASA) remotely administered a psychoacoustic test in fall of 2022 as the first of two phases of a cooperative Urban Air Mobility (UAM) vehicle noise human response study. The first phase, the Feasibility Test, described in this paper, determined the feasibility of the remote test method, in contrast to a previous in-person psychoacoustic test that found an annoyance response difference between small unmanned aerial system (sUAS) noise and ground vehicle noise. This paper discusses the Feasibility Test online layout, sound calibration method, remote test software development, stimuli selection, test subject recruitment, and test administration. Test performance is measured through comparison of annoyance response data with the previous in-person test results. The paper also investigates if providing a contextual cue to test subjects influenced their annoyance response. Response differences between test subjects in geographically distinct areas are analyzed. Administrative challenges that were encountered during the test are discussed. The second phase of this study, the implementation phase, will use a remote (web-based) test method and leverage the cooperation of multiple government agencies, academia, and industry to gain human response insights from a wide range of UAM vehicle sounds that would be challenging for a single organization to acquire. Improvements to administering a remote test for the implementation phase of the UAM vehicle noise human response study are recommended.
The National Aeronautics and Space Administration (NASA) remotely administered a psychoacoustic test in fall of 2022 as the first of two phases of a cooperative Urban Air Mobility (UAM) vehicle noise human response study. The first phase, the Feasibility Test, described in this paper, determined the feasibility of the remote test method, in contrast to a previous in-person psychoacoustic test that found an annoyance response difference between small unmanned aerial system (sUAS) noise and ground vehicle noise. This paper discusses the Feasibility Test online layout, sound calibration method, remote test software development, stimuli selection, test subject recruitment, and test administration. Test performance is measured through comparison of annoyance response data with the previous in-person test results. The paper also investigates if providing a contextual cue to test subjects influenced their annoyance response. Response differences between test subjects in geographically distinct areas are analyzed. Administrative challenges that were encountered during the test are discussed. The second phase of this study, the implementation phase, will use a remote (web-based) test method and leverage the cooperation of multiple government agencies, academia, and industry to gain human response insights from a wide range of UAM vehicle sounds that would be challenging for a single organization to acquire. Improvements to administering a remote test for the implementation phase of the UAM vehicle noise human response study are recommended.
ORT (Operational Readiness Test) software allows one engineer to test readiness of 64 minicomputers and their peripherals from single console. Software makes roll call of computers and peripherals via common data buffer to check readiness of system in morning "wake up" or at other important times. Subsystems are tested in parallel to save time. "Watchdog" terminates test of any system that does not respond in time, so one failed system does not halt test sequence. Entire rollcall is complete in about 15 minutes. Software is designed for Space Shuttle prelaunch checkout, but approach should interest users of similar equipment.
Software testing is typically an ad hoc process where human testers manually write many test inputs and expected test results, perhaps automating their execution in a regression suite. This process is cumbersome and costly. This paper reports preliminary results on an approach to further automate this process. The approach consists of combining automated test case generation based on systematically exploring the program's input domain, with runtime analysis, where execution traces are monitored and verified against temporal logic specifications, or analyzed using advanced algorithms for detecting concurrency errors such as data races and deadlocks. The approach suggests to generate specifications dynamically per input instance rather than statically once-and-for-all. The paper describes experiments with variants of this approach in the context of two examples, a planetary rover controller and a space craft fault protection system.
The use of a software development facility is discussed as a means of producing a reliable and maintainable ECS software system, and as a means of providing efficient use of the ECS hardware test facility. Principles applied to software design are given, including modularity, abstraction, hiding, and uniformity. The general objectives of each phase of the software life cycle are also given, including testing, maintenance, code development, and requirement specifications. Software development facility tools are summarized, and tool deficiencies recognized in the code development and testing phases are considered. Due to limited lab resources, the functional simulation capabilities may be indispensable in the testing phase.
Applying equal testing and verification effort to all parts of a software system is not very efficient, especially when resources are limited and scheduling is tight. Therefore, one needs to be able to differentiate low/high fault density components so that the testing/verification effort can be concentrated where needed. Such a strategy is expected to detect more faults and thus improve the resulting reliability of the overall system. This paper presents an alternative approach for constructing such models that is intended to fulfill specific software engineering needs (i.e. dealing with partial/incomplete information and creating models that are easy to interpret). Our approach to classification is as follows: (1) to measure the software system to be considered; and (2) to build multivariate stochastic models for prediction. We present experimental results obtained by classifying FORTRAN components developed at the NASA/GSFC into two fault density classes: low and high. Also we evaluate the accuracy of the model and the insights it provides into the software process.
A repertoire of software to optimally analyze various X-ray imagery was successfully developed. Computer techniques are presented to solve many common problems involved in nondestructive testing X-ray analysis.
The major Shuttle-related testing currently in progress includes: static testing of all major elements, full scale ground vibration testing, main propulsion system testing, software verification and validation, qualification testing of many components and subsystems, and SSME verification testing. This paper reviews the current status of the Shuttle program and gives attention to the transition to operations, near-term traffic plans, user-charge policies, and payload integration. It is concluded that the transition from individual space-research projects to a fully integrated Space Transportation System, providing low-cost routine access to space for many users, involves a complete rethinking of the role NASA and the user will play.
Computer program called "A Formal Test Representation Language and Tool for Functional Test Designs" (TRL) provides automatic software tool and formal language used to implement category-partition method and produce specification of test cases in testing phase of development of software. Category-partition method useful in defining input, outputs, and purpose of test-design phase of development and combines benefits of choosing normal cases having error-exposing properties. Traceability maintained quite easily by creating test design for each objective in test plan. Effort to transform test cases into procedures simplified by use of automatic software tool to create cases based on test design. Method enables rapid elimination of undesired test cases from consideration and facilitates review of test designs by peer groups. Written in C language.
A methodology for testing fault tolerant software is presented. There are problems associated with testing fault tolerant software because many errors are masked or corrected by voters, limiter, or automatic channel synchronization. This methodology illustrates how the same strategies used for testing fault tolerant hardware can be applied to testing fault tolerant software. For example, one strategy used in testing fault tolerant hardware is to disable the redundancy during testing. A similar testing strategy is proposed for software, namely, to move the major emphasis on testing earlier in the development cycle (before the redundancy is in place) thus reducing the possibility that undetected errors will be masked when limiters and voters are added.
On the surface of Mars, the Mars Science Laboratory will boot up its flight computers every morning, having charged the batteries through the night. This boot process is complicated, critical, and affected by numerous hardware states that can be difficult to test. The hardware test beds do not facilitate testing a long duration of back-to-back unmanned automated tests, and although the software simulation has provided the necessary functionality and fidelity for this boot testing, there has not been support for the full flexibility necessary for this task. Therefore to perform this testing a framework has been build around the software simulation that supports running automated tests loading a variety of starting configurations for software and hardware states. This implementation has been tested against the nominal cases to validate the methodology, and support for configuring off-nominal cases is ongoing. The implication of this testing is that the introduction of input configurations that have yet proved difficult to test may reveal boot scenarios worth higher fidelity investigation, and in other cases increase confidence in the robustness of the flight software boot process.
Kennedy Space Center is in the midst of developing a command and control system for the launch of the next generation manned space vehicle. The Space Launch System (SLS) will launch using the new Spaceport Command and Control System (SCCS). As a member of the Software Integration and Test (SWIT) Team, command scripts, and bash scripts were written to assist in integration and testing of the Launch Control System (LCS), which is a component of SCCS. The short term and midterm tasks are for the most part completed. The long term tasks if time permits will require a presentation and demonstration.
In this paper, we present an overview of a proposed collaboration between the National Aeronautics and Space Administration (NASA) and the European Space Agency (ESA), which is designed to facilitate the introduction of commercial-off-the-shelf (COTS) radios for smart-sensing applications into international spaceflight programs and projects. The proposed work will produce test hardware reference designs, test software reference architectures and example implementations, test plans in reference test environments, and test results, all of which will be shared between the agencies and documented for future use by mission planners. The proposed collaborative structure together with all of the anticipated tools and results produced under the effort is collectively referred to as the Smart Sensor Inter-agency Reference Testbench or SSIART. It is intended to provide guidance in technology selection and in increasing the related readiness levels of projects and missions as well as the space industry.
NASA and its commercial industry team achieved significant progress in 2016 in manufacturing and testing of the Block 1 vehicle for the first launch of the Space Launch System (SLS). Test and flight article hardware for the liquid hydrogen fuel tank as well as the engine section for the core stage were completed at Michoud Assembly Facility (MAF) in New Orleans. Test stands neared completion at Marshall Space Flight Center for the propellant tanks, engine section, intertank and payload section. Stennis Space Center completed major structural renovations on the B2 test stand, where the core stage "green run" test program will be conducted. The SLS team completed a hotfire test series at Stennis to successfully demonstrate the ability of the RS-25 engine to operate under SLS environments and performance conditions. The team also test fired the second qualification five-segment solid rocket motor and cast the first six motor segments for the first SLS mission. The Interim Cryogenic Propulsion Stage (ICPS) test article was delivered to Marshall for structural tests, and work is nearly finished on the flight stage. Flight software testing completed at Marshall included power quality and command and data handling. In 2017, that work continues. SLS completed Preliminary Design Review (PDR) on the Exploration Upper Stage (EUS), a powerful, human-rated spacecraft that will propel explorers to cis-lunar space. In 2017, hardware will continue to be integrated at MAF for core stage structural test articles and the first two operational flights. RS-25 hotfire testing will continue to explore engine performance, as well as test flight-like software and four new Engine Controller Units (ECUs) for the first mission. Production of development components for a more affordable RS-25 design is underway. Core stage structural test articles have begun arriving at Marshall. While engineering challenges typical of a new development are possible, SLS is working toward launch readiness in late 2018. This paper will discuss these and other technical and programmatic successes and challenges over the past year and provide a preview of work ahead before first flight