Results for “program verification” — Page 37

NASA NTRS1980

First Scientific Working Group Meeting of Airborne Doppler Lidar Wind Velocity Measurement Program

The purpose of the first scientific working group meeting was fourfold: (1) to identify flight test options for engineering verification of the MSFC Doppler Lidar; (2) to identify flight test options for gathering data for scientific/technology applications; (3) to identify additional support equipment needed on the CV 990 aircraft for the flight tests; and (4) to identify postflight data processing and data sets requirements. The working group identified approximately ten flight options for gathering data on atmospheric dynamics processes, including turbulence, valley breezes, and thunderstorm cloud anvil and cold air outflow dynamics. These test options will be used as a basis for planning the fiscal year 1981 tests of the Doppler Lidar system.

Kaufman, J. W.↗

NASA NTRS1981

A Module Experimental Process System Development Unit (MEPSDU)

The purpose of this program is to demonstrate the technical readiness of a cost effective process sequence that has the potential for the production of flat plate photovoltaic modules which met the price goal in 1986 of $.70 or less per watt peak. Program efforts included: preliminary design review, preliminary cell fabrication using the proposed process sequence, verification of sandblasting back cleanup, study of resist parameters, evaluation of pull strength of the proposed metallization, measurement of contact resistance of Electroless Ni contacts, optimization of process parameter, design of the MEPSDU module, identification and testing of insulator tapes, development of a lamination process sequence, identification, discussions, demonstrations and visits with candidate equipment vendors, evaluation of proposals for tabbing and stringing machine.

Source record↗

NASA NTRS1985

Implementation and verification of a comprehensive helicopter coupled rotor - Fuselage analysis

The analytical basis and the application of a Rotor/Airframe Comprehensive Aeroelastic Program (RACAP) are described in detail. The rationale behind each analytical choice is outlined and the modular procedure is described. The program is verified by application to the AH-1G helicopter. The applicability of various airload prediction models is examined, and both the steady and vibratory responses of the blade are compared with flight test data. Reasonable correlation is found between measured and calculated blade response, with excellent correlation for vibration amplitudes at various locations on the fuselage such as engine, pilot seat, and gunner. Within the analytical model, comparisons are drawn between an isolated blade analysis and a coupled rotor/fuselage model. The deficiency of the former in the context of the AH-1G is highlighted.

Wood, E. R.↗

NASA NTRS1986

N-ROSS: The dynamics and control issues

The Navy Remote Ocean Sensing System (N-ROSS) Dynamic Stability Study team concluded that the frozen April 1985 design was viable and contained no show stoppers, although it was also clear from the study results that the configuration required further optimization. While the frozen N-ROSS configuration used has since been superceded, and the vehicle is now under competitive procurement, several other results remain from the study that will have lasting value to the N-ROSS program. The importance of constructing an integrated simulation, to serve as a design and verification aid, has been clearly established. The two team approach to the study afforded the Navy a higher degree of confidence in the results than could have been accomplished by a single simulation, and the approach led to results that highlighted subtleties in the model and simulation development that surely would have been overlookded without the benefit of an independent companion simulation with which to compare it.

Lindberg, Robert E.↗

NASA NTRS1990

Advanced X-ray Astrophysics Facility - Extending man's vision into the X-ray universe

The Advanced X-ray Astrophysics Facility will open a clear window into the X-ray universe. This paper presents an overview of the history, objectives, and status of the program and its projected impact on man's knowledge of the cosmos. The program is shown to be a total system composed of subsystems and their interfaces, verification activities, operations considerations, and a comprehensive interface with the scientific community.

Miller, Lee A.↗

NASA NTRS1992

Verification of the PROS timing analysis package

ROSAT observations of known pulsars are used to verify the functions of timing programs. The Crab Pulsar and PSR 0540-69, with 33 and 50 millisecond periods, are used to examine the fast Fourier transform and the epoch-folding task used to search for periodic signals. These fast pulsars provide a more vigorous test of the system than those with periods of a few seconds.

Manning, K. R.↗

NASA NTRS1994

Load-limiting landing gear footpad energy absorption system

