Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Test Tool”

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 127 records · Page 7
All sourcesNASA NTRSDOE OSTI
DOE OSTI2015

WE-AB-201-04: The Recommendations of MPPG #5 and Practical Implementation Strategies

Treatment planning systems (TPS) are a cornerstone of modern radiation therapy. Errors in their commissioning or use can have a devastating impact on many patients. To support safe and high quality care, medical physicists must conduct efficient and proper commissioning, good clinical integration, and ongoing quality assurance (QA) of the TPS. AAPM Task Group 53 and related publications have served as seminal benchmarks for TPS commissioning and QA over the past two decades. Over the same time, continuing innovations have made the TPS even more complex and more central to the clinical process. Medical goals are now expressed in terms of the dose and margins around organs and tissues that are delineated from multiple imaging modalities (CT, MR and PET); and even temporally resolved (i.e., 4D) imaging. This information is passed on to optimization algorithms to establish accelerator movements that are programmed directly for IMRT, VMAT and stereotactic treatments. These advances have made commissioning and QA of the TPS much more challenging. This education session reviews up-to-date experience and guidance on this subject; including the recently published AAPM Medical Physics Practice Guideline (MPPG) #5 “Commissioning and QA of Treatment Planning Dose Calculations: Megavoltage Photon and Electron Beams”. Treatment Planning System Commissioning and QA: Challenges and Opportunities (Greg Salomons) This session will provide some key background and review publications describing prominent incidents relating to TPS commissioning and QA. Traditional approaches have been hardware and feature oriented. They aim to establish a functional configuration and establish specifications for regular testing of features (like dose calculation) to assure stable operation and detect failures. With the advent of more complex systems, more patient-specific testing has also been adopted. A number of actual TPS defects will be presented along with heuristics for identifying similar defects in the future. Finally, the Gamma test has become a popular metric for reporting TPS Commissioning and QA results. It simplifies complex testing into a numerical index, but noisy data and casual application can make it misleading. A brief review of the issues around the use of the Gamma test will be presented. TPS commissioning and QA: A process orientation and application of control charts (Michael Sharpe) A framework for commissioning a treatment planning system will be presented, focusing on preparations, practical aspects of configuration, priorities, specifications, and establishing performance. The complexity of the modern TPS make modular testing of features inadequate, and modern QA tools can provide “too much information” about the performance of techniques like IMRT and VMAT. We have adopted a process orientation and quality tools, like control charts, for ongoing TPS QA and assessment of patient-specific tests. The trending nature of these tools reveals the overall performance of the TPS system, and quantifies the variations that arise from individual plans, discrete calculations, and experimentation based on discrete measurements. Examples demonstrating application of these tools to TPS QA will be presented. TPS commissioning and QA: Incorporating the entire planning process (Sasa Mutic) The TPS and its features do not perform in isolation. Instead, the features and modules are key components in a complex process that begins with CT Simulation and extends to treatment delivery, along with image guidance and verification. Most importantly, the TPS is used by people working in a multi-disciplinary environment. It is very difficult to predict the outcomes of human interactions with software. Therefore, an interdisciplinary approach to training, commissioning and QA will be presented, along with an approach to the physics chart check and end-to-end testing as a tool for TPS QA. The role of standardization and automation in QA will also be discussed. The recommendations of MPPG #5 and practical implementation strategies (Jennifer Smilowitz) The recently published recommendations from Task Group No. 244, Medical Physics Practice Guideline on Commissioning and QA of Treatment Planning Dose Calculations: Megavoltage Photon and Electron Beams will be presented. The recommendations focus on the validation of commissioning data and dose calculations. Tolerance values for non-IMRT beam configurations are summarized based on established criteria and data collected by the IROC. More stringent evaluation criteria for IMRT dose calculations are suggested to test the limitations of the TPS dose algorithms for advanced delivery conditions. The MPPG encourages users to create a suite of validation tests for dose calculation for various conditions for static photon beams, heterogeneities, IMRT/VMAT and electron beams. This test suite is intended to be used for subsequent testing, including TPS software upgrades. In the past, the recommendations of some reports have not been widely implemented due to practical limitations. Implementation strategies, tools and processes developed by multiple centers for efficient and “do-able” MPPG #5 testing will be presented, as well as a discussion on the overall validation experience. Learning Objectives: Identify some of the key documents relevant for TPS commissioning and QA Understand strategies for testing TPS software Gain a practical knowledge of the Gamma test criteria Increase familiarity with the process of commissioning a TPS Learn about the use of Control Charts for TPS QA Review the role of the TPS in the overall planning process Increase awareness of the link between TPS QA and chart checking Gain an increased appreciation for the importance of interdisciplinary communication Understand the new recommendations from MPPG #5 on TPS Dose Algorithm Commissioning and QC/QA Learn practical implementation processes and tools for MPPG #5 validation recommendations.

