Search NASA⌕ Search

SEARCH · Search NASA

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS2004

From Bridges and Rockets, Lessons for Software Systems

Although differences exist between building software systems and building physical structures such as bridges and rockets, enough similarities exist that software engineers can learn lessons from failures in traditional engineering disciplines. This paper draws lessons from two well-known failures the collapse of the Tacoma Narrows Bridge in 1940 and the destruction of the space shuttle Challenger in 1986 and applies these lessons to software system development. The following specific applications are made: (1) the verification and validation of a software system should not be based on a single method, or a single style of methods; (2) the tendency to embrace the latest fad should be overcome; and (3) the introduction of software control into safety-critical systems should be done cautiously.

Holloway, C. Michael↗
NASA NTRS2017

Automated Analysis of Stateflow Models

Stateflow is a widely used modeling framework for embedded and cyber physical systems where control software interacts with physical processes. In this work, we present a framework a fully automated safety verification technique for Stateflow models. Our approach is two-folded: (i) we faithfully compile Stateflow models into hierarchical state machines, and (ii) we use automated logic-based verification engine to decide the validity of safety properties. The starting point of our approach is a denotational semantics of State flow. We propose a compilation process using continuation-passing style (CPS) denotational semantics. Our compilation technique preserves the structural and modal behavior of the system. The overall approach is implemented as an open source toolbox that can be integrated into the existing Mathworks Simulink Stateflow modeling framework. We present preliminary experimental evaluations that illustrate the effectiveness of our approach in code generation and safety verification of industrial scale Stateflow models.

Stateflow↗
NASA NTRS2019

Medical System Concept of Operations for Mars Exploration Mission-11: Exploration Medical Capability (ExMC) Element - Human Research Program

NASA’s exploration missions to Mars will have durations of 2-3 years and will take humans farther away from Earth than ever before. This will result in a paradigm shift for mission planning, spacecraft design, human systems integration, and in-flight medical care. Constraints on real-time communication, resupply, and medical evacuation are major architectural drivers. These constraints require medical system development to be tightly integrated with mission and vehicle design to provide crew autonomy and enable mission success. This concept of operations provides a common vision of medical care for developing a medical system for Mars exploration missions. It documents an overview of the stakeholder needs and goals of a medical system and provides examples of the types of activities the system will be used for during the mission. Development of the concept of operations considers mission variables such as distance from Earth, duration of mission, time to definitive medical care, communication protocols between crewmembers and ground support, personnel capabilities and skill sets, medical hardware and software, and medical data management. The information provided in this document informs the ExMC Systems Engineering effort to define the functions to be provided by the medical system. In addition, this concept of operations will inform the subsequent systems engineering process of developing technical requirements, system architectures, interfaces, and verification and validation approaches for the medical system. This document supports the closure of ExMC Gap Med01: We do not have a concept of operations for medical care during exploration missions, corresponding to the ExMC-managed human system risk: Risk of Adverse Health Outcomes & Decrements in Performance due to Inflight Medical Conditions. This document is applicable to the ExMC Element Systems Engineering process and may be used for collaboration within the Human Research Program.

Urbina, Michelle↗
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↗
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↗
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↗
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↗
NASA NTRS2015

NASA Operational Simulator for Small Satellites (NOS3)

The Simulation-to-Flight 1 (STF-1) CubeSat mission aims to demonstrate how legacy simulation technologies may be adapted for flexible and effective use on missions using the CubeSat platform. These technologies, named NASA Operational Simulator (NOS), have demonstrated significant value on several missions such as James Webb Space Telescope, Global Precipitation Measurement, Juno, and Deep Space Climate Observatory in the areas of software development, mission operationstraining, verification and validation (VV), test procedure development and software systems check-out. STF-1 will demonstrate a highly portable simulation and test platform that allows seamless transition of mission development artifacts to flight products. This environment will decrease development time of future CubeSat missions by lessening the dependency on hardware resources. In addition, through a partnership between NASA GSFC, the West Virginia Space Grant Consortium and West Virginia University, the STF-1 CubeSat will hosts payloads for three secondary objectives that aim to advance engineering and physical-science research in the areas of navigation systems of small satellites, provide useful data for understanding magnetosphere-ionosphere coupling and space weather, and verify the performance and durability of III-V Nitride-based materials.

modeling simulation↗