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 721 records · Page 40

Quantifying parameters for Bayesian prior assumptions when estimating the probability of failure of software

Software reliability has become increasingly important, especially in life-critical situations. The ability to measure the results of testing and to quantify software reliability is needed. If this is accomplished, a certain minimum amount of reliability for a piece of software can be specified, and testing and/or other analysis may be done until that minimum number has been attained. There are many models for estimating software reliability. The accuracy of these models has been challenged and many revisions for the models and recalibration techniques have been devised. Of particular interest is the method of estimating the probability of failure of software when no failures have yet occurred in its current version as described by Miller. This model uses black box testing with formulae based on Bayesian estimation. The focus is on three interrelated issues: estimating the probability of failure when testing has revealed no errors; modifying this estimation when the input use distribution does not match the test distribution; and combining the results from random testing with other relevant information to obtain a possibly more accurate estimate of the probability of failure. Obtaining relevant information about the software and combining the results for a better estimate for the Miller model are discussed.

Long, Jacquelyn E.↗

S-Band Transponder Multi-Network Compatibility, Space Environment and Radiation Testing

This paper presents the development and testing of the Software Define Radio (SDR) transceiver to meet the emerging needs for SmallSat communication and navigation. Vulcan Wireless and NASA Goddard Space Flight Center (GSFC) collaborated in testing the Vulcan Wireless S-band SDR engineering model. Apart from testing, communication link analysis was performed for a Low Earth Orbit (LEO) 400 km scenario. The results of the compatibility, radiation, environmental testing, and link analysis are presented. Also, this paper reviews a set of SmallSat missions under development at NASA GSFC.

Software Define Radio, transceiver, S-band↗

Study of fault tolerant software technology for dynamic systems

The major aim of this study is to investigate the feasibility of using systems-based failure detection isolation and compensation (FDIC) techniques in building fault-tolerant software and extending them, whenever possible, to the domain of software fault tolerance. First, it is shown that systems-based FDIC methods can be extended to develop software error detection techniques by using system models for software modules. In particular, it is demonstrated that systems-based FDIC techniques can yield consistency checks that are easier to implement than acceptance tests based on software specifications. Next, it is shown that systems-based failure compensation techniques can be generalized to the domain of software fault tolerance in developing software error recovery procedures. Finally, the feasibility of using fault-tolerant software in flight software is investigated. In particular, possible system and version instabilities, and functional performance degradation that may occur in N-Version programming applications to flight software are illustrated. Finally, a comparative analysis of N-Version and recovery block techniques in the context of generic blocks in flight software is presented.

Caglayan, A. K.↗

Real-Time Sensor Validation System Developed for Reusable Launch Vehicle Testbed

A real-time system for validating sensor health has been developed for the reusable launch vehicle (RLV) program. This system, which is part of the propulsion checkout and control system (PCCS), was designed for use in an integrated propulsion technology demonstrator testbed built by Rockwell International and located at the NASA Marshall Space Flight Center. Work on the sensor health validation system, a result of an industry-NASA partnership, was completed at the NASA Lewis Research Center, then delivered to Marshall for integration and testing. The sensor validation software performs three basic functions: it identifies failed sensors, it provides reconstructed signals for failed sensors, and it identifies off-nominal system transient behavior that cannot be attributed to a failed sensor. The code is initiated by host software before the start of a propulsion system test, and it is called by the host program every control cycle. The output is posted to global memory for use by other PCCS modules. Output includes a list indicating the status of each sensor (i.e., failed, healthy, or reconstructed) and a list of features that are not due to a sensor failure. If a sensor failure is found, the system modifies that sensor's data array by substituting a reconstructed signal, when possible, for use by other PCCS modules.

Jankovsky, Amy L.↗

November 2021 Operational Highlights