60 APPLIED LIFE SCIENCES↗
NASA NTRS1987

Development of a comprehensive software engineering environment

The generation of a set of tools for software lifecycle is a recurring theme in the software engineering literature. The development of such tools and their integration into a software development environment is a difficult task because of the magnitude (number of variables) and the complexity (combinatorics) of the software lifecycle process. An initial development of a global approach was initiated in 1982 as the Software Development Workbench (SDW). Continuing efforts focus on tool development, tool integration, human interfacing, data dictionaries, and testing algorithms. Current efforts are emphasizing natural language interfaces, expert system software development associates and distributed environments with Ada as the target language. The current implementation of the SDW is on a VAX-11/780. Other software development tools are being networked through engineering workstations.

Hartrum, Thomas C.↗
NASA NTRS1999

Landsat-7 Simulation and Testing Environments

A spacecraft Attitude Control and Determination Subsystem (ACDS) is heavily dependent upon simulation throughout its entire development, implementation and ground test cycle. Engineering simulation tools are typically developed to design and analyze control systems to validate the design and software simulation tools are required to qualify the flight software. However, the need for simulation does not end here. Operating the ACDS of a spacecraft on the ground requires the simulation of spacecraft dynamics, disturbance modeling and celestial body motion. Sensor data must also be simulated and substituted for actual sensor data on the ground so that the spacecraft will respond by sending commands to the actuators as they will on orbit. And finally, the simulators is the primary training tool and test-bed for the Flight Operations Team. In this paper various ACDS simulation, developed for or used by the Landsat 7 project will be described. The paper will include a description of each tool, its unique attributes, and its role in the overall development and testing of the ACDS. Finally, a section is included which discusses how the coordinated use of these simulation tools can maximize the probability of uncovering software, hardware and operations errors during the ground test process.

Holmes, E.↗
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↗
DOE OSTI2016

TU-AB-202-03: Prediction of PET Transfer Uncertainty by DIR Error Estimating Software, AUTODIRECT

Purpose: Deformable image registration (DIR) is a powerful tool, but DIR errors can adversely affect its clinical applications. To estimate voxel-specific DIR uncertainty, a software tool, called AUTODIRECT (automated DIR evaluation of confidence tool), has been developed and validated. This work tests the ability of this software to predict uncertainty for the transfer of standard uptake values (SUV) from positron-emission tomography (PET) with DIR. Methods: Virtual phantoms are used for this study. Each phantom has a planning computed tomography (CT) image and a diagnostic PET-CT image set. A deformation was digitally applied to the diagnostic CT to create the planning CT image and establish a known deformation between the images. One lung and three rectum patient datasets were employed to create the virtual phantoms. Both of these sites have difficult deformation scenarios associated with them, which can affect DIR accuracy (lung tissue sliding and changes in rectal filling). The virtual phantoms were created to simulate these scenarios by introducing discontinuities in the deformation field at the lung rectum border. The DIR algorithm from Plastimatch software was applied to these phantoms. The SUV mapping errors from the DIR were then compared to that predicted by AUTODIRECT. Results: The SUV error distributions closely followed the AUTODIRECT predicted error distribution for the 4 test cases. The minimum and maximum PET SUVs were produced from AUTODIRECT at 95% confidence interval before applying gradient-based SUV segmentation for each of these volumes. Notably, 93.5% of the target volume warped by the true deformation was included within the AUTODIRECT-predicted maximum SUV volume after the segmentation, while 78.9% of the target volume was within the target volume warped by Plastimatch. Conclusion: The AUTODIRECT framework is able to predict PET transfer uncertainty caused by DIR, which enables an understanding of the associated target volume uncertainty.

