Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software engineering software verification validation”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

A Survey of ISS and Visiting Vehicle Returned Surfaces for Environmental Characterization and Computer Model Development

The Orbital Debris Engineering Model (ORDEM) developed by the NASA Orbital Debris Program Office (ODPO) is a data-driven model — extensive radar, optical, laboratory, and in situ measurement data sets have been used to build the model since its earliest versions. A salient aspect of professional software development is the verification and validation (V&V) process. Verification answers the question “Is the model built correctly?” while validation addresses the question “Did we build the correct model?” Less extensive, reserved, or independent data sets serve the validation requirement. Due to the dynamic nature of the orbital debris environment, it is critical to use contemporaneous data sources that represent the current environment to support ORDEM development and validation. ORDEM has utilized in situ data collected from Space Shuttle and Hubble Space Telescope surface inspections, now over a decade old. This historical dataset is fundamental for providing baseline in situ measurement data for sizes between 10 to 300 microns, but new data sources are being evaluated using returned surfaces from or near the International Space Station (ISS). This paper reviews a general microscopic survey of ISS soft goods, the Pressurized Mating Adapter 2 (PMA-2) blanket, and a limited-scope feasibility study conducted on the Space Exploration Technologies Corporation (SpaceX) Dragon capsule’s Thermal Protection System (TPS) material. The PMA-2 blanket, exposed to the space environment between 09 July 2013 and 25 February 2015, is an approximately 3.7 m2-area blanket composed of a betacloth outer layer and multiple ballistic fabric inner layers. The SpaceX Cargo Dragon capsule regularly visited the ISS from 2012 through 2020 and potentially provides a timely and well-characterized source of data for modeling purposes. The capsule’s lateral surfaces use SpaceX Proprietary Ablative Material (SPAM) TPS material, a syntactic foam, for thermal management during all mission phases. Seven SPAM extracted samples have been analyzed to date. This paper will provide an overview of the characterization completed for impact features by size, depth, impactor diameter, and the impactor residues chemical analyses, allowing a differentiation between micrometeoroids and orbital debris and a categorization by mass density and density class. Impactor diameter is estimated using damage equations generated from ground-based hypervelocity impact testing. The orbital debris impactors are compared to the current ORDEM 3.2 model of the environment at ISS altitudes. We briefly discuss the meteoroid impactors, including constituents and mass densities, in the general context of current models.

Phillip Anz-meador↗
NASA NTRSDate not supplied

A Survey of ISS and Visiting Vehicle Returned Surfaces for Environmental Characterization and Computer Model Development

The Orbital Debris Engineering Model (ORDEM) developed by the NASA Orbital Debris Program Office (ODPO) is a data-driven model — extensive radar, optical, laboratory, and in situ measurement data sets have been used to build the model since its earliest versions. A salient aspect of professional software development is the verification and validation (V&V) process. Verification answers the question “Is the model built correctly?” while validation addresses the question “Did we build the correct model?” Less extensive, reserved, or independent data sets serve the validation requirement. Due to the dynamic nature of the orbital debris environment, it is critical to use contemporaneous data sources that represent the current environment to support ORDEM development and validation. ORDEM has utilized in situ data collected from Space Shuttle and Hubble Space Telescope surface inspections, now over a decade old. This historical dataset is fundamental for providing baseline in situ measurement data for sizes between 10 to 300 microns, but new data sources are being evaluated using returned surfaces from or near the International Space Station (ISS). This paper reviews a general microscopic survey of ISS soft goods, the Pressurized Mating Adapter 2 (PMA-2) blanket, and a limited-scope feasibility study conducted on the Space Exploration Technologies Corporation (SpaceX) Dragon capsule’s Thermal Protection System (TPS) material. The PMA-2 blanket, exposed to the space environment between 09 July 2013 and 25 February 2015, is an approximately 3.7 m2-area blanket composed of a betacloth outer layer and multiple ballistic fabric inner layers. The SpaceX Cargo Dragon capsule regularly visited the ISS from 2012 through 2020 and potentially provides a timely and well-characterized source of data for modeling purposes. The capsule’s lateral surfaces use SpaceX Proprietary Ablative Material (SPAM) TPS material, a syntactic foam, for thermal management during all mission phases. Seven SPAM extracted samples have been analyzed to date. This paper will provide an overview of the characterization completed for impact features by size, depth, impactor diameter, and the impactor residues chemical analyses, allowing a differentiation between micrometeoroids and orbital debris and a categorization by mass density and density class. Impactor diameter is estimated using damage equations generated from ground-based hypervelocity impact testing. The orbital debris impactors are compared to the current ORDEM 3.2 model of the environment at ISS altitudes. We briefly discuss the meteoroid impactors, including constituents and mass densities, in the general context of current models.