Completed: 1. the initial tests of document workflows for Titan on the Red, which included standing up a software encryption capability to test data ingestion; 2. a software encryption capability in order to ingest the first data source by the end of the month; 3. a stand-alone computer for classified ontology data entry. Titan on the Red is an artificial intelligence/machine learning system to make digitizing, cataloging, and searching NSRC collections easier and more efficient. Created Online Vault backups, with one copy stored at LANL and one shipped to Lawrence Livermore National Laboratory. The Online Vault is a classified, searchable library of LANL’s nuclear weapons design and test history. Imported new Laboratory Directed Research and Development (LDRD) documents based on revised access categories. Bulk ingested nearly 10,000 documents via java-based PowerLoader. This application ingests metadata and content into the Online Vault to meet the requirements for the NSRC collections. Rehoused 300 linear feet of weapons physics documents in archival, acid-free storage folders and boxes.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗

Cooperative GN&C development in a rapid prototyping environment

The Navigation, Control and Aeronautics Division (NCAD) at NASA-JSC is exploring ways of producing Guidance, Navigation and Control (GN&C) flight software faster, better, and cheaper. To achieve these goals NCAD established two hardware/software facilities that take an avionics design project from initial inception through high fidelity real-time hardware-in-the-loop testing. Commercially available software products are used to develop the GN&C algorithms in block diagram form and then automatically generate source code from these diagrams. A high fidelity real-time hardware-in-the-loop laboratory provides users with the capability to analyze mass memory usage within the targeted flight computer, verify hardware interfaces, conduct system level verification, performance, acceptance testing, as well as mission verification using reconfigurable and mission unique data. To evaluate these concepts and tools, NCAD embarked on a project to build a real-time 6 DOF simulation of the Soyuz Assured Crew Return Vehicle flight software. To date, a productivity increase of 185 percent has been seen over traditional NASA methods for developing flight software.

Bordano, Aldo↗

How Usability Testing Resulted in Improvements to Ground Collision Software for General Aviation: Improved Ground Collision Avoidance System (IGCAS)

The NASA improved Ground Collision Avoidance System (iGCAS) team conducted an onsite usability study at Experimental Aircraft Association (EAA) Air Venture in Oshkosh, Wisconsin from July 19 through July 26, 2015. EAA Air Venture had approximately 550,000 attendees from which the sample pool of pilots were selected. The objectives of this study were to assess the overall appropriateness and acceptability of iGCAS as a warning system for General Aviation aircraft, usability of the iGCAS displays and audio cues, test terrain avoidance characteristics, performance, functionality, pilot response time, and correlate terrain avoidance performance and pilot response time data.

collision avoidance↗

Verification Testing For Solid-Element Material Models 11-19 in DYNA3D/ParaDyn

This technical report documents the creation and implementation of verification tests for solid-element material models 11 through 19 available in DYNA3D/ParaDyn. The verification tests covered all aspects of each material model, except for the Weibull distribution functionality in material models 15 and 19. General test cases were created to verify the elastic and plastic behavior of the material models. Other additional tests were developed to examine the intricacies of each material model. Each test involved the use a kinematic load case and specification of material parameters necessary to activate corresponding features of the material model. The load cases prescribed the full time history of the kinematic motion for the solid elements, and these loads are independent of the material model or element formulation. When possible, closed form solutions were then derived for each verification test in a continuum setting. The DYNA3D simulations for each test were carried out over a unit time interval, t ϵ [0, 1], and the as implemented DYNA3D response was compared to the closed form solutions evaluated at discrete points in time. A relative error measure was determined for each test to justify the proper implementation of the material model. The relative errors comparing the DYNA3D solution to the analytical solution were, in general, on the order of machine precision except where noted. This signifies the proper implementation of solid-element material models 11-19. In the development of these verification tests, six bugs were found and fixed in the source code. Additionally, this work generated eighteen DYNA3D input decks and answer extraction scripts in the DYNA3D/ParaDyn Software Quality Assurance test suite, which are comprised of a total of 285 solid-element tests. Testing for each material model utilizes two input decks and answer extraction scripts, where one focuses on the linear elastic response and the other examines the inelastic and remaining functionalities of the material model. In total, this work added 285 individual verification test problems in the DYNA3D/ParaDyn test suite.

