Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “automated verification”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 433 records · Page 24
All sourcesNASA NTRSDOE OSTI
DOE OSTI2026

Elevating SolTrace's Capabilities for the Next Generation of Concentrating Solar Analysis

SolTrace is an open-source Monte Carlo ray tracing software developed at NREL. SolTrace can characterize concentrating solar thermal (CST) collector optical performance and is CST technology agnostic. Shown in Fig. 1, SolTrace is a foundational tool in NREL's CST system and component modeling suite. SolTrace's generic surface elements can flexibly model novel collector and receiver designs to predict spatial and temporal flux distributions - critical to understand for CST component design, performance prediction, and system integration. Since its initial development, SolTrace has over 1,650 references on Google Scholar, over 9,800 downloads since 2017, and has served the CST research and development community as a benchmark of 3rd party verification. SolTrace provides users with many options for defining surface shape and boundaries. However, SolTrace provides limited documentation which can result in a steep learning curve for new users. Additionally, SolTrace lacks the computational performance required to evaluate optical performance of a CST system over the course of a year and/or iteratively over design parameters in a timely manner. To address this, we are working towards a new release of SolTrace that enables increased computational throughput by implementing ray tracing acceleration structures and enabling GPU parallelization. Additionally, we are working to improve SolTrace's usability, accessibility, and maintainability by (1) automating solar position time-dependent simulation processes, (2) creating general CST collector templates of grouped elements, (3) updating the user interface to better visualize model inputs and outputs, and (4) creating a user support network through forums, "how to" videos, and documentation.

14 SOLAR ENERGY↗
NASA NTRS1973

Proposal for hierarchical description of software systems

The programming of digital computers has developed into a new dimension full of diffculties, because the hardware of computers has become so powerful that more complex applications are entrusted to computers. The costs of software development, verification, and maintenance are outpacing those of the hardware and the trend is toward futher increase of sophistication of application of computers and consequently of sophistication of software. To obtain better visibility into software systems and to improve the structure of software systems for better tests, verification, and maintenance, a clear, but rigorous description and documentation of software is needed. The purpose of the report is to extend the present methods in order to obtain a documentation that better reflects the interplay between the various components and functions of a software system at different levels of detail without losing the precision in expression. This is done by the use of block diagrams, sequence diagrams, and cross-reference charts. In the appendices, examples from an actual large sofware system, i.e. the Marshall System for Aerospace Systems Simulation (MARSYAS), are presented. The proposed documentation structure is compatible to automation of updating significant portions of the documentation for better software change control.

Thauboth, H.↗
NASA NTRS2006

ESAS Deliverable PS 1.1.2.3: Customer Survey on Code Generations in Safety-Critical Applications

Automated code generators (ACG) are tools that convert a (higher-level) model of a software (sub-)system into executable code without the necessity for a developer to actually implement the code. Although both commercially supported and in-house tools have been used in many industrial applications, little data exists on how these tools are used in safety-critical domains (e.g., spacecraft, aircraft, automotive, nuclear). The aims of the survey, therefore, were threefold: 1) to determine if code generation is primarily used as a tool for prototyping, including design exploration and simulation, or for fiight/production code; 2) to determine the verification issues with code generators relating, in particular, to qualification and certification in safety-critical domains; and 3) to determine perceived gaps in functionality of existing tools.

Schumann, Johann↗
NASA NTRSDate not supplied

Space Shuttle Cargo Integration Coupled Loads Analysis Lessons Learned

