Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “program verification”

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 757 records · Page 42
All sourcesNASA NTRSDOE OSTI
NASA NTRS1995

(abstract) Cassini MLI Balnkets High-Temperature Exposure Tests

The trajectory required for the Cassini spacecraft to reach Saturn will subject the spacecraft to a 0.61 AU temperature environment at perihelion. Temperatures on some sunlit blanket surfaces at 0.61 AU can reach levels that are beyond the service capability of the conventional Mylar/Dacron net MLI. The majority of the blanket surfaces, however, will experience temperatures with an upper bound of 250(deg) C. The maximum allowable temperature for Mylar/Dacron net is determined to be 220(deg)C. Kapton can withstand temperatures in excess of 400(deg) C; however, the high cost of embossed Kapton relative to Mylar/Dacron net requires a baseline design which includes a standard layup and a high-temperature layup. The high-temperature layup is utilized at a limited number of locations, while at least 90% of the blankets are of the standard layup. The verification of both layups' capability to meet all temperature requirements has been accomplished by a comprehensive test program which addressed their high-temperature survivability, effective emittance, and optical and electrical properties. This paper focuses on the high-temperature exposure tests which helped define the hybrid standard layup, and which demonstrated the adequacy of both layups in withstanding their respective thermal environments.

temperature control insulation Cassini↗
NASA NTRS2005

Assemby, test, and launch operations for the Mars Exploration Rovers

In January of 2004, NASA's twin Mars rovers, Spirit and Opportunity, successfully landed on opposite sides of the Red Planet after a seven month Earth to Mars cruise period. Both vehicles have operated well beyond their 90 day primary mission design life requirements. The Assembly, Test, and Launch Operations (ATLO) program for these missions presented unique technical and schedule challenges to the team at the Jet Propulsion Laboratory (JPL). Among these challenges were a highly compressed schedule and late deliveries leading to extended double shift staffing, dual spacecraft operations requiring test program diversification and resource arbitration, multiple atypical test configurations for airbag/rocket landings and surface mobility testing, and verification of an exceptionally large number of separations, deployments, and mechanisms. This paper discusses the flight system test philosophies and approach, and presents lessons learned.

Assembly, Test, and Launch Operations (ATLO)↗
NASA NTRS2011

Developing Flexible Discrete Event Simulation Models in an Uncertain Policy Environment

On February 1st, 2010 U.S. President Barack Obama submitted to Congress his proposed budget request for Fiscal Year 2011. This budget included significant changes to the National Aeronautics and Space Administration (NASA), including the proposed cancellation of the Constellation Program. This change proved to be controversial and Congressional approval of the program's official cancellation would take many months to complete. During this same period an end-to-end discrete event simulation (DES) model of Constellation operations was being built through the joint efforts of Productivity Apex Inc. (PAl) and Science Applications International Corporation (SAIC) teams under the guidance of NASA. The uncertainty in regards to the Constellation program presented a major challenge to the DES team, as to: continue the development of this program-of-record simulation, while at the same time remain prepared for possible changes to the program. This required the team to rethink how it would develop it's model and make it flexible enough to support possible future vehicles while at the same time be specific enough to support the program-of-record. This challenge was compounded by the fact that this model was being developed through the traditional DES process-orientation which lacked the flexibility of object-oriented approaches. The team met this challenge through significant pre-planning that led to the "modularization" of the model's structure by identifying what was generic, finding natural logic break points, and the standardization of interlogic numbering system. The outcome of this work resulted in a model that not only was ready to be easily modified to support any future rocket programs, but also a model that was extremely structured and organized in a way that facilitated rapid verification. This paper discusses in detail the process the team followed to build this model and the many advantages this method provides builders of traditional process-oriented discrete event simulations.

Miranda, David J.↗
NASA NTRS2012

Design and Analysis of Modules for Segmented X-Ray Optics