Phillip Anz-Meador↗
NASA NTRS1994

A measurement system for large, complex software programs

This paper describes measurement systems required to forecast, measure, and control activities for large, complex software development and support programs. Initial software cost and quality analysis provides the foundation for meaningful management decisions as a project evolves. In modeling the cost and quality of software systems, the relationship between the functionality, quality, cost, and schedule of the product must be considered. This explicit relationship is dictated by the criticality of the software being developed. This balance between cost and quality is a viable software engineering trade-off throughout the life cycle. Therefore, the ability to accurately estimate the cost and quality of software systems is essential to providing reliable software on time and within budget. Software cost models relate the product error rate to the percent of the project labor that is required for independent verification and validation. The criticality of the software determines which cost model is used to estimate the labor required to develop the software. Software quality models yield an expected error discovery rate based on the software size, criticality, software development environment, and the level of competence of the project and developers with respect to the processes being employed.

Rone, Kyle Y.↗
NASA NTRS1994

Formalizing procedures for operations automation, operator training and spacecraft autonomy

The generation and validation of operations procedures is a key task of mission preparation that is quite complex and costly. This has motivated the development of software applications providing support for procedures preparation. Several applications have been developed at MATRA MARCONI SPACE (MMS) over the last five years. They are presented in the first section of this paper. The main idea is that if procedures are represented in a formal language, they can be managed more easily with a computer tool and some automatic verifications can be performed. One difficulty is to define a formal language that is easy to use for operators and operations engineers. From the experience of the various procedures management tools developed in the last five years (including the POM, EOA, and CSS projects), MMS has derived OPSMAKER, a generic tool for procedure elaboration and validation. It has been applied to quite different types of missions, ranging from crew procedures (PREVISE system), ground control centers management procedures (PROCSU system), and - most relevant to the present paper - satellite operation procedures (PROCSAT developed for CNES, to support the preparation and verification of SPOT 4 operation procedures, and OPSAT for MMS telecom satellites operation procedures).

Lecouat, Francois↗
DOE OSTI2021

A software environment for effective reliability management for pulsed power design

The reliable design of magnetically insulated transmission lines (MITLs) for very high current pulsed power machines must be accomplished in the future by utilizing a variety of sophisticated modeling tools. The complexity of the models required is high and the number of sub-models and approximations large. The potential for significant analyst error using a single tool is large, with possible reliability issues associated with the plasma modeling tools themselves or the chosen approach by the analyst to solve a given problem. Here, we report on a software infrastructure design that provides a workable framework for building self-consistent models and constraining feedback to limit analyst error. The framework and associated tools aid the development of physical intuition, the development of increasingly sophisticated models, and the comparison of performance results. The work lays the computational foundation for designing state-of-the-art pulsed-power experiments. The design and useful features of this environment are described. We discuss the utility of the Git source code management system and a GitLab interface for use in project management that extends beyond software development tasks.

42 ENGINEERING↗
NASA NTRS1984

Control system testing

A three stage process of ground testing of the Space Telescope Pointing Control System is used for verification prior to on-orbit operation. First, development tests are conducted in a laboratory environment using flight/engineering model control sensor and actuators configured with an engineering model of the flight computer and data management system breadboards. These development tests validate the results of computer simulations predicting control system performance. Integration tests bring together flight system elements and software interfaced to a software simulation of vehicle dynamics to confirm closed loop performance. The final ground test phase, flight systems testing, is conducted on the fully assembled Space Telescope, verifies interfaces with the Fine Guidance Sensors and includes a thermal vacuum testing period. During the final test phase, the Point Control System is exercised with the dynamics simulator running in real time.

Whittler, W. H.↗
NASA NTRSDate not supplied

Artemis Status Tracker for Real-time Awareness

Providers of Verification evidence for the Space Launch System (SLS) Program include Element Offices (SPIE, Stages, Engines, Booster) as well as Disciplines (Vehicle Management / GN&C, Loads & Environments, Safety and Mission Assurance, Systems Engineering, Integrated Avionics Software). These Elements and Disciplines rely on myriad inputs for their compliance evidence, from NASA and contractors alike, spanning testing and analysis to inspection and validation of records such as drawings and reports.