42 ENGINEERING↗

Hardware in the Loop Testing of an Iodine-Fed Hall Thruster

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload,1 providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm cu and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high delta v maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Recently, work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) 2 that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. Iodine stores as a dense solid at very low pressures, making it acceptable as a propellant on a secondary payload. It has exceptionally high ρIsp (density times specific impulse), making it an enabling technology for small satellite near-term applications and providing the potential for systems-level advantages over mid-term high power electric propulsion options. Iodine flow can also be thermally regulated, subliming at relatively low temperature ( less than100 C) to yield I2 vapor at or below 50 torr. At low power, the measured performance of an iodine-fed HET is very similar to that of a state-of-the-art xenon-fed thruster. Just as importantly, the current-voltage discharge characteristics of low power iodine-fed and xenon-fed thrusters are remarkably similar, potentially reducing development and qualifications costs by making it possible to use an already-qualified xenon-HET PPU in an iodine-fed system. Finally, a cold surface can be installed in a vacuum test chamber on which expended iodine propellant can deposit. In addition, the temperature doesn't have to be extremely cold to maintain a low vapor pressure in the vacuum chamber (it is under 10(exp -6) torr at -75 C), making it possible to 'cryopump' the propellant with lower-cost recirculating refrigerant-based systems as opposed to using liquid nitrogen or low temperature gaseous helium cryopanels. In the present paper, we describe testing performed using an iodine-fed 200 W Hall thruster mounted to a thrust stand and operated in conjunction with MSFCs Small Projects Rapid Integration and Test Environment (SPRITE) Portable Hardware In the Loop (PHIL) hardware. This work is performed in support of the iodine satellite (iSAT) project, which aims to fly a 200-W iodine-fed thruster on a 12-U CubeSat. The SPRITE PHIL hardware allows a given vehicle to do a checkout of its avionics algorithm by allowing it to monitor and feed data to simulated sensors and effectors in a digital environment. These data are then used to determine the attitude of the vehicle and a separate computer is used to interpret the data set and visualize it using a 3D graphical interface. The PHIL hardware allows the testing of the vehicles bus by providing 'real' hardware interfaces (in the case of this test a real RS422 bus) and specific components can be modeled to show their interactions with the avionics algorithm (e.g. a thruster model). For the iSAT project the PHIL is used to visualize the operating cycle of the thruster and the subsequent effect this thrusting has on the attitude of the satellite over a given period of time. The test is controlled using software running on an Andrews Space Cortex 160 flight computer. This computer is the current baseline for a full iSAT mission. While the test could be conducted with a lab computer and software, the team chose to exercise the propulsion system with a representative CubeSat-class computer. For purposes of this test, the "flight" software monitored the propulsion and PPU systems, controlled operation of the thruster, and provided thruster state data to the PHIL simulation. Commands to operate the thruster were initiated from an operator's workstation outside the vacuum chamber and passed through the Cortex 160 to exercise portions of the flight avionics. Two custom-designed pieces of electronics hardware have been designed to operate the propellant feed system. One piece of hardware is an auxiliary board that controls a latch valve, proportional flow control valves (PFCVs) and valve heaters as well as measuring pressures, temperatures and PFCV feedback voltage. An onboard FPGA provides a serial link for issuing commands and manages all lower level input-output functions. The other piece of hardware is a power distribution board, which accepts a standard bus voltage input and converts this voltage into all the different current-voltage types required to operate the auxiliary board. These electronics boards are located in the vacuum chamber near the thruster, exposing this hardware to both the vacuum and plasma environments they would encounter during a mission, with these components communicating to the flight computer through an RS-422 interface. The auxiliary board FPGA provides a 28V MOSFET switch circuit with a 20ms pulse to open or close the iodine propellant feed system latch valve. The FPGA provides a pulse width modulation (PWM) signal to a DC/DC boost converter to produce the 12-120V needed for control of the proportional flow control valve. There are eight MOSFET-switched heating circuits in the system. Heaters are 28V and located in the latch valve, PFCV, propellant tank and propellant feed lines. Both the latch valve and PFCV have thermistors built into them for temperature monitoring. There are also seven resistance temperature device (RTD) circuits on the auxiliary board that can be used to measure the propellant tank and feedline temperatures. The signals are conditioned and sent to an analog to digital converter (ADC), which is directly commanded and controlled by the FPGA.

