Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “automated 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 235 records · Page 13

NASA Tech Briefs, August 2007

Topics include: Program Merges SAR Data on Terrain and Vegetation Heights; Using G(exp 4)FETs as a Data Router for In-Plane Crossing of Signal Paths; Two Algorithms for Processing Electronic Nose Data; Radiation-Tolerant Dual Data Bus; General-Purpose Front End for Real-Time Data Processing; Nanocomposite Photoelectrochemical Cells; Ultracapacitor-Powered Cordless Drill, Cumulative Timers for Microprocessors; Photocatalytic/Magnetic Composite Particles; Separation and Sealing of a Sample Container Using Brazing; Automated Aerial Refueling Hitches a Ride on AFF; Cobra Probes Containing Replaceable Thermocouples; High-Speed Noninvasive Eye-Tracking System; Detergent-Specific Membrane Protein Crystallization Screens; Evaporation-Cooled Protective Suits for Firefighters; Plasmonic Antenna Coupling for QWIPs; Electronic Tongue Containing Redox and Conductivity Sensors; Improved Heat-Stress Algorithm; A Method of Partly Automated Testing of Software; Rover Wheel-Actuated Tool Interface; and Second-Generation Electronic Nose.

Source record↗

Occupant Protection at NASA

This slide presentation reviews NASA's efforts to arrive at protection of occupants of the ORION space craft on landing. An Abbreviated Injury Scale (AIS) has been developed, it is an anatomically-based, consensus-derived, global severity scoring system that classifies each injury by body region according to its relative importance on a 6-point ordinal scale. It reviews an Operationmally Relevant Injury Scale (ORIS), a classification methodology, and shows charts that detail the results of applying this ORIS to the injury databases. One chart uses NASCAR injury classification. It discusses providing a context for the level of risk inherent in the Orion landings in terms that people understand and have a sense for. For example is the risk of injury during an Orion landing roughly the same, better or worse than: An aircraft carrier landing, a NASCAR crash, or a helicopter crash, etc? The data for NASCAR and Indy Racing league (IRL) racing crash and injury data was reviewed. The risk from the Air Force, Navy, and Army injury data was also reviewed. Past NASA and the Soyuz programs injury risks are also reviewed. The work is an attempt to formulate a recommendation to the Orion Project for an acceptable level of injury risk associated with Nominal and Off-Nominal landing cases. The presentation also discusses the data mining and use of the data to Validate NASA Operationally-Relevant Injury Scale (NORIS) / Military Operationally-Relevant Injury Scale (MORIS), developing injury risk criteria, the types of data that are required, NASCAR modeling techniques and crash data, and comparison with the Brinkley model. The development of injury risk curves for each biodynamic response parameter is discussed. One of the main outcomes of this work is to establish an accurate Automated Test Dummy (ATD) that can be used to measure human tolerances.

Somers, Jeffrey↗

Symbolic PathFinder: Symbolic Execution of Java Bytecode

Symbolic Pathfinder (SPF) combines symbolic execution with model checking and constraint solving for automated test case generation and error detection in Java programs with unspecified inputs. In this tool, programs are executed on symbolic inputs representing multiple concrete inputs. Values of variables are represented as constraints generated from the analysis of Java bytecode. The constraints are solved using off-the shelf solvers to generate test inputs guaranteed to achieve complex coverage criteria. SPF has been used successfully at NASA, in academia, and in industry.

Pasareanu, Corina S.↗

Data Validation in the Kepler Science Operations Center Pipeline

We present an overview of the Data Validation (DV) software component and its context within the Kepler Science Operations Center (SOC) pipeline and overall Kepler Science mission. The SOC pipeline performs a transiting planet search on the corrected light curves for over 150,000 targets across the focal plane array. We discuss the DV strategy for automated validation of Threshold Crossing Events (TCEs) generated in the transiting planet search. For each TCE, a transiting planet model is fitted to the target light curve. A multiple planet search is conducted by repeating the transiting planet search on the residual light curve after the model flux has been removed; if an additional detection occurs, a planet model is fitted to the new TCE. A suite of automated tests are performed after all planet candidates have been identified. We describe a centroid motion test to determine the significance of the motion of the target photocenter during transit and to estimate the coordinates of the transit source within the photometric aperture; a series of eclipsing binary discrimination tests on the parameters of the planet model fits to all transits and the sequences of odd and even transits; and a statistical bootstrap to assess the likelihood that the TCE would have been generated purely by chance given the target light curve with all transits removed. Keywords: photometry, data validation, Kepler, Earth-size planets