When a system experiences a loading environment characterized by rapidly varying forces, such as a rocket launch, a transient analysis is used to analyze the response of the system. The most common transient analysis methodology is the Coupled Loads Analysis (CLA). CLAs are used by the automotive and aerospace industry to analyze cars, trucks, planes, helicopters, spacecraft, etc. The Space Shuttle program used the CLA methodology to assess the compatibility of the payload with the Orbiter and the flight environment. The Space Shuttle Verification Loads Analysis (VLA) was a standardized CLA process that started between ten and thirteen months prior to launch, and included several meetings as well as analysis by both the Space Shuttle Program and the payload developers to verify that the payloads were compatible with the flight loads environment and would not interact negatively with the vehicle. Over the course of the Space Shuttle Program, many improvements were made to the process, which reduced cycle time and improved manifest flexibility. There were several issues which were never fully addressed, but workarounds were developed to keep the process flowing. The lessons learned included automation of some processes and standardization of others, early assessments, improved documentation and better coordination with all stakeholders in the process. Lessons learned also included the limitations in the current process, and what to do to avoid the same issues in the future.

Erica E. Bruno↗
NASA NTRS1995

The CCD/Transit Instrument (CTI) data-analysis system

The automated software system for archiving, analyzing, and interrogating data from the CCD/Transit Instrument (CTI) is described. The CTI collects up to 450 Mbytes of image-data each clear night in the form of a narrow strip of sky observed in two colors. The large data-volumes and the scientific aims of the project make it imperative that the data are analyzed within the 24-hour period following the observations. To this end a fully automatic and self evaluating software system has been developed. The data are collected from the telescope in real-time and then transported to Tucson for analysis. Verification is performed by visual inspection of random subsets of the data and obvious cosmic rays are detected and removed before permanent archival is made to the optical disc. The analysis phase is performed by a pair of linked algorithms, one operating on the absolute pixel-values and the other on the spatial derivative of the data. In this way both isolated and merged images are reliably detected in a single pass. In order to isolate the latter algorithm from the effects of noise spikes a 3x3 Hanning filter is applied to the raw data before the analysis is run. The algorithms reduce the input pixel-data to a database of measured parameters for each image which has been found. A contrast filter is applied in order to assign a detection-probability to each image and then x-y calibration and intensity calibration are performed using known reference stars in the strip. These are added to as necessary by secondary standards boot-strapped from the CTI data itself. The final stages involve merging the new data into the CTI Master-list and History-list and the automatic comparison of each new detection with a set of pre-defined templates in parameter-space to find interesting objects such as supernovae, quasars and variable stars. Each stage of the processing from verification to interesting image selection is performed under a data-logging system which both controls the pipe-lining of data through the system and records key performance monitor parameters which are built into the software. Furthermore, the data from each stage are stored in databases to facilitate evaluation, and all stages offer the facility to enter keyword-indexed free-format text into the data-logging system. In this way a large measure of certification is built into the system to provide the necessary confidence in the end results.

Cawson, M. G. M.↗
NASA NTRS2008

Generating Customized Verifiers for Automatically Generated Code

Program verification using Hoare-style techniques requires many logical annotations. We have previously developed a generic annotation inference algorithm that weaves in all annotations required to certify safety properties for automatically generated code. It uses patterns to capture generator- and property-specific code idioms and property-specific meta-program fragments to construct the annotations. The algorithm is customized by specifying the code patterns and integrating them with the meta-program fragments for annotation construction. However, this is difficult since it involves tedious and error-prone low-level term manipulations. Here, we describe an annotation schema compiler that largely automates this customization task using generative techniques. It takes a collection of high-level declarative annotation schemas tailored towards a specific code generator and safety property, and generates all customized analysis functions and glue code required for interfacing with the generic algorithm core, thus effectively creating a customized annotation inference algorithm. The compiler raises the level of abstraction and simplifies schema development and maintenance. It also takes care of some more routine aspects of formulating patterns and schemas, in particular handling of irrelevant program fragments and irrelevant variance in the program structure, which reduces the size, complexity, and number of different patterns and annotation schemas that are required. The improvements described here make it easier and faster to customize the system to a new safety property or a new generator, and we demonstrate this by customizing it to certify frame safety of space flight navigation code that was automatically generated from Simulink models by MathWorks' Real-Time Workshop.

Denney, Ewen↗
NASA NTRSDate not supplied

Space Shuttle Cargo Integration Coupled Loads Analysis Lessons Learned