60 APPLIED LIFE SCIENCES↗
NASA NTRS2018

Rapid Model Import Tool (RMIT)

Our project is about developing a tool to implement conversion of 3D Computer Aided Design (CAD) models produced with software such as Delmia, 3DS Max, or Maya, into a size and format compatible with the Unity 3D environment. RMIT will be used to aid KSC engineering personnel in the design, development, testing, operations, and training on spacecraft, launch vehicles, facilities, and ground support equipment. For our project, we are using Blender, a free/open-source 3D graphics software, with the goal of developing, testing, and deploying a 3D CAD model converter tool. I worked on using Blender to import 3D CAD models exported from CATIA software into Collada file format. The Collada file format has file extension DAE. Importing the Collada DAE file as is into Blender, generates dots and dashes. In 3DS Max, there is an existing OpenCollada plugin and with that plugin, 3DS Max can import the DAE file successfully. But, Blender does not seem to have an OpenCollada plugin, so I worked on writing a new OpenCollada plugin for Blender. Since 3DS Max was able to display the image, I looked into comparing differences between the original DAE file and the DAE file exported from 3DS Max using the OpenCollada plugin. As Collada documents describing digital assets are XML files with file extension DAE, Collada files contains XML tags, making them easily modifiable. After some research, it appears that Blender does not like primitive 2D tags like tristrips and trifans. Changing those tags to polygons slightly improved the image, but the pieces were exploded. I found after further research comparing differences between the original file and the file exported from 3DS Max that the values inside the translate tags in the original file are scaled down by a factor of 25.4 in the exported file from 3DS Max, representing the millimeters to inches conversion (1 inch = 25.4 millimeters). After scaling down values inside all of the translate tags by 25.4, the exploded pieces stuck back in, but the image needed further improvement. I have been able to create a new plugin in Blender that takes the original DAE file, replaces the primitive 2D tags tristrips and trifans with polygons, scales down the values inside the translate tags by a factor of 25.4, and saves the changes into a temporary DAE file. After the temporary DAE file is imported into Blender, the temp file is then deleted, keeping the original DAE file intact. Starting with a DAE file that is exported using the NASA Enterprise Visualization Application (NEVA), a Collada exporter, from CATIA gives better results. NEVA is a Design Visualization product that is used for exporting 3D models from CATIA. With NEVA, the up axis is defined in the top-level node if navigation gravity is enabled. With that file, just replacing the primitive tags tristrips and trifans with polygons in yields a much improved image in Blender. As we identify more differences between the original DAE file and the DAE file exported from 3DS Max, this plugin can be improved further. Our goal is to have a model that is formatted and sized for import into Unity, and we are trying out different 3D programs to see which will work best.

Ayyangar, Arjun↗
DOE OSTI2020

Neurodata Extensions Catalog (NDX Catalog) v1.0.0

The Neurodata Extensions Catalog (NDX Catalog) is a novel web archive and associated software tools that enable users to easily create, search for, test, review, and install extensions to the Neurodata Without Borders (NWB) data standard for neurophysiology. The Catalog consists of several software repositories that can be found at https://github.com/nwb-extensions.

Tritt, Andrew↗
DOE OSTI2021

Community-Driven Methods for Open and Reproducible Software Tools for Analyzing Datasets from Atom Probe Microscopy

Atom probe tomography, and related methods, probe the three-dimensional architecture of a material. The software tools that microscopists use, and how these tools are connected into workflows, makes a substantial contribution to the accuracy and precision of such a material characterization experiment. Typically, we adapt methods from other communities like mathematics, data science, computational geometry, artificial intelligence, or scientific computing. We also realize that improving on research data management is a challenge when it comes to align with the FAIR data stewardship principles. Faced with this global challenge, we are convinced that collaborating is useful. Here, we report the results and challenges with an inter-laboratory call for developing test cases for several types of atom probe software tools. The results support why defining detailed recipes of software workflows and sharing these recipes is necessary and rewarding: Open source tools and (meta)data exchange can help to make our day-to-day data processing tasks become more efficient, the training of new users and knowledge transfer become easier, and assist us with automated quantification of uncertainties to gain access to substantiated results.