Wu, Hayley↗

NASA Tech Briefs, December 2004

opics include: High-Rate Digital Receiver Board; Signal Design for Improved Ranging Among Multiple Transceivers; Automated Analysis, Classification, and Display of Waveforms; Fast-Acquisition/Weak-Signal-Tracking GPS Receiver for HEO; Format for Interchange and Display of 3D Terrain Data; Program Analyzes Radar Altimeter Data; Indoor Navigation using Direction Sensor and Beacons; Software Assists in Responding to Anomalous Conditions; Software for Autonomous Spacecraft Maneuvers; WinPlot; Software for Automated Testing of Mission-Control Displays; Nanocarpets for Trapping Microscopic Particles; Precious-Metal Salt Coatings for Detecting Hydrazines; Amplifying Electrochemical Indicators; Better End-Cap Processing for Oxidation-Resistant Polyimides; Carbon-Fiber Brush Heat Exchangers; Solar-Powered Airplane with Cameras and WLAN; A Resonator for Low-Threshold Frequency Conversion; Masked Proportional Routing; Algorithm Determines Wind Speed and Direction from Venturi-Sensor Data; Feature-Identification and Data-Compression Software; Alternative Attitude Commanding and Control for Precise Spacecraft Landing; Inspecting Friction Stir Welding using Electromagnetic Probes; and Helicity in Supercritical O2/H2 and C7H16/N2 Mixing Layers.

Source record↗

Autonomous Spacecraft Communication Interface for Load Planning

Ground-based controllers can remain in continuous communication with spacecraft in low Earth orbit (LEO) with near-instantaneous communication speeds. This permits near real-time control of all of the core spacecraft systems by ground personnel. However, as NASA missions move beyond LEO, light-time communication delay issues, such as time lag and low bandwidth, will prohibit this type of operation. As missions become more distant, autonomous control of manned spacecraft will be required. The focus of this paper is the power subsystem. For present missions, controllers on the ground develop a complete schedule of power usage for all spacecraft components. This paper presents work currently underway at NASA to develop an architecture for an autonomous spacecraft, and focuses on the development of communication between the Mission Manager and the Autonomous Power Controller. These two systems must work together in order to plan future load use and respond to unanticipated plan deviations. Using a nominal spacecraft architecture and prototype versions of these two key components, a number of simulations are run under a variety of operational conditions, enabling development of content and format of the messages necessary to achieve the desired goals. The goals include negotiation of a load schedule that meets the global requirements (contained in the Mission Manager) and local power system requirements (contained in the Autonomous Power Controller), and communication of off-plan disturbances that arise while executing a negotiated plan. The message content is developed in two steps: first, a set of rapid-prototyping "paper" simulations are preformed; then the resultant optimized messages are codified for computer communication for use in automated testing.

Controls↗

Experiment Design for Complex VTOL Aircraft with Distributed Propulsion and Tilt Wing

Selected experimental results from a wind tunnel study of a subscale VTOL concept with distributed propulsion and tilt lifting surfaces are presented. The vehicle complexity and automated test facility were ideal for use with a randomized designed experiment. Design of Experiments and Response Surface Methods were invoked to produce run efficient, statistically rigorous regression models with minimized prediction error. Static tests were conducted at the NASA Langley 12-Foot Low-Speed Tunnel to model all six aerodynamic coefficients over a large flight envelope. This work supports investigations at NASA Langley in developing advanced configurations, simulations, and advanced control systems.

Murphy, Patrick C.↗

Flight Software for the LADEE Mission

The Lunar Atmosphere and Dust Environment Explorer (LADEE) spacecraft was launched on September 6, 2013, and completed its mission on April 17, 2014 with a directed impact to the Lunar Surface. Its primary goals were to examine the lunar atmosphere, measure lunar dust, and to demonstrate high rate laser communications. The LADEE mission was a resounding success, achieving all mission objectives, much of which can be attributed to careful planning and preparation. This paper discusses some of the highlights from the mission, and then discusses the techniques used for developing the onboard Flight Software. A large emphasis for the Flight Software was to develop it within tight schedule and cost constraints. To accomplish this, the Flight Software team leveraged heritage software, used model based development techniques, and utilized an automated test infrastructure. This resulted in the software being delivered on time and within budget. The resulting software was able to meet all system requirements, and had very problems in flight.

LADEE↗

Software Verification of Orion Cockpit Displays