When a system experiences a loading environment characterized by rapidly varying forces, such as a rocket launch, a transient analysis is used to analyze the response of the system. The most common transient analysis methodology is the Coupled Loads Analysis(CLA). CLAs are used by the automotive and aerospace industry to analyze cars, trucks,planes, helicopters, spacecraft, etc. The Space Shuttle program used the CLA methodology to assess the compatibility of the payload with the Orbiter and the flight environment. The Space Shuttle Verification Loads Analysis (VLA) was a standardized CLA process that started between ten and thirteen months prior to launch, and included several meetings as well as analysis by both the Space Shuttle Program and the payload developers to verify that the payloads were compatible with the flight loads environment and would not interact negatively with the vehicle. Over the course of the Space Shuttle Program, many improvements were made to the process, which reduced cycle time and improved manifest flexibility. There were several issues which were never fully addressed, but work-arounds were developed to keep the process flowing. The lessons learned included automation of some processes and standardization of others, early assessments, improved documentation and better coordination with all stakeholders in the process. Lessons learned also included the limitations in the current process, and what to do to avoid the same issues.

ERICA E. BRUNO↗
NASA NTRSDate not supplied

Tradeoffs When Considering Deep Reinforcement Learning for Contingency Management in Advanced Air Mobility

Air transportation is undergoing a rapid evolution globally with the introduction of Advanced Air Mobility (AAM) and with it comes novel challenges and opportunities for transforming aviation. As AAM operations introduce increasing heterogeneity in vehicle capabilities and density, increased levels of automation are likely necessary to achieve operational safety and efficiency goals. This paper focuses on one example where increased automation has been suggested. Autonomous operations will need contingency management systems that can monitor evolving risk across a span of interrelated (or interdependent) hazards and, if necessary, execute appropriate control interventions via supervised or automated decision making. Accommodating this complex environment may require automated functions (autonomy) that apply artificial intelligence (AI) techniques that can adapt and respond to a quickly changing environment. This paper explores the use of Deep Reinforcement Learning (DRL) which has shown promising performance in complex and high-dimensional environments where the objective can be constructed as a sequential decision-making problem. An extension of a prior formulation of the contingency management problem as a Markov Decision Process (MDP) is presented and uses a DRL framework to train agents that mitigate hazards present in the simulation environment. A comparison of these learning-based agents and classical techniques is presented in terms of their performance, verification difficulties, and development process.

machine learningautonomous systems; flight simulat↗
NASA NTRSDate not supplied

Tradeoffs When Considering Deep Reinforcement Learning for Contingency Management in Advanced Air Mobility

Air transportation is undergoing a rapid evolution globally with the introduction of Advanced Air Mobility (AAM) and with it comes novel challenges and opportunities for transforming aviation. As AAM operations introduce increasing heterogeneity in vehicle capabilities and density, increased levels of automation are likely necessary to achieve operational safety and efficiency goals. This paper focuses on one example where increased automation has been suggested. Autonomous operations will need contingency management systems that can monitor evolving risk across a span of interrelated (or interdependent) hazards and, if necessary, execute appropriate control interventions via supervised or automated decision making. Accommodating this complex environment may require automated functions (autonomy) that apply artificial intelligence (AI) techniques that can adapt and respond to a quickly changing environment. This paper explores the use of Deep Reinforcement Learning (DRL) which has shown promising performance in complex and high-dimensional environments where the objective can be constructed as a sequential decision-making problem. An extension of a prior formulation of the contingency management problem as a Markov Decision Process (MDP) is presented and uses a DRL framework to train agents that mitigate hazards present in the simulation environment. A comparison of these learning-based agents and classical techniques is presented in terms of their performance, verification difficulties, and development process.

machine learning↗
NASA NTRS2014

Using AUTORAD for Cassini File Uplinks: Incorporating Automated Commanding into Mission Operations