Future X-ray astronomy missions demand thin, light, and closely packed optics which lend themselves to segmentation of the annular mirrors and, in turn, a modular approach to the mirror design. The modular approach to X-ray Flight Mirror Assembly (FMA) design allows excellent scalability of the mirror technology to support a variety of mission sizes and science objectives. This paper describes FMA designs using slumped glass mirror segments for several X-ray astrophysics missions studied by NASA and explores the driving requirements and subsequent verification tests necessary to qualify a slumped glass mirror module for space-flight. A rigorous testing program is outlined allowing Technical Development Modules to reach technical readiness for mission implementation while reducing mission cost and schedule risk.

McClelland, Ryan S.↗
NASA NTRS2014

Verification and Validation of the General Mission Analysis Tool (GMAT)

This paper describes the processes and results of Verification and Validation (V&V) efforts for the General Mission Analysis Tool (GMAT). We describe the test program and environments, the tools used for independent test data, and comparison results. The V&V effort produced approximately 13,000 test scripts that are run as part of the nightly buildtest process. In addition, we created approximately 3000 automated GUI tests that are run every two weeks. Presenting all test results are beyond the scope of a single paper. Here we present high-level test results in most areas, and detailed test results for key areas. The final product of the V&V effort presented in this paper was GMAT version R2013a, the first Gold release of the software with completely updated documentation and greatly improved quality. Release R2013a was the staging release for flight qualification performed at Goddard Space Flight Center (GSFC) ultimately resulting in GMAT version R2013b.

GMAT↗
NASA NTRS2016

Functional Fault Model Development Process to Support Design Analysis and Operational Assessment

A functional fault model (FFM) is an abstract representation of the failure space of a given system. As such, it simulates the propagation of failure effects along paths between the origin of the system failure modes and points within the system capable of observing the failure effects. As a result, FFMs may be used to diagnose the presence of failures in the modeled system. FFMs necessarily contain a significant amount of information about the design, operations, and failure modes and effects. One of the important benefits of FFMs is that they may be qualitative, rather than quantitative and, as a result, may be implemented early in the design process when there is more potential to positively impact the system design. FFMs may therefore be developed and matured throughout the monitored system's design process and may subsequently be used to provide real-time diagnostic assessments that support system operations. This paper provides an overview of a generalized NASA process that is being used to develop and apply FFMs. FFM technology has been evolving for more than 25 years. The FFM development process presented in this paper was refined during NASA's Ares I, Space Launch System, and Ground Systems Development and Operations programs (i.e., from about 2007 to the present). Process refinement took place as new modeling, analysis, and verification tools were created to enhance FFM capabilities. In this paper, standard elements of a model development process (i.e., knowledge acquisition, conceptual design, implementation & verification, and application) are described within the context of FFMs. Further, newer tools and analytical capabilities that may benefit the broader systems engineering process are identified and briefly described. The discussion is intended as a high-level guide for future FFM modelers.

Verification↗
NASA NTRS2020

Developing and Implementing a Process to Verify and Validate the NASA InSight Mission’s Instrument Command Products

The NASA InSight Mars lander is a roboticspacecraft which is investigating the interior structure of Marsthrough a series of seismological measurements andexperiments. Much of the commanding of activities performedby the instruments was done using ‘blocks’ – reusable functionswritten in Virtual Machine Language stored onboard thespacecraft– and sequences (series of commands) that werecreated by teams to operate their instruments. It was vital thatthese blocks and sequences (collectively called commandproducts) be thoroughly examined prior to onboard executionusing a comprehensive test program to reduce risk to thespacecraft and instruments and ensure smooth operations onthe surface of Mars. The Verification and Validation (V&V)process that was designed and implemented during the monthsleading up to InSight’s launch and landing successfullyuncovered a number of issues that could have causedoperational delays or impacted hardware. The process alsohelped adapt ground tools to better model onboard activities,create operational principles to avoid unintended consequencesduring flight, and generate a reference database for commandproduct use during operations. This allowed InSight to meet itssurface operations goals in the desired timeframe. This paperdescribes the development, implementation and results ofInSight’s command product V&V process, its contribution tomission success, and challenges faced.

Cloutier, Kyle↗
NASA NTRS2003

Design for Verification: Using Design Patterns to Build Reliable Systems