NASA's latest spacecraft Orion is in the development process of taking humans deeper into space. Orion is equipped with three main displays to monitor and control the spacecraft. To ensure the software behind the glass displays operates without faults, rigorous testing is needed. To conduct such testing, the Rapid Prototyping Lab at NASA's Johnson Space Center along with the University of Texas at Tyler employed a software verification tool, EggPlant Functional by TestPlant. It is an image based test automation tool that allows users to create scripts to verify the functionality within a program. A set of edge key framework and Common EggPlant Functions were developed to enable creation of scripts in an efficient fashion. This framework standardized the way to code and to simulate user inputs in the verification process. Moreover, the Common EggPlant Functions can be used repeatedly in verification of different displays.

Biswas, M. A. Rafe↗

Command and Control System Software Development

Kennedy Space Center has been the heart of human space flight for decades. From the Apollo Program to the Space Shuttle Program, and now to the coming Space Launch System (SLS) and Orion, NASA will be a leader in deep space exploration for mankind. Before any rockets blast off, there is significant work to be done in preparation for launch. People working on all aspects of spaceflight must contribute by developing new technology that has yet to participate in a successful launch, and which can work with technology already proven in flight. These innovations, whether hardware or software, must be tried and true, and includes the projects to which interns contribute to. For this internship, the objective was to create a data recording system for the developers of a LCS section that records certain messages in the traffic of the system. Developers would then be able to use these recordings for analysis later on, either manually or by an automated test. The tool would be of convenience to a developer as it would be used if the system's main data recorder was not available for tests.

Velasquez, Ricky↗

Data Validation in the Kepler Science Operations Center Pipeline

We present an overview of the Data Validation (DV) software component and its context within the Kepler ScienceOperations Center (SOC) pipeline and overall Kepler Science mission. The SOC pipeline performs a transiting planetsearch on the corrected light curves for over 150,000 targets across the focal plane array. We discuss the DV strategy forautomated validation of Threshold Crossing Events (TCEs) generated in the transiting planet search. For each TCE, atransiting planet model is fitted to the target light curve. A multiple planet search is conducted by repeating the transitingplanet search on the residual light curve after the model flux has been removed; if an additional detection occurs, aplanet model is fitted to the new TCE. A suite of automated tests are performed after all planet candidates have beenidentified. We describe a centroid motion test to determine the significance of the motion of the target photocenterduring transit and to estimate the coordinates of the transit source within the photometric aperture; a series of eclipsingbinary discrimination tests on the parameters of the planet model fits to all transits and the sequences of odd and eventransits; and a statistical bootstrap to assess the likelihood that the TCE would have been generated purely by chancegiven the target light curve with all transits removed.

photometry↗

Field Evaluations of Sampling, Interviewing, and Flight Tracking of NASA's Low Boom Flight Demonstrator Aircraft