36 MATERIALS SCIENCE↗
DOE OSTI2015

Increasing the resilience and security of the United States' power infrastructure

The United States' power infrastructure is aging, underfunded, and vulnerable to cyber attack. Emerging smart grid technologies may take some of the burden off of existing systems and make the grid as a whole more efficient, reliable, and secure. The Pacific Northwest National Laboratory (PNNL) is funding research into several aspects of smart grid technology and grid security, creating a software simulation tool that will allow researchers to test power infrastructure control and distribution paradigms by utilizing different smart grid technologies to determine how the grid and these technologies react under different circumstances. Understanding how these systems behave in real-world conditions will lead to new ways to make our power infrastructure more resilient and secure. Demonstrating security in embedded systems is another research area PNNL is tackling. Many of the systems controlling the U.S. critical infrastructure, such as the power grid, lack integrated security and the aging networks protecting them are becoming easier to attack.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2015

Optimal Ground Source Heat Pump System Design

Despite the facts that GSHPs first gained popularity as early as the 1940’s and they can achieve 30 to 60 percent in energy savings and carbon emission reductions relative to conventional HVAC systems, the use of geothermal energy in the U.S. has been less than 1 percent of the total energy consumption. The key barriers preventing this technically-mature technology from reaching its full commercial potential have been its high installation cost and limited consumer knowledge and trust in GSHP systems to deliver the technology in a cost-effective manner in the market place. Led by ENVIRON, with support from University Hartford and University of Vermont, the team developed and tested a software-based a decision making tool (‘OptGSHP’) for the least-cost design of ground-source heat pump (‘GSHP’) systems. OptGSHP combines state of the art optimization algorithms with GSHP-specific HVAC and groundwater flow and heat transport simulation. The particular strength of OptGSHP is in integrating heat transport due to groundwater flow into the design, which most of the GSHP designs do not get credit for and therefore are overdesigned.

42 ENGINEERING↗
DOE OSTI2025

Vitis CI/CD & Containerization

Modern development flows that use tooling for automated building, testing, and deployment of software are becoming the norm for large scale software and hardware projects. These flows offer quite a few advantages that make them desirable, but when attempting to implement them for projects that use FPGAs, some complications can arise when attempting to integrate them with traditional FPGA toolchains and deployment workflows. In this poster, we present early our early efforts integrating the Vitis FPGA toolchain into a modern, Kuberentes and Github actions based CI/CD pipeline.

Hawks, Benjamin G. [Fermilab]↗
NASA NTRS1991

Optimal simultaneous control and structure design

Optimization-based control/structure design methodologies are presented for large space structures with the H2 cost function. The order and/or structure of the compensator can be chosen in advance. It is assumed that the compensator parameters can vary freely, but the structural parameters are constrained. In addition, the CSI model is presented. The problem is stated, and algorithms are developed in MATRIXx software. Finally, the tools that are developed are tested using an 11-beam truss example.

Harn, Ywh-Pyng↗
NASA NTRS2003

Aerostructures Test Wing

The Aerostructures Test Wing (ATW) was an apparatus used in a flight experiment during a program of research on aeroelastic instabilities. The ATW experiment was performed to study a specific instability known as flutter. Flutter is a destructive phenomenon caused by adverse coupling of structural dynamics and aerodynamics. The process of determining a flight envelope within which an aircraft will not experience flutter, known as flight flutter testing, is very dangerous and expensive because predictions of the instability are often unreliable. The ATW was a small-scale airplane wing that comprised an airfoil and boom (see upper part of Figure 1). For flight tests, the ATW was mounted on the F-15B/FTF-II testbed, which is a second-generation flight-test fixture described in Flight-Test Fixture for Aerodynamic Research (DRC- 95-27), NASA Tech Briefs, Vol. 19, No. 9, September 1995, page 84. The ATW was mounted horizontally on this fixture, and the entire assembly was attached to the undercarriage of the F-15B airplane (see lower part of Figure 1). The primary objective of the ATW project was to investigate traditional and advanced methodologies for predicting the onset of flutter. In particular, the ATW generated data that were used to evaluate a flutterometer. This particular flutterometer is an on-line computer program that uses method analysis to estimate worst-case flight conditions associated with flutter. This software was described in A Flutterometer Flight Test Tool NASA Tech Briefs, Vol. 23, No. 1, January 1999, page 52.