Components so far have been mainly used in commercial software development to reduce time to market. While some effort has been spent on formal aspects of components, most of this was done in the context of programming language or operating system framework integration. As a consequence, increased reliability of composed systems is mainly regarded as a side effect of a more rigid testing of pre-fabricated components. In contrast to this, Design for Verification (D4V) puts the focus on component specific property guarantees, which are used to design systems with high reliability requirements. D4V components are domain specific design pattern instances with well-defined property guarantees and usage rules, which are suitable for automatic verification. The guaranteed properties are explicitly used to select components according to key system requirements. The D4V hypothesis is that the same general architecture and design principles leading to good modularity, extensibility and complexity/functionality ratio can be adapted to overcome some of the limitations of conventional reliability assurance measures, such as too large a state space or too many execution paths.

Mehlitz, Peter C.↗
NASA NTRS2008

Development of a New Data Tool for Computing Launch and Landing Availability with Respect to Surface Weather

The Marshall Space Flight Center Natural Environments Branch has a long history of expertise in the modeling and computation of statistical launch availabilities with respect to weather conditions. Their existing data analysis product, the Atmospheric Parametric Risk Assessment (APRA) tool, computes launch availability given an input set of vehicle hardware and/or operational weather constraints by calculating the climatological probability of exceeding the specified constraint limits, APRA has been used extensively to provide the Space Shuttle program the ability to estimate impacts that various proposed design modifications would have to overall launch availability. The model accounts for both seasonal and diurnal variability at a single geographic location and provides output probabilities for a single arbitrary launch attempt. Recently, the Shuttle program has shown interest in having additional capabilities added to the APRA model, including analysis of humidity parameters, inclusion of landing site weather to produce landing availability, and concurrent analysis of multiple sites, to assist in operational landing site selection. In addition, the Constellation program has also expressed interest in the APRA tool, and has requested several additional capabilities to address some Constellation-specific issues, both in the specification and verification of design requirements and in the development of operations concepts. The combined scope of the requested capability enhancements suggests an evolution of the model beyond a simple revision process. Development has begun for a new data analysis tool that will satisfy the requests of both programs. This new tool, Probabilities of Atmospheric Conditions and Environmental Risk (PACER), will provide greater flexibility and significantly enhanced functionality compared to the currently existing tool.

Burns, K. Lee↗
NASA NTRS1979

Evaluation of verifiability in HAL/S

The ability of HAL/S to write verifiable programs, a characteristic which is highly desirable in aerospace applications, is lacking since many of the features of HAL/S do not lend themselves to existing verification techniques. The methods of language evaluation are described along with the means in which language features are evaluated for verifiability. These methods are applied in this study to various features of HAL/S to identify specific areas in which the language fails with respect to verifiability. Some conclusions are drawn for the design of programming languages for aerospace applications and ongoing work to identify a verifiable subset of HAL/S is described.

Young, W. D.↗
NASA NTRS2009

The Integrated Hazard Analysis Integrator

Hazard analysis addresses hazards that arise in the design, development, manufacturing, construction, facilities, transportation, operations and disposal activities associated with hardware, software, maintenance, operations and environments. An integrated hazard is an event or condition that is caused by or controlled by multiple systems, elements, or subsystems. Integrated hazard analysis (IHA) is especially daunting and ambitious for large, complex systems such as NASA s Constellation program which incorporates program, systems and element components that impact others (International Space Station, public, International Partners, etc.). An appropriate IHA should identify all hazards, causes, controls and verifications used to mitigate the risk of catastrophic loss of crew, vehicle and/or mission. Unfortunately, in the current age of increased technology dependence, there is the tendency to sometimes overlook the necessary and sufficient qualifications of the integrator, that is, the person/team that identifies the parts, analyzes the architectural structure, aligns the analysis with the program plan and then communicates/coordinates with large and small components, each contributing necessary hardware, software and/or information to prevent catastrophic loss. As viewed from both Challenger and Columbia accidents, lack of appropriate communication, management errors and lack of resources dedicated to safety were cited as major contributors to these fatalities. From the accident reports, it would appear that the organizational impact of managers, integrators and safety personnel contributes more significantly to mission success and mission failure than purely technological components. If this is so, then organizations who sincerely desire mission success must put as much effort in selecting managers and integrators as they do when designing the hardware, writing the software code and analyzing competitive proposals. This paper will discuss the necessary and sufficient requirements of one of the significant contributors to mission success, the IHA integrator. Discussions will be provided to describe both the mindset required as well as deleterious assumptions/behaviors to avoid when integrating within a large scale system.