The first year’s effort identified sampling and interviewing as the principal risks to assessment of prompt reactions to overflights producing low-amplitude sonic booms. It also 1) established the utility of geo-information system-based route planning for LBFD flight missions, 2) developed and demonstrated a prototype of a geographically-distributed, Internet-enabled instrumentation system capable of wide-area tracking of LBFD aircraft in near-real time. The latter system permits synchronizing the conduct of interviews in multiple overflown communities with arrival times of shock waves at interviewing sites; and of measuring, archiving, and processing their acoustic signatures. Means were also recommended for constructing representative, telephone-based samples of eligible respondents living in households within carpet boom corridors adjacent to LBFD flight tracks, and for conducting interviews with cross-sectional (independent) samples of such respondents about their prompt reactions to exposure to low-amplitude sonic booms. A detailed study design was prepared and accepted by NASA for a set of single-contact attempt telephone interviews with a nationally representative sample of households. The study design focused on testing automated and live agent interview completion rates obtainable without callbacks. A minimal (two monitoring station) version of the aircraft tracking system was built and installed near a civil airport in a successful demonstration of the system’s ability to detect and track aircraft movements. The field exercise also demonstrated the ability of the system to capture the acoustic emissions of departing aircraft, and to serve aircraft position and sound level information to remote, geographically-distributed analysts in near-real time. Upon approval of OMB and IRB of the detailed study plan, a stratified, nationally representative sample of landline and wireless telephone-subscribing households was constructed. A total of 12,734 telephone interview contact attempts of the sort required by a straightforward cross-sectional study design were then made. These contact attempts demonstrated the impracticality of conducting a time-critical, cross-sectional study of prompt community response to low-amplitude sonic booms by means of “independent” (single contact attempt per respondent for each LBFD flight mission) telephone samples of respondents. The observed interview completion rates for these single telephone contact attempts were so low (~ 1% to 3% for automated and live agent interviews, respectively) that: 1) the representativeness of collected opinions would be susceptible to intuitive challenge as inadequate, even absent conclusive evidence of non-representativeness. Refuting challenges to representativeness would have to demonstrate that the composition of the actual sample did not differ from that of the target population, a task that is tantamount to proving a negative; 2) the information required to refute allegations of non-representativeness would require a questionnaire considerably lengthier than that required simply to determine the prevalence of boom-induced startle and annoyance. Such a questionnaire would have to inquire about potentially sensitive and intrusive matters, including respondents’ age, gender, education, employment, home ownership, income, ethnicity, family size, and other demographic factors; and 3) unreasonable numbers of attempts would be required to re-contact households with unsuccessful initial contact attempts, given the limited time available for doing so. For example, if about 500 completed interviews were desired in a supersonically overflown community, approximately 50,000 automated interview attempts would have to be made within ten to fifteen minutes of each LBFD overflight. Such large numbers of contact attempts could well exceed the numbers of households available for interview in areas of similar boom exposure levels in some communities near LBFD flight tracks. Such large numbers of interviews could be cost-effectively undertaken only by means of automated (i.e., outgoing interactive voice response) interviewing, a data collection method ill-suited for complex and sensitive questionnaire items. The infeasibility of independent sampling for evaluating prompt responses to LBFD overflights in a cross-sectional study is due in large part to simple non-response: that is, potential respondents – particularly those contacted on wireless telephones – refusing to answer calls with unfamiliar caller IDs. It is also due in part, however, to 1) the lack of time to attempt to contact the same respondent more than once within a few minutes after the arrival of a shock wave at the respondent’s location; and 2) the need to place calls during weekday/daytime hours, when response rates are notably lower than during evenings and weekends. Despite the poor interview completion rates achieved under the above constraints, cross sectional assessments of delayed reactions to LBFD overflights could still be feasible, if multiple attempts could be made to contact respondents during evening and weekend time periods, over extended time periods. Detailed plans for a longitudinal (panel) sample were developed as an alternative to a cross sectional sample design.

Fidell, Sanford↗

Bridging the Gap Between Requirements and Model Analysis : Evaluation on Ten Cyber-Physical Challenge Problems

Formal verfication and simulation are powerful tools to validate requirements against complex systems. [Problem] Requirements are developed in early stages of the software lifecycle and are typically written in ambiguous natural language. There is a gap between such requirements and formal notations that can be used by verification tools, and lack of support for proper association of requirements with software artifacts for verification. [Principal idea] We propose to write requirements in an intuitive, structured natural language with formal semantics, and to support formalization and model/code verification as a smooth, well-integrated process. [Contribution] We have developed an end-to-end, open source requirements analysis framework that checks Simulink models against requirements written in structured natural language. Our framework is built in the Formal Requirements Elicitation Tool (fret); we use fret's requirements language named fretish, and formalization of fretish requirements in temporal logics. Our proposed framework contributes the following features: 1) automatic extraction of Simulink model information and association of fretish requirements with target model signals and components; 2) translation of temporal logic formulas into synchronous dataflow cocospec specifications as well as Simulink monitors, to be used by verification tools; we establish correctness of our translation through extensive automated testing; 3) interpretation of counterexamples produced by verification tools back at requirements level. These features support a tight integration and feedback loop between high level requirements and their analysis. We demonstrate our approach on a major case study: the Ten Lockheed Martin Cyber-Physical, aerospace-inspired challenge problems.

Mavridou, Anastasia↗

Adding Fresh Produce to the Space Diet

NASA’s Human Research Program has identified a Risk of inadequate nutrition and food stability as a risk of high concern for future long duration exploration missions such as a mission to Mars. One possible solution to help reduce this risk is the addition of in situ produced supplemental fresh produce to supplement and enhance the astronaut diet. A number of ground and ISS-based studies are being conducted which are helping to reduce this risk by filling the gaps in knowledge and technology associated with space crop production. These include studies with the Veggie vegetable production system on the International Space Station. Key focus areas include water and nutrient delivery, food safety and the crop microbiome, crop selection and testing, automation and robotics, radiation impacts, seed storage and handling, and scalability for different concepts and architectures. All of these areas have significant challenges that need to be addressed prior to successful integration of crop production into the crew diet. Data from these studies is feeding the development of new technologies and systems for space crop production. This research was funded by NASA Space Biology and NASA’s Human Research Program.

Gioia Massa↗