Braxton Lovett↗
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the validation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aerospace Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and ascent. The GLASS framework utilizes the off-the-shelf Mathworks (R) Simscape (TM) Multibody (TM) toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparison demonstrates that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check-cases and verify the GLASS core framework dynamics and the implementation of the check case scenario models.

6-Dof↗
DOE OSTI2017

Modernization and optimization of a legacy open-source CFD code for high-performance computing architectures

Legacy codes remain a crucial element of today's simulation-based engineering ecosystem due to the extensive validation process and investment in such software. The rapid evolution of high-performance computing architectures necessitates the modernization of these codes. One approach to modernization is a complete overhaul of the code. However, this could require extensive investments, such as rewriting in modern languages, new data constructs, etc., which will necessitate systematic verification and validation to re-establish the credibility of the computational models. The current study advocates using a more incremental approach and is a culmination of several modernization efforts of the legacy code MFIX, which is an open-source computational fluid dynamics code that has evolved over several decades, widely used in multiphase flows and still being developed by the National Energy Technology Laboratory. Two different modernization approaches,‘bottom-up’ and ‘top-down’, are illustrated. Here, preliminary results show up to 8.5x improvement at the selected kernel level with the first approach, and up to 50% improvement in total simulated time with the latter were achieved for the demonstration cases and target HPC systems employed.

97 MATHEMATICS AND COMPUTING↗
NASA NTRSDate not supplied

Verification of the Generalized Aerospace Simulation in Simulink (R)

NASA uses six-degrees-of-freedom (6-DOF) simulations tools to design, test, develop Guidance Navigation and Control (GN&C) software, and certify vehicle performance prior to flight. Therefore, it is critical that the 6-DOF tools used for vehicle design and certification are validated. The focus of this work is the vali-dation of the NASA Marshall Space Flight Center 6-DOF “GeneraLized Aero-space Simulation in Simulink” (GLASS) framework tool. The GLASS tool framework is currently used to support NASA GN&C insight for the Human Landing System (HLS) project, simulating vehicle dynamics during lunar descent and as-cent. The GLASS framework utilizes the off-the-shelf Mathworks ® Simscape Multibody® toolbox to model vehicle multi-body dynamics. NASA’s Engineering and Safety Center (NESC) provides a set of 6-DOF simulation verification “check cases” that are available to any user needing to verify 6-DOF tools. The check cases contain seventeen atmospheric and twenty-six orbital test scenarios are provided to validate equations of motion, environmental models (e.g., atmosphere, gravitation, and geodesy) and tool propagators. This paper compares GLASS 6-DOF simulation results against the NESC check cases’ results via simulation-to-simulation comparisons. The comparisons demonstrate that GLASS simulation results are “in family” with the outputs of the applicable NASA NESC check cases and verifies the GLASS core framework dynamics and the correct implementation of the check case scenario models.

6-Dof↗
NASA NTRS2016

NASA Operational Simulator for Small Satellites: Tools for Software Based Validation and Verification of Small Satellites

The NASA Operational Simulator for Small Satellites (NOS3) is a suite of tools to aid in areas such as software development, integration test (IT), mission operations training, verification and validation (VV), and software systems check-out. NOS3 provides a software development environment, a multi-target build system, an operator interface-ground station, dynamics and environment simulations, and software-based hardware models. NOS3 enables the development of flight software (FSW) early in the project life cycle, when access to hardware is typically not available. For small satellites there are extensive lead times on many of the commercial-off-the-shelf (COTS) components as well as limited funding for engineering test units (ETU). Considering the difficulty of providing a hardware test-bed to each developer tester, hardware models are modeled based upon characteristic data or manufacturers data sheets for each individual component. The fidelity of each hardware models is such that FSW executes unaware that physical hardware is not present. This allows binaries to be compiled for both the simulation environment, and the flight computer, without changing the FSW source code. For hardware models that provide data dependent on the environment, such as a GPS receiver or magnetometer, an open-source tool from NASA GSFC (42 Spacecraft Simulation) is used to provide the necessary data. The underlying infrastructure used to transfer messages between FSW and the hardware models can also be used to monitor, intercept, and inject messages, which has proven to be beneficial for VV of larger missions such as James Webb Space Telescope (JWST). As hardware is procured, drivers can be added to the environment to enable hardware-in-the-loop (HWIL) testing. When strict time synchronization is not vital, any number of combinations of hardware components and software-based models can be tested. The open-source operator interface used in NOS3 is COSMOS from Ball Aerospace. For testing, plug-ins are implemented in COSMOS to control the NOS3 simulations, while the command and telemetry tools available in COSMOS are used to communicate with FSW. NOS3 is actively being used for FSW development and component testing of the Simulation-to-Flight 1 (STF-1) CubeSat. As NOS3 matures, hardware models have been added for common CubeSat components such as Novatel GPS receivers, ClydeSpace electrical power systems and batteries, ISISpace antenna systems, etc. In the future, NASA IVV plans to distribute NOS3 to other CubeSat developers and release the suite to the open-source community.