As a precursor to future manned missions to the moon, an inexpensive, unmanned vehicle that could carry small, scientific payloads to the lunar surface was studied by NASA. The vehicle, called the Common Lunar Lander, required extremely optimized structural systems to increase the potential payload mass. A lightweight energy-absorbing system (LAGFEAS), which also acts as a landing load-limiter was designed to help achieve this optimized structure. Since the versatile and easily tailored system is a load-limiter, it allowed for the structure to be designed independently of the ever-changing landing energy predictions. This paper describes the LAGFEAS system and preliminary verification testing performed at NASA's Johnson Space Center for the Common Lunar Lander program.

Hansen, Chris↗

NASA NTRS2005

JAVA PathFinder

JPF is an explicit state software model checker for Java bytecode. Today, JPF is a swiss army knife for all sort of runtime based verification purposes. This basically means JPF is a Java virtual machine that executes your program not just once (like a normal VM), but theoretically in all possible ways, checking for property violations like deadlocks or unhandled exceptions along all potential execution paths. If it finds an error, JPF reports the whole execution that leads to it. Unlike a normal debugger, JPF keeps track of every step how it got to the defect.

Mehhtz, Peter↗

NASA NTRS2013

Applications of Automation Methods for Nonlinear Fracture Test Analysis

Using automated and standardized computer tools to calculate the pertinent test result values has several advantages such as: 1. allowing high-fidelity solutions to complex nonlinear phenomena that would be impractical to express in written equation form, 2. eliminating errors associated with the interpretation and programing of analysis procedures from the text of test standards, 3. lessening the need for expertise in the areas of solid mechanics, fracture mechanics, numerical methods, and/or finite element modeling, to achieve sound results, 4. and providing one computer tool and/or one set of solutions for all users for a more "standardized" answer. In summary, this approach allows a non-expert with rudimentary training to get the best practical solution based on the latest understanding with minimum difficulty.Other existing ASTM standards that cover complicated phenomena use standard computer programs: 1. ASTM C1340/C1340M-10- Standard Practice for Estimation of Heat Gain or Loss Through Ceilings Under Attics Containing Radiant Barriers by Use of a Computer Program 2. ASTM F 2815 - Standard Practice for Chemical Permeation through Protective Clothing Materials: Testing Data Analysis by Use of a Computer Program 3. ASTM E2807 - Standard Specification for 3D Imaging Data Exchange, Version 1.0 The verification, validation, and round-robin processes required of a computer tool closely parallel the methods that are used to ensure the solution validity for equations included in test standard. The use of automated analysis tools allows the creation and practical implementation of advanced fracture mechanics test standards that capture the physics of a nonlinear fracture mechanics problem without adding undue burden or expense to the user. The presented approach forms a bridge between the equation-based fracture testing standards of today and the next generation of standards solving complex problems through analysis automation.

Allen, Phillip A.↗

NASA NTRS2011

Internal Versus External DSLs for Trace Analysis: Extended Abstract

This tutorial explores the design and implementation issues arising in the development of domain-specific languages for trace analysis. It introduces the audience to the general concepts underlying such special-purpose languages building upon the authors' own experiences in developing both external domain specific languages and systems, such as EAGLE, HAWK, RULER and LOGSCOPE, and the more recent internal domain-specific language and system TRACECONTRACT within the SCALA language.

domain specific language (DSL)↗

NASA NTRS2019

Agile Approach to Assuring Software for NASA's Orion Spacecraft

Agile software development is prevalent throughout the Government, and NASA is no exception. NASA's Orion spacecraft is being developed to return Astronauts to the moon in the next 5 years, and the role of software in achieving the ambitious mission objectives has expanded dramatically in the last few decades. This presentation is the story of how the Independent Verification and Validation team for Orion adapted to the Agile approach that the Orion Program was using to develop the flight software. Consider attending this session if you are working with software developers utilizing Agile development approaches, or are interested in learning about Agile and Lean principles that could help improve communication within your own team.

Smith, Justin↗

NASA NTRSDate not supplied

Embedding Differential Dynamic Logic in PVS

Runtime assurance is a control framework where a complex controller operates under the observation of a monitor. If the monitor detects the controller exhibiting undesirable behavior, control is passed off to a trusted controller until a desirable state is regained. The runtime assurance architecture provides a layer of assurance to the system being controlled, but special care must be taken that the resulting overall system, consisting of the monitors and controllers, is behaving as intended. This talk aims to formally model and reason about runtime assurance-equipped systems as hybrid programs- which are models that consist of both discrete and continuous components. Using the verification tool Plaidypvs, safety properties of some examples involving RTA architectures is shown.