As the Cassini spacecraft embarked on the Solstice Mission in October 2010, the flight operations team faced a significant challenge in planning and executing the continuing tour of the Saturnian system. Faced with budget cuts that reduced the science and engineering staff by over a third in size, new and streamlined processes had to be developed to allow the Cassini mission to maintain a high level of science data return with a lower amount of available resources while still minimizing the risk. Automation was deemed an important key in enabling mission operations with reduced workforce and the Cassini flight team has made this goal a priority for the Solstice Mission. The operations team learned about a utility called AUTORAD which would give the flight operations team the ability to program selected command files for radiation up to seven days in advance and help minimize the need for off-shift support that could deplete available staffing during the prime shift hours. This paper will describe how AUTORAD is being utilized by the Cassini flight operations team and the processes that were developed or modified to ensure that proper oversight and verification is maintained in the generation and execution of radiated command files.

Goo, Sherwin↗
DOE OSTI2022

DIVA/DeviceEditor (DIVA) v6.0.0

The DIVA software interfaces a process in which researchers design their DNA with a web-based graphical user interface (DeviceEditor), submit their designs to a central queue, and a few weeks later receive their sequence-verified clonal constructs. Each researcher independently designs the DNA to be constructed with a web-based BioCAD tool, and presses a button to submit their designs to a central queue. Researchers have web-based access to their DNA design queues, and can track the progress of their submitted designs as they progress from "evaluation", to "waiting for reagents", to "in progress", to "complete". Researchers access their completed constructs through the central DNA repository. Along the way, all DNA construction success/failure rates are captured in a central database. Once a design has been submitted to the queue, a small number of dedicated staff evaluate the design for feasibility and provide feedback to the responsible researcher if the design is either unreasonable (e.g., encompasses a combinatorial library of a billion constructs) or small design changes could significantly facilitate the downstream implementation process. The dedicated staff then use DNA assembly design automation software to optimize the DNA construction process for the design, leveraging existing parts from the DNA repository where possible and ordering synthetic DNA where necessary. Once all requisite process inputs are available, the design progresses from "waiting for reagents" to "in progress" in the design queue. Human-readable and machine-parseable DNA construction protocols output by the DNA assembly design automation software are then executed by the dedicated staff exploiting lab automation devices wherever possible. Since the all employed DNA construction methods are sequence-agnostic, standardized (utilize the same enzymatic master mixes and reaction conditions), completely independent DNA construction tasks can be aggregated into the same multi-well plates and pursued in parallel. The resulting sets of cloned constructs can then be screened by high-throughput next-gen sequencing platforms for sequence correctness. A combination of long read-length (e.g., PacBio) and paired-end read platforms (e.g., Illumina) would be exploited depending the particular task at hand (e.g., PacBio might be sufficient to screen a set of pooled constructs with significant gene divergence). Post sequence verification, designs for which at least one correct clone was identified will progress to a "complete" status, while designs for which no correct clones were identified will progress to a "failure" status. Depending on the failure mode (e.g., no transformants), and how many prior attempts/variations of assembly protocol have been already made for a given design, subsequent attempts may be made or the design can progress to a "permanent failure" state. All success and failure rate information will be captured during the process, including at which stage a given clonal construction procedure failed (e.g., no PCR product) and what the exact failure was (e.g. assembly piece 2 missing). This success/failure rate data can be leveraged to refine the DNA assembly design process.

Plahar, Hector↗
NASA NTRS2011

Draper Station Analysis Tool

Draper Station Analysis Tool (DSAT) is a computer program, built on commercially available software, for simulating and analyzing complex dynamic systems. Heretofore used in designing and verifying guidance, navigation, and control systems of the International Space Station, DSAT has a modular architecture that lends itself to modification for application to spacecraft or terrestrial systems. DSAT consists of user-interface, data-structures, simulation-generation, analysis, plotting, documentation, and help components. DSAT automates the construction of simulations and the process of analysis. DSAT provides a graphical user interface (GUI), plus a Web-enabled interface, similar to the GUI, that enables a remotely located user to gain access to the full capabilities of DSAT via the Internet and Webbrowser software. Data structures are used to define the GUI, the Web-enabled interface, simulations, and analyses. Three data structures define the type of analysis to be performed: closed-loop simulation, frequency response, and/or stability margins. DSAT can be executed on almost any workstation, desktop, or laptop computer. DSAT provides better than an order of magnitude improvement in cost, schedule, and risk assessment for simulation based design and verification of complex dynamic systems.