Morris, A. Terry↗
NASA NTRS2023

On-Board Deployment Event Verification for GOES-R Spacecraft

As is common with many spacecraft designs, the GOES-R vehicles require a series of deployment events to transition from the launch configuration to the operational configuration. Rather than implementing additional sensors to verify various deployments, the GOES-R program developed an alternate approach that uses existing gyro rate sensing. The approach includes two pieces: the first is a new onboard shock detection capability to confirm initiation of individual deployment events, and the second is a ground-based dynamics verification step to confirm completion of deployment events. We first present the algorithm that detects shock events for various deployment devices along with the parameter tuning performed during ground tests. We then show inflight performance of the shock detection algorithm. While shock detection is useful for observing initiation of deployment events, completion of some deployment events cannot be determined by shock detection alone. For these events, such as solar panel latch-up and deployable boom extension, the program developed dynamics models for the deployment transient responses. High-rate gyro data were recorded for these events, which allow the ground team to verify that the appendages were fully deployed. We show the predictive models for these events and corresponding flight results.

GeoXO↗
NASA NTRS1985

The space shuttle launch vehicle aerodynamic verification challenges

The Space Shuttle aerodynamics and performance communities were challenged to verify the Space Shuttle vehicle (SSV) aerodynamics and system performance by flight measurements. Historically, launch vehicle flight test programs which faced these same challenges were unmanned instrumented flights of simple aerodynamically shaped vehicles. However, the manned SSV flight test program made these challenges more complex because of the unique aerodynamic configuration powered by the first man-rated solid rocket boosters (SRB). The analyses of flight data did not verify the aerodynamics or performance preflight predictions of the first flight of the Space Transportation System (STS-1). However, these analyses have defined the SSV aerodynamics and verified system performance. The aerodynamics community also was challenged to understand the discrepancy between the wind tunnel and flight defined aerodynamics. The preflight analysis challenges, the aerodynamic extraction challenges, and the postflight analyses challenges which led to the SSV system performance verification and which will lead to the verification of the operational ascent aerodynamics data base are presented.

Wallace, R. O.↗
NASA NTRS1992

SEDS1 mission software verification using a signal simulator

The first flight of the Small Expendable Deployer System (SEDS1) is schedule to fly as the secondary payload of a Delta 2 in March, 1993. The objective of the SEDS1 mission is to collect data to validate the concept of tethered satellite systems and to verify computer simulations used to predict their behavior. SEDS1 will deploy a 50 lb. instrumented satellite as an end mass using a 20 km tether. Langley Research Center is providing the end mass instrumentation, while the Marshall Space Flight Center is designing and building the deployer. The objective of the experiment is to test the SEDS design concept by demonstrating that the system will satisfactorily deploy the full 20 km tether without stopping prematurely, come to a smooth stop on the application of a brake, and cut the tether at the proper time after it swings to the local vertical. Also, SEDS1 will collect data which will be used to test the accuracy of tether dynamics models used to stimulate this type of deployment. The experiment will last about 1.5 hours and complete approximately 1.5 orbits. Radar tracking of the Delta II and end mass is planned. In addition, the SEDS1 on-board computer will continuously record, store, and transmit mission data over the Delta II S-band telemetry system. The Data System will count tether windings as the tether unwinds, log the times of each turn and other mission events, monitor tether tension, and record the temperature of system components. A summary of the measurements taken during the SEDS1 are shown. The Data System will also control the tether brake and cutter mechanisms. Preliminary versions of two major sections of the flight software, the data telemetry modules and the data collection modules, were developed and tested under the 1990 NASA/ASEE Summer Faculty Fellowship Program. To facilitate the debugging of these software modules, a prototype SEDS Data System was programmed to simulate turn count signals. During the 1991 summer program, the concept of simulating signals produced by the SEDS electronics systems and circuits was expanded and more precisely defined. During the 1992 summer program, the SEDS signal simulator was programmed to test the requirements of the SEDS Mission software, and this simulator will be used in the formal verification of the SEDS Mission Software. The formal test procedures specification was written which incorporates the use of the signal simulator to test the SEDS Mission Software and which incorporates procedures for testing the other major component of the SEDS software, the Monitor Software.