Formal Verification↗

NASA NTRS1982

Design, analysis, and test verification of advanced encapsulation systems

Design sensitivities are established for the development of photovoltaic module criteria and the definition of needed research tasks. The program consists of three phases. In Phase I, analytical models were developed to perform optical, thermal, electrical, and structural analyses on candidate encapsulation systems. From these analyses several candidate systems will be selected for qualification testing during Phase II. Additionally, during Phase II, test specimens of various types will be constructed and tested to determine the validity of the analysis methodology developed in Phase I. In Phse III, a finalized optimum design based on knowledge gained in Phase I and II will be developed. All verification testing was completed during this period. Preliminary results and observations are discussed. Descriptions of the thermal, thermal structural, and structural deflection test setups are included.

Mardesich, N.↗

NASA NTRSDate not supplied

Actor-based Runtime Verification with MESA

This work presents a runtime verification approach implemented in the tool MESA (MEssage-based System Analysis) which allows for using concurrent monitors to check for properties specified in data parameterized temporal logic and state machines. The tool is implemented as an internal Scala DSL. We employ the actor programming model to implement MESA where monitors are captured by concurrent actors that communicate via messaging. The paper presents a case study in which MESA is used to effectively monitor a large number of flights from live US airspace data streams. We also perform an empirical study by conducting experiments using monitoring systems with different numbers of concurrent monitors and different layers of indexing on the data contained in events. The paper describes the experiments, evaluates the results, and discusses challenges faced during the study. The evaluation shows the value of combining concurrency with indexing to handle data rich events.

runtime verification↗

NASA NTRSDate not supplied

Operational Modal Analysis of the Artemis I Dynamic Rollout Test and Wet Dress Rehearsal

NASA has developed an expendable heavy lift launch vehicle capability, the Space Launch System (SLS), to support lunar and deep space exploration. The uncrewed Artemis I was the first flight of this new launch vehicle and tested critical systems for the upcoming crewed Artemis II flight to the moon. Accelerations were recorded at a multitude of locations on Artemis, the Mobile Launcher (ML), and the Crawler Transporter (CT)during the rollout of Artemis I from the Vehicle Assembly Building (VAB) to Launch Pad 39B March 2022 and is referred to as the Artemis I Dynamic Rollout Test (DRT). While Artemis I was at Launch Pad 39B, the Wet Dress Rehearsal (WDR) was performed to demonstrate launch readiness and acceleration measurements were also recorded. Finally, Artemis I rolled back from Launch Pad 39B to the VAB in April 2022, where acceleration measurements were also recorded and is referred to as the rollback portion of DRT. Because the forces during rollout and at the launch pad acting on Artemis I, the ML, and the CT are not directly measurable, Operational Modal Analysis (OMA) techniques, instead of traditional Experimental Modal Analysis (EMA) techniques, were used to identify modal characteristics. The OMA analysis of DRT and WDR directly builds upon the lessons learned from the OMA analysis of an earlier rollout of the ML from the VAB. DRT and WDR dynamic characteristics will be used to support SLS Integrated Modal Test finite element model correlation efforts and Exploration Ground System ML and CT finite element model verification and validation, which are part of the Building Block approach the Space Launch System program has implemented. The dynamic characteristics extracted from DRT as well as the rollout acceleration time histories themselves will be used in the development of generic rollout forcing functions that will provide refined estimates of the Artemis IV rollout forces, which will have the heavier and larger SLS Block 1B launch vehicle and Mobile Launcher 2 (ML-2). This paper briefly describes Artemis I, the ML, and the CT physical characteristics, DRT rollout/rollback and WDR data collection, the challenges in implementing OMA techniques due in part to the CT harmonics, and how these challenges were overcome to obtain the Artemis I DRT configuration and WDR configuration modal characteristics.

Apollo↗

NASA NTRS1997

A Categorization of Dynamic Analyzers