Verification↗
DOE OSTI2020

AGGREGATE: dAta-driven modelinG preservinG contRollable dEr for outaGe mAnagemenT and rEsiliency (Report for Task 14: Model Verification/Validation Test Plan (Deliverable D10))

This report summarizes the technical progress and validation plan for each of AGGREGATE project modules, and integrated modules. The overall validation plan can be divided into two major parts. Firstly, it provides offline validation results of each module using the IEEE-123 node distribution system with certain modifications to support individual module results verification. The offline validation plan tentatively validated the usability and practicability of developed AGGREGATE tools. Secondly, the realworld test system - Seattle City Light (SCL) test feeder for verifying each module and the integrated modules using GE advanced distribution management system (ADMS) software.

42 ENGINEERING↗
NASA NTRS2018

Propulsion Control Technology Development Needs to Address NASA Aeronautics Research Mission Goals for Thrusts 3a and 4

The Commercial Aero-Propulsion Control Working Group (CAPCWG), consisting of propulsion control technology leads from The Boeing Company, GE Aviation, Honeywell, Pratt & Whitney, Rolls-Royce, and NASA (National Aeronautics and Space Administration) Glenn Research Center, has been working together over the past year to identify propulsion control technology areas of common interest that we believe are critical to achieving the challenging NASA Aeronautics Research goals for Thrust 3a: Ultra-Efficient Commercial Vehicles - Subsonic Transports, and Thrust 4: Transition to Alternative Propulsion and Energy. This paper describes the various propulsion control technology development areas identified by CAPCWG as most critical for NASA to invest in. For Thrust 3a these are: i) Integrated On-Board Model Based Engine Control and Health Management; ii) Flexible and Modular Networked Control Hardware and Software Architecture; iii) Intelligent Air/Fuel Control for Low Emissions Combustion; and iv) Active Clearance Control. For Thrust 4a, the focus is on Hybrid Electric Propulsion (HEP) for single aisle commercial aircraft. The specific technology development areas include: i) Integrated Power and Propulsion System Dynamic Modeling for Control; ii) Control Architectures for HEP; iii) HEP Control Verification and Validation; and iv) Engine/Airplane Control Integration. For each of the technology areas, the discussion includes: problem to be solved and how it relates to NASA goals, and the challenges to be addressed in reducing risk.

Propulsion Control↗
NASA NTRS2003

An Overview of the Process for Pre-Launch Checkout and Transition Activities in Support of the International Space Station (ISS) Payload Operations Integration Center

The objective of this paper is to provide future ISS scientists and/or engineers with an overview of the coordination process for the preparation and implementation of the pre-launch checkout and transition activities as observed from the Marshall Control Flight Center (MSFC) Payload Operations Integration Center perspective. This includes 4 major phases: (1) Verification and validation of the new command and telemetry databases that are needed for new payload experiments and new onboard formats; (2) Integration testing of the new ground control software and hardware; (3) Final internal and external pre-launch checkouts with cadre and experiment teams; (4) Performance of the actual synchronized transition between MSFC, Johnson Space Center (JSC), and ISS onboard configuration to new onboard software, ground software, and databases.

Digesu, Sam↗
NASA NTRS1986

Software engineering environment tool set integration

Space Transportation System Division (STSD) Engineering has a program to promote excellence within the engineering function. This program resulted in a capital funded facility based on a VAX cluster called the Rockwell Operational Engineering System (ROSES). The second phase of a three phase plan to establish an integrated software engineering environment for ROSES is examined. It discusses briefly phase one which establishes the basic capability for a modern software development environment to include a tool set, training and standards. Phase two is a tool set integration. The tool set is primarily off-the-shelf tools acquired through vendors or government agencies (public domain). These tools were placed into categories of software development. These categories are: requirements, design, and construction support; verification and validation support; and software management support. The integration of the tool set is being performed through concept prototyping and development of tools specifically designed to support the life cycle and provide transition from one phase to the next.