Pierson, William E.↗
NASA NTRSDate not supplied

Toward Verification of the γ-Reθt Transition Model in OVERFLOW and FUN3D

The results of an ongoing assessment of the transition modeling capability in NASA's OVERFLOW and FUN3D programs are presented, with a focus on the Langtry-Menter γ-Reθt transition model in combination with the shear-stress transport (SST) turbulence model. While the effect of numerics and boundary conditions on the accuracy and iterative convergence of RANS solutions for fully turbulent flows has been well documented, especially in the context of canonical flow configurations, the same cannot be said for transport-equation-based transition models coupled with RANS-based turbulence models. Given the criticality of transition modeling for new aircraft design and optimization, there has been a renewed focus on the accuracy of such transition models and their inconsistent implementation across different flow solvers as seen from the AIAA and NATO-AVT workshops. In this work, we aim to establish the verification of such models via these two well established CFD codes with different numerics. The goal is to produce high-quality data, such as grids, solutions, and other auxiliary data, that may be utilized for code verification by others in the CFD community. As a first step, the work reported here is focused on the Langtry-Menter transition model as applied to two simple 2D configurations, namely the flat plate, and the NLF-0416, respectively. The paper also highlights how the boundary conditions and baseline turbulence model can affect the solutions from the SST-based Langtry-Menter transition model. A preliminary evaluation of the automatic mesh adaption capabilities of these solvers and potential benefits for flow configurations involving a mix of laminar, transitional, and fully turbulent flows is also reported.

CFD Modeling↗
NASA NTRS1971

The programming language HAL: A specification

HAL accomplishes three significant objectives: (1) increased readability, through the use of a natural two-dimensional mathematical format; (2) increased reliability, by providing for selective recognition of common data and subroutines, and by incorporating specific data-protect features; (3) real-time control facility, by including a comprehensive set of real-time control commands and signal conditions. Although HAL is designed primarily for programming on-board computers, it is general enough to meet nearly all the needs in the production, verification and support of aerospace, and other real-time applications.

Source record↗
NASA NTRS1973

Evaluation of an electrochemical N2/H2 gas separator

A program was successfully completed to evaluate an electrochemical nitrogen/hydrogen (N2/H2) separator for use in a spacecraft nitrogen (N2) generator. Based on the technical data obtained a N2/H2 separator subsystem consisting of an organic polymer gas permeator first stage and an electrochemical second and third stage was estimated to have the lowest total spared equivalent weight, 257 kg (566 lb), for a 15 lb/day N2 generation rate. A pre-design analysis of the electrochemical N2/H2 separator revealed that its use as a first stage resulted in too high a power requirement to be competitive with the organic polymer membrane and the palladium-silver membrane separation methods. As a result, program emphasis was placed on evaluating the electrochemical. A parametric test program characterized cell performance and established second- and third-stage electrochemical N2/H2 separator operating conditions. A design verification test was completed on the second and third stages. The second stage was then successfully endurance tested for 200 hours.

Marshall, R. D.↗
NASA NTRS1975

Apollo experience report: Guidance and control systems; lunar module mission programer

A review of the concept, operational requirements, design, and development of the lunar module mission programer is presented, followed by a review of component and subsystem performance during design-feasibility, design-verification, and qualification tests performed in the laboratory. The system was further proved on the unmanned Apollo 5 mission. Several anomalies were detected, and satisfactory solutions were found. These problems are defined and examined, and the corrective action taken is discussed. Suggestions are given for procedural changes to be used if future guidance and control systems of this type are to be developed.

Vernon, J. A.↗