Lind, RIck↗
DOE OSTI2019

Diablo Test Suite: Code Coverage Analysis

An analysis of the Diablo source code covered by its Software Quality Assurance test suite was performed. Intel’s code coverage tool was used to determine the percentage of covered files, blocks, and functions. Excluding non-functional legacy files and single use developer-only files, the code coverage tool showed that 55% of blocks, the most applicable metric and closest to lines of code, are covered. For a large software code, 70-80% coverage is generally considered a reasonable target.A significant percentage of the uncovered code can be categorized as features that are not practical to test, duplicate/unused legacy code, and niche features only used by select individuals. Additionally, large segments of code dedicated to debugging and error handling are untested, as the test problems do not error out. The remaining untested code can be considered general purpose for use by the analyst/user community. These untested general purpose features are identified in the document and should be prioritized when new testing is added. Suggestions for additional test problems that would have the biggest impact on increasing the code coverage metric are presented. Finally, it is important to note that the single biggest way to increase the overall coverage metric is to delete old and unused code. While admittedly tedious to perform, future code development would also benefit markedly from this. Deleting unused code would likely push the coverage metric north of 60%, which is not too far off the 70-80% target. Overall, the current test suite covers the majority of commonly used features in Diablo, but there remains significant room for improvement. These areas for improvement have been identified.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

Software Verification Toolkit (SVT): Survey on Available Software Verification Tools and Future Direction

Writing software is difficult. However, writing complex, well tested and designed, and functionally correct software is incredibly difficult. An entire field of study is devoted to the validation and verification of software to address this problem, and in this paper we analyze the landscape of currently available third party software. We have divided our analyses into three separate subsections with regards to software validation: formal methods, static analysis, and test generation. Formal verification is the most complex method in which to validate software correctness, but also the most thorough as it truly validates the mathematical validity of the source code. Static analysis generally is relegated to abstract syntax tree traversal techniques to find errors related to faulty software such as memory leaks or stack overflow issues. Automatic test generation is similar in implementation to static analysis, but pushes a bit further in verifying the boundedness of function inputs and outputs with regards to annotated or parsed criteria. The crux of this report is to analyze and describe the software tools that implement these techniques to validate and verify software. Pros and cons related to installation, utilization, and capabilities of the frameworks are described, and reproducible examples are provided with a focus on usability. The initial survey concluded that the most interesting tools of note are Z3, Isabelle/HOL, and TLA+ with regards to formal verification; and Infer, Frama-C, and SonarQube with regards to static analysis. With these tools in mind, a final conjecture is provided that describes future avenues of utilizing these tools for developing a verification framework to assist in validating existing software at Sandia National Laboratories.

97 MATHEMATICS AND COMPUTING↗
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 NTRS2005

Development of Advanced Verification and Validation Procedures and Tools for the Certification of Learning Systems in Aerospace Applications

Adaptive control technologies that incorporate learning algorithms have been proposed to enable automatic flight control and vehicle recovery, autonomous flight, and to maintain vehicle performance in the face of unknown, changing, or poorly defined operating environments. In order for adaptive control systems to be used in safety-critical aerospace applications, they must be proven to be highly safe and reliable. Rigorous methods for adaptive software verification and validation must be developed to ensure that control system software failures will not occur. Of central importance in this regard is the need to establish reliable methods that guarantee convergent learning, rapid convergence (learning) rate, and algorithm stability. This paper presents the major problems of adaptive control systems that use learning to improve performance. The paper then presents the major procedures and tools presently developed or currently being developed to enable the verification, validation, and ultimate certification of these adaptive control systems. These technologies include the application of automated program analysis methods, techniques to improve the learning process, analytical methods to verify stability, methods to automatically synthesize code, simulation and test methods, and tools to provide on-line software assurance.

Jacklin, Stephen↗