Bedrossian, Nazareth↗
NASA NTRS2015

Attitude Design for the LADEE Mission

The Lunar Atmosphere and Dust Environment Explorer (LADEE) satellite successfully completed its 148-day science investigation in a low-altitude, near-equatorial lunar orbit on April 18, 2014. The LADEE spacecraft was built, managed and operated by NASA's Ames Research Center (ARC). The Mission Operations Center (MOC) was located at Ames and was responsible for activity planning, command sequencing, trajectory and attitude design, orbit determination, and spacecraft operations. The Science Operations Center (SOC) was located at Goddard Space Flight Center and was responsible for science planning, data archiving and distribution. This paper details attitude design and operations support for the LADEE mission. LADEE's attitude design was shaped by a wide range of instrument pointing requirements that necessitated regular excursions from the baseline one revolution per orbit "Ram" attitude. Such attitude excursions were constrained by a number of flight rules levied to protect instruments from the Sun, avoid geometries that would result in simultaneous occlusion of LADEE's two star tracker heads, and maintain the spacecraft within its thermal and power operating limits. To satisfy LADEE's many attitude requirements and constraints, a set of rules and conventions was adopted to manage the complexity of this design challenge and facilitate the automation of ground software that generated pointing commands spanning multiple days of operations at a time. The resulting LADEE Flight Dynamics System (FDS) that was developed used Visual Basic scripts that generated instructions to AGI's Satellite Tool Kit (STK) in order to derive quaternion commands at regular intervals that satisfied LADEE's pointing requirements. These scripts relied heavily on the powerful "align and constrain" capability of STK's attitude module to construct LADEE's attitude profiles and the slews to get there. A description of the scripts and the attitude modeling they embodied is provided. One particular challenge analysts faced was in the design of LADEE maneuver attitudes. A flight rule requiring pre-maneuver verification of in-flight maneuver conditions by ground operators prior to burn execution resulted in the need to accommodate long periods in the maneuver attitude. This in turn complicated efforts to satisfy star tracker interference and communication constraints in lunar orbit. In response to this challenge, a graphical method was developed and used to survey candidate rotation angles about the thrust vector. This survey method is described and an example of its use on a particular LADEE maneuver is discussed. Finally, the software and methodology used to satisfy LADEE's attitude requirements are also discussed in the context of LADEE's overall activity planning effort. In particular, the way in which strategic schedules of instrument and engineering activities were translated into actual attitude profiles at the tactical level, then converted into precise quaternion commands to achieve those pointing goals is explained. In order to reduce the risk of time-consuming re-planning efforts, this process included the generation of long-term projections of constraint violation predictions for individual attitude profiles that could be used to establish keep-out time-frames for particular attitude profiles. The challenges experienced and overall efficacy of both the overall LADEE ground system and the attitude components of the Flight Dynamics System in meeting LADEE's varied pointing requirements are discussed.

LADEE↗
NASA NTRS1986

Development of a prototype automated on-orbit contact heat exchanger

An automated contact heat exchanger is being developed for use aboard the manned Space Station, serving as an interface heat exchanger between the pressurized module internal thermal buses and the central external thermal bus. The concept makes use of an array of flattened, thin-walled, flexible tubes that expand or contract to make or break the thermal connection as the internal pressure changes. Because of its simplicity, it permits on-orbit assembly by the remote manipulator system, thus eliminating the need for expensive EVA to make connections. A design methodology based on stress and thermal analyses has been developed and used to perform trade-offs between performance and cost, and to optimize design parameters. Simple verification tests have been performed to confirm the stress analysis model. Two conceptual variants of the contact heat exchanger are described, each designed for a 25 kW total heat load and a minimum uniform heat flux of 2.15 W/sq cm.