Program analysis techniques and tools are essential to the development process because of the support they provide in detecting errors and deficiencies at different phases of development. The types of information rendered through analysis includes the following: statistical measurements of code, type checks, dataflow analysis, consistency checks, test data,verification of code, and debugging information. Analyzers can be broken into two major categories: dynamic and static. Static analyzers examine programs with respect to syntax errors and structural properties., This includes gathering statistical information on program content, such as the number of lines of executable code, source lines. and cyclomatic complexity. In addition, static analyzers provide the ability to check for the consistency of programs with respect to variables. Dynamic analyzers in contrast are dependent on input and the execution of a program providing the ability to find errors that cannot be detected through the use of static analysis alone. Dynamic analysis provides information on the behavior of a program rather than on the syntax. Both types of analysis detect errors in a program, but dynamic analyzers accomplish this through run-time behavior. This paper focuses on the following broad classification of dynamic analyzers: 1) Metrics; 2) Models; and 3) Monitors. Metrics are those analyzers that provide measurement. The next category, models, captures those analyzers that present the state of the program to the user at specified points in time. The last category, monitors, checks specified code based on some criteria. The paper discusses each classification and the techniques that are included under them. In addition, the role of each technique in the software life cycle is discussed. Familiarization with the tools that measure, model and monitor programs provides a framework for understanding the program's dynamic behavior from different, perspectives through analysis of the input/output data.

Lujan, Michelle R.↗

NASA NTRSDate not supplied

Operational Modal Analysis of the Artemis I Dynamic Rollout Test and Wet Dress Rehearsal

NASA has developed an expendable heavy lift launch vehicle capability, the Space Launch System (SLS), to support lunar and deep space exploration. The uncrewed Artemis I was the first flight of this new launch vehicle and tested critical systems for the upcoming crewed Artemis II flight to the moon. Accelerations were recorded at a multitude of locations on Artemis, the Mobile Launcher (ML), and the Crawler Transporter (CT)during the rollout of Artemis I from the Vehicle Assembly Building (VAB) to Launch Pad 39B March 2022 and is referred to as the Artemis I Dynamic Rollout Test (DRT). While Artemis I was at Launch Pad 39B, the Wet Dress Rehearsal (WDR) was performed to demonstrate launch readiness and acceleration measurements were also recorded. Finally, Artemis I rolled back from Launch Pad 39B to the VAB in April 2022, where acceleration measurements were also recorded and is referred to as the rollback portion of DRT. Because the forces during rollout and at the launch pad acting on Artemis I, the ML, and the CT are not directly measurable, Operational Modal Analysis (OMA) techniques, instead of traditional Experimental Modal Analysis (EMA) techniques, were used to identify modal characteristics. The OMA analysis of DRT and WDR directly builds upon the lessons learned from the OMA analysis of an earlier rollout of the ML from the VAB. DRT and WDR dynamic characteristics will be used to support SLS Integrated Modal Test finite element model correlation efforts and Exploration Ground System ML and CT finite element model verification and validation, which are part of the Building Block approach the Space Launch System program has implemented. The dynamic characteristics extracted from DRT as well as the rollout acceleration time histories themselves will be used in the development of generic rollout forcing functions that will provide refined estimates of the Artemis IV rollout forces, which will have the heavier and larger SLS Block 1B launch vehicle and Mobile Launcher 2 (ML-2). This paper briefly describes Artemis I, the ML, and the CT physical characteristics, DRT rollout/rollback and WDR data collection, the challenges in implementing OMA techniques due in part to the CT harmonics, and how these challenges were overcome to obtain the Artemis I DRT configuration and WDR configuration modal characteristics.

Apollo↗

NASA NTRS2022

Towards an Implementation of Differential Dynamic Logic in PVS

This paper describes an ongoing effort to embed and verify differential dynamic logic (dL) in the Prototype Verification System (PVS). dL is a logic for specifying and formally reasoning about hybrid systems, which employ both continuous and discrete dynamics. There are several benefits of this effort. First, the embedding of dL in PVS offers an independent formal verification of the semantics and rules of dL. Second, the embedding is fully operational within PVS, giving PVS practitioners the ability to use dL in the formal specification and verification process. Third, the rich specification language, type system, and powerful interactive prover of PVS can be used on dL objects. In addition to the embedding and verification of dL, a custom extension for Visual Studio Code has been developed, so that a stylized dL syntax can be used to specify hybrid programs and their properties.

Differential Dynamic Logic↗