Adding Fresh Produce to the Space Diet

NASA’s Human Research Program has identified a Risk of inadequate nutrition and food stability as a risk of high concern for future long duration exploration missions such as a mission to Mars. One possible solution to help reduce this risk is the addition of in situ produced supplemental fresh produce to supplement and enhance the astronaut diet. A number of ground and ISS-based studies are being conducted which are helping to reduce this risk by filling the gaps in knowledge and technology associated with space crop production. These include studies with the Veggie vegetable production system on the International Space Station. Key focus areas include water and nutrient delivery, food safety and the crop microbiome, crop selection and testing, automation and robotics, radiation impacts, seed storage and handling, and scalability for different concepts and architectures. All of these areas have significant challenges that need to be addressed prior to successful integration of crop production into the crew diet. Data from these studies is feeding the development of new technologies and systems for space crop production. This research was funded by NASA Space Biology and NASA’s Human Research Program.

Space Crop Production↗

Ground Software Technologies – Embracing Change: Mission Drivers and Technology Opportunities to Enable Long Lived Missions

Mission lifecycles have proven to extend well beyond their original design. The benefits to this are countless but introduce challenges in today’s rapidly changing ground infrastructure and software technologies used to enable mission success. What remains constant is the risk posture missions maintain when accepting change and the use of new technologies. Larger missions are ready for change in early lifecycle development but near launch and especially in operations, few continue to evolve beyond what is set in place in phase C. This paper will discuss how the Advance Multi-Mission Operations System (AMMOS) intends to address, three driving missions concerns: Maintaining functionality (hardware/software) for decades, rapidly responding to security vulnerabilities in software, and finally the ability to quickly evolve infrastructure and software changes. These driving concerns are briefly described below: 1. Maintaining functionality (hardware/software) for decades. Hardware updates considerably faster than 10 years ago. Expectations that a system can remain in place for more than 10 years is no longer valid. Expecting to find hardware replacements for a system older than 5 years will increasingly become more and more challenging. How than do missions plan for hardware changes for long lived missions? Principle Objective: Provide abstraction by virtualizing and containerizing software abstract away any hardware dependencies and package up the application lightweight units. 2. Rapidly responding to security vulnerabilities in software. Cost is often the main impediment and largely driven by the revalidation and testing of system that undergo change. In todays, environment security updates are a major diver demanding systems remain up to date. How then do missions accept these changes and avoid large testing efforts? Principle Objective: Help reduce the cost of re-testing by automation of testing, deployment, and compartmentalizing change. 3. Ability to quickly evolve infrastructure and software changes. Responding quickly to change is similar to the second concern in this paper regarding security vulnerabilities. In this case, it address broader concerns of updating software and infrastructure on a more realistic timeline. How do missions stay up to date with the most recent versions of software and allowing for improved functionality? Principle Objective: Use continuous integration techniques at the system level to ensure rapid turnaround. This paper explores each of these concerns in more detail. It focuses the AMMOS’s current plans, challenges and current roadmap.

Giovannoni, Brian J.↗

Feature-Guided Analysis of Neural Networks

Applying standard software engineering practices to neural networks is challenging due to the lack of high-level abstractions describing a neural network’s behavior. To address this challenge, we propose to extract high-level task-specific features from the neural network internal representation, based on monitoring the neural network activations.The extracted feature representations can serve as a link to high-level requirements and can be leveraged to enable fundamental software engineering activities, such as automated testing, debugging, requirements analysis, and formal verification, leading to better engineering of neural networks. Using two case studies, we present initial empirical evidence demonstrating the feasibility of our ideas.

Features↗

NASA Armstrong Flight Research Center Dynamics and Controls (530)

AFRC Controls and Dynamics Branch - Research Areas: - Traditional GN&C - Classical and advanced control algorithms - Risk based approaches for safety critical applications - Integration of novel sensors and sensor fusion (FOSS, LIDAR, etc.) - Trajectory optimization and control - Flight/System Dynamics - Equations of Motion and integrated modeling of vehicles and vehicle systems - Unique and novel vehicle dynamics - Methods for extracting relevant vehicle dynamic information from flight data - Human and vehicle interfaces and interactions - Handling Qualities and Pilot-in-the-loop oscillations (PIO) predictions and design metrics - Ride quality research - Autonomy - Novel algorithms, sensors, and sensor fusion - Bounding risk for testing automated systems - Pilot/Operator interactions - Engineering Support and Airworthiness Assessments - Aircraft modifications and experimental configurations

Chris Miller↗