Lee, C. Y.↗
NASA NTRS2013

Certification-Based Process Analysis

Space mission architects are often challenged with knowing which investment in technology infusion will have the highest return. Certification-based analysis (CBA) gives architects and technologists a means to communicate the risks and advantages of infusing technologies at various points in a process. Various alternatives can be compared, and requirements based on supporting streamlining or automation can be derived and levied on candidate technologies. CBA is a technique for analyzing a process and identifying potential areas of improvement. The process and analysis products are used to communicate between technologists and architects. Process means any of the standard representations of a production flow; in this case, any individual steps leading to products, which feed into other steps, until the final product is produced at the end. This sort of process is common for space mission operations, where a set of goals is reduced eventually to a fully vetted command sequence to be sent to the spacecraft. Fully vetting a product is synonymous with certification. For some types of products, this is referred to as verification and validation, and for others it is referred to as checking. Fundamentally, certification is the step in the process where one insures that a product works as intended, and contains no flaws.

Knight, Russell L.↗
NASA NTRS1994

Weld analysis and control system

The invention is a Weld Analysis and Control System developed for active weld system control through real time weld data acquisition. Closed-loop control is based on analysis of weld system parameters and weld geometry. The system is adapted for use with automated welding apparatus having a weld controller which is capable of active electronic control of all aspects of a welding operation. Enhanced graphics and data displays are provided for post-weld analysis. The system provides parameter acquisition, including seam location which is acquired for active torch cross-seam positioning. Torch stand-off is also monitored for control. Weld bead and parent surface geometrical parameters are acquired as an indication of weld quality. These parameters include mismatch, peaking, undercut, underfill, crown height, weld width, puddle diameter, and other measurable information about the weld puddle regions, such as puddle symmetry, etc. These parameters provide a basis for active control as well as post-weld quality analysis and verification. Weld system parameters, such as voltage, current and wire feed rate, are also monitored and archived for correlation with quality parameters.

Kennedy, Larry Z.↗
NASA NTRS2015

Formal Foundations for Hierarchical Safety Cases

Safety cases are increasingly being required in many safety-critical domains to assure, using structured argumentation and evidence, that a system is acceptably safe. However, comprehensive system-wide safety arguments present appreciable challenges to develop, understand, evaluate, and manage, partly due to the volume of information that they aggregate, such as the results of hazard analysis, requirements analysis, testing, formal verification, and other engineering activities. Previously, we have proposed hierarchical safety cases, hicases, to aid the comprehension of safety case argument structures. In this paper, we build on a formal notion of safety case to formalise the use of hierarchy as a structuring technique, and show that hicases satisfy several desirable properties. Our aim is to provide a formal, theoretical foundation for safety cases. In particular, we believe that tools for high assurance systems should be granted similar assurance to the systems to which they are applied. To this end, we formally specify and prove the correctness of key operations for constructing and managing hicases, which gives the specification for implementing hicases in AdvoCATE, our toolset for safety case automation. We motivate and explain the theory with the help of a simple running example, extracted from a real safety case and developed using AdvoCATE.

Hierarchy↗
NASA NTRS2009

Generating Code Review Documentation for Auto-Generated Mission-Critical Software

Model-based design and automated code generation are increasingly used at NASA to produce actual flight code, particularly in the Guidance, Navigation, and Control domain. However, since code generators are typically not qualified, there is no guarantee that their output is correct, and consequently auto-generated code still needs to be fully tested and certified. We have thus developed AUTOCERT, a generator-independent plug-in that supports the certification of auto-generated code. AUTOCERT takes a set of mission safety requirements, and formally verifies that the autogenerated code satisfies these requirements. It generates a natural language report that explains why and how the code complies with the specified requirements. The report is hyper-linked to both the program and the verification conditions and thus provides a high-level structured argument containing tracing information for use in code reviews.

Denney, Ewen↗