Polzin, Kurt A.↗

Quantitative Risk Analysis of High Safety Significant Safety-related Digital Instrumentation and Control Systems in Nuclear Power Plants using IRADIC Technology

This report documents the activities performed by Idaho National Laboratory (INL) during fiscal year (FY) 2021 for the U.S. Department of Energy (DOE) Light Water Reactor Sustainability (LWRS) Program, Risk Informed Systems Analysis (RISA) Pathway, digital instrumentation and control (DI&C) Risk Assessment project. In FY-2019, the RISA Pathway initiated a project to develop a risk assessment strategy for delivering a strong technical basis to support effective, licensable, and secure DI&C technologies for digital upgrades/designs. An integrated risk assessment technology for the DI&C systems (IRADIC technology) was proposed for this strategy, which aims to (1) provide a best-estimate risk-informed capability to quantitatively and accurately estimate the safety margin obtained from plant modernization, especially for the High Safety Significant Safety-related (HSSSR) DI&C systems, (2) develop an advanced risk assessment technology to support transition from analog to DI&C technologies for nuclear industry, (3) assure the long-term safety and reliability of vital HSSSR DI&C systems, (4) reduce uncertainty in costs and support integration of DI&C systems in the plant. To achieve these technical goals and deal with the expensive licensing justifications from regulatory insights, the IRADIC technology is instructive for nuclear vendors and utilities to effectively lower the costs associated with digital compliance and speed industry advances by: (1) defining an integrated risk-informed analysis process for DI&C upgrade, including hazard analysis, reliability analysis, and consequence analysis, (2) applying systematic and risk-informed tools to address common cause failures (CCFs) and quantify responding failure probabilities for DI&C technologies, particularly software CCFs, (3) evaluating the impact of digital failures at the individual level, system level, and plant level, (4) providing insights and suggestions on designs to manage the risks; thus, to support the development, licensing, and deployment of advanced DI&C technologies on nuclear power plant (NPPs). In this report, an approach for performing software CCF analysis, given limited data, is developed and demonstrated using a case study of a highly redundant digital reactor trip system. Consequence analysis is also performed based on different accident scenarios. Results indicate that plant modernization including the improvement of HSSSR DI&C systems will make great benefits to plant safety by providing more safety margins to accident management. In addition, a novel approach is proposed in this report for the quantification of software hazards when sufficient operational and testing data available. The method incorporates software development quality as well as strong analysis techniques to identify and link software defects to potential failure modes. The approach includes both semantic and test-based analysis to detect failures that can exist in different stages of the software development life cycle. This method is applied to an advanced human system interface relevant to reactor trip safety developed from the APR 1400 design.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Automation of electromagnetic compatability (EMC) test facilities

Efforts to automate electromagnetic compatibility (EMC) test facilities at Marshall Space Flight Center are discussed. The present facility is used to accomplish a battery of nine standard tests (with limited variations) deigned to certify EMC of Shuttle payload equipment. Prior to this project, some EMC tests were partially automated, but others were performed manually. Software was developed to integrate all testing by means of a desk-top computer-controller. Near real-time data reduction and onboard graphics capabilities permit immediate assessment of test results. Provisions for disk storage of test data permit computer production of the test engineer's certification report. Software flexibility permits variation in the tests procedure, the ability to examine more closely those frequency bands which indicate compatibility problems, and the capability to incorporate additional test procedures.