Selfridge, William P.↗
NASA NTRS1995

Concurrent engineering research center

The projects undertaken by The Concurrent Engineering Research Center (CERC) at West Virginia University are reported and summarized. CERC's participation in the Department of Defense's Defense Advanced Research Project relating to technology needed to improve the product development process is described, particularly in the area of advanced weapon systems. The efforts committed to improving collaboration among the diverse and distributed health care providers are reported, along with the research activities for NASA in Independent Software Verification and Validation. CERC also takes part in the electronic respirator certification initiated by The National Institute for Occupational Safety and Health, as well as in the efforts to find a solution to the problem of producing environment-friendly end-products for product developers worldwide. The 3M Fiber Metal Matrix Composite Model Factory Program is discussed. CERC technologies, facilities,and personnel-related issues are described, along with its library and technical services and recent publications.

Callahan, John R.↗
NASA NTRS2014

Towards Test Driven Development for Computational Science with pFUnit

Developers working in Computational Science & Engineering (CSE)/High Performance Computing (HPC) must contend with constant change due to advances in computing technology and science. Test Driven Development (TDD) is a methodology that mitigates software development risks due to change at the cost of adding comprehensive and continuous testing to the development process. Testing frameworks tailored for CSE/HPC, like pFUnit, can lower the barriers to such testing, yet CSE software faces unique constraints foreign to the broader software engineering community. Effective testing of numerical software requires a comprehensive suite of oracles, i.e., use cases with known answers, as well as robust estimates for the unavoidable numerical errors associated with implementation with finite-precision arithmetic. At first glance these concerns often seem exceedingly challenging or even insurmountable for real-world scientific applications. However, we argue that this common perception is incorrect and driven by (1) a conflation between model validation and software verification and (2) the general tendency in the scientific community to develop relatively coarse-grained, large procedures that compound numerous algorithmic steps.We believe TDD can be applied routinely to numerical software if developers pursue fine-grained implementations that permit testing, neatly side-stepping concerns about needing nontrivial oracles as well as the accumulation of errors. We present an example of a successful, complex legacy CSE/HPC code whose development process shares some aspects with TDD, which we contrast with current and potential capabilities. A mix of our proposed methodology and framework support should enable everyday use of TDD by CSE-expert developers.

pFUnit↗
DOE OSTI2021

Impact of particle loading and phase coupling on gas–solid flow dynamics: A case study of a two-phase, gas–solid flow in an annular pipe

The present study is devoted to a two-phase, gas–solid flow in an annular pipe (hollow cylinder) at an elevated pressure of 15 bars and moderate Reynolds number of circa 6000. The influence of the particle loading, the interaction between the phases, and turbulence dispersion on the flow dynamics is systematically studied by means of computational fluid dynamics simulations, employing the Ansys FLUENT commercial package. The cases with a particle volumetric fraction of 1.2% are referred to as “high particle loading,” and those with 0.13% are denoted as “low particle loading.” The following cases are investigated: (1) pure gas flow; (2) low particle loading two-phase flow with one-way coupling and with turbulence dispersion; (3) low particle loading two-phase flow with two-way coupling but without turbulence dispersion; (4) low particle loading two-phase flow with two-way coupling and with turbulence dispersion; (5) high particle loading two-phase flow with one-way coupling and with turbulence dispersion; (6) high particle loading two-phase flow with two-way coupling but without turbulence dispersion; and (7) high particle loading two-phase flow with two-way coupling and with turbulence dispersion. Additionally, the boundary layer is found to grow without fluctuations of the turbulent kinetic energy (TKE) for cases 1, 2, and 5. For case 4, the TKE fluctuations have been identified, although they appear to be less substantial than those in cases 6 and 7. The authors attribute the semi-chaotic nature of the TKE fluctuations to the particle loading and two-way coupling. In addition, the onset and development of the flow instability have been observed at a random axial distance in cases 4, 6, and 7. Such instability is also attributed to the two-way coupling with turbulence dispersion in the flow. It is concluded that the particle loading, one-way, or two-way coupling between the phases, and the turbulence dispersion models significantly influence the development of the flow dynamics with the same inlet and boundary conditions. Consequently, it is not a trivial question, which result a user should trust. The present computational results inspire to perform verification as well as experimental validation of the simulations, so the simulation results can subsequently be used with confidence for design analysis.

42 ENGINEERING↗