Harrison, C. A.↗

STGT program: Ada coding and architecture lessons learned

STGT (Second TDRSS Ground Terminal) is currently halfway through the System Integration Test phase (Level 4 Testing). To date, many software architecture and Ada language issues have been encountered and solved. This paper, which is the transcript of a presentation at the 3 Dec. meeting, attempts to define these lessons plus others learned regarding software project management and risk management issues, training, performance, reuse, and reliability. Observations are included regarding the use of particular Ada coding constructs, software architecture trade-offs during the prototyping, development and testing stages of the project, and dangers inherent in parallel or concurrent systems, software, hardware, and operations engineering.

Usavage, Paul↗

A Vehicle Management End-to-End Testing and Analysis Platform for Validation of Mission and Fault Management Algorithms to Reduce Risk for NASA's Space Launch System

The development of the Space Launch System (SLS) launch vehicle requires cross discipline teams with extensive knowledge of launch vehicle subsystems, information theory, and autonomous algorithms dealing with all operations from pre-launch through on orbit operations. The characteristics of these systems must be matched with the autonomous algorithm monitoring and mitigation capabilities for accurate control and response to abnormal conditions throughout all vehicle mission flight phases, including precipitating safing actions and crew aborts. This presents a large complex systems engineering challenge being addressed in part by focusing on the specific subsystems handling of off-nominal mission and fault tolerance. Using traditional model based system and software engineering design principles from the Unified Modeling Language (UML), the Mission and Fault Management (M&FM) algorithms are crafted and vetted in specialized Integrated Development Teams composed of multiple development disciplines. NASA also has formed an M&FM team for addressing fault management early in the development lifecycle. This team has developed a dedicated Vehicle Management End-to-End Testbed (VMET) that integrates specific M&FM algorithms, specialized nominal and off-nominal test cases, and vendor-supplied physics-based launch vehicle subsystem models. The flexibility of VMET enables thorough testing of the M&FM algorithms by providing configurable suites of both nominal and off-nominal test cases to validate the algorithms utilizing actual subsystem models. The intent is to validate the algorithms and substantiate them with performance baselines for each of the vehicle subsystems in an independent platform exterior to flight software test processes. In any software development process there is inherent risk in the interpretation and implementation of concepts into software through requirements and test processes. Risk reduction is addressed by working with other organizations such as S&MA, Structures and Environments, GNC, Orion, the Crew Office, Flight Operations, and Ground Operations by assessing performance of the M&FM algorithms in terms of their ability to reduce Loss of Mission and Loss of Crew probabilities. In addition, through state machine and diagnostic modeling, analysis efforts investigate a broader suite of failure effects and detection and responses that can be tested in VMET and confirm that responses do not create additional risks or cause undesired states through interactive dynamic effects with other algorithms and systems. VMET further contributes to risk reduction by prototyping and exercising the M&FM algorithms early in their implementation and without any inherent hindrances such as meeting FSW processor scheduling constraints due to their target platform - ARINC 653 partitioned OS, resource limitations, and other factors related to integration with other subsystems not directly involved with M&FM. The plan for VMET encompasses testing the original M&FM algorithms coded in the same C++ language and state machine architectural concepts as that used by Flight Software. This enables the development of performance standards and test cases to characterize the M&FM algorithms and sets a benchmark from which to measure the effectiveness of M&FM algorithms performance in the FSW development and test processes. This paper is outlined in a systematic fashion analogous to a lifecycle process flow for engineering development of algorithms into software and testing. Section I describes the NASA SLS M&FM context, presenting the current infrastructure, leading principles, methods, and participants. Section II defines the testing philosophy of the M&FM algorithms as related to VMET followed by section III, which presents the modeling methods of the algorithms to be tested and validated in VMET. Its details are then further presented in section IV followed by Section V presenting integration, test status, and state analysis. Finally, section VI addresses the summary and forward directions followed by the appendices presenting relevant information on terminology and documentation.

Trevino, Luis↗

GPS Navigation Results from the Low Power Transceiver CANDOS Experiment on STS-107

This paper presents the Global Positioning System (GPS) navigation results from the Communications and Savigation Demonstration on Shuttle (CANDOS) experiment flown on STS- 107. The CAkDOS experiment consisted of the Low Power Transceiver (LPT) that hosted the GPS Enhanced Orbit Determination Experiment (GEODE) orbit determination software. All CANDOS test data were recovered during the mission using the LPT's Tracking and Data Relay Satellite System (TDRSS) uplinh'downlink communications capabilit! . An overview of the LPT's navigation software and the GPS experiment timeline is presented. In addition. this paper discusses GEODE performance results. including comparisons ibith the Best Estimate of Trajectory (BET). N.ASA Johnson Space Center (JSC) real-time ground navigation vectors. and post-processed solutions using the Goddard Trajectory Determination System (GTDS).

Haas, Lin↗

N-S3 Cellular Vehicle-to-Everything (C-V2X) Cosimulation Framework [SWR-24-54]

This is a vehicular networking simulator designed to enable synchronized network simulation with vehicle traffic simulation software. The communications model is based on the 3GPP LTE-V2X Mode 4 protocol, but includes several other wireless network protocol models as well. This simulator includes both a V2X network simulation implemented in ns-3 as well as an interface to automatically configure, run, and interact with a set of ns-3 instances based on network size and available hardware. This software has been tested with Aimsun NEXT 2.0 simulator (with V2X SDK), but uses a generic interface for compatibility with any comparable vehicle traffic simulator across the HELICS co-simulation framework. This software is intended as a generalized extension to vehicle traffic simulation, and does not model any vehicle traffic on its own.

Wang, Qichao↗

Spring 2023 Verification Presentation to Headquarters [Slides]

Testing codes is important, and more tests are needed. Verification testing is different than software-quality assurance, like regression suites. Tests should be simple, but not too simple, and tests should be code agnostic. Developing verification methods is still open research. Testing single-physics code pieces in isolation may lead to bad results when they are coupled. Good verification tests must include multiple physics models, multiple materials, and be performed in multiple dimensions.

97 MATHEMATICS AND COMPUTING↗

Integrated Test Approach

This paper describes a testing methodology undertaken on the Facilities Development and Operations Contract (FDOC) by Lockheed Martin. The methodology was defined with the intent of reducing project schedule time to enable NASA's Johnson Space Center (JSC) to be able to deliver the Mission Control Center (MCC) 21 project as quickly as possible. 21 represents the 21st century where NASA JSC is updating its control center with new technology and operational concepts in order to support NASA customers wanting to use control center assets to support space vehicle operations. In collaboration with the NASA customer, a new test concept was conceived early during MCC21 project planning with the goal of reducing project delivery time. One enabler that could help reduce delivery time was testing. Within the project, testing was performed by two entities, software development responsible for subsystem testing and system test responsible for system integration testing. The MCC21 project took a deliberate review of testing to determine how it could be performed differently to realize an overall reduction in test time to support the goal of a more rapid project delivery.

Cotton, Will↗

Mars Science Laboratory Boot Robustness Testing

Mars Science Laboratory (MSL) is one of the most complex spacecrafts in the history of mankind. Due to the nature of its complexity, a large number of flight software (FSW) requirements have been written for implementation. In practice, these requirements necessitate very complex and very precise flight software with no room for error. One of flight software's responsibilities is to be able to boot up and check the state of all devices on the spacecraft after the wake up process. This boot up and initialization is crucial to the mission success since any misbehavior of different devices needs to be handled through the flight software. I have created a test toolkit that allows the FSW team to exhaustively test the flight software under variety of different unexpected scenarios and validate that flight software can handle any situation after booting up. The test includes initializing different devices on spacecraft to different configurations and validate at the end of the flight software boot up that the flight software has initialized those devices to what they are suppose to be in that particular scenario.

mission phases↗