Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “engineering software”

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 937 records · Page 52
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

Towards a State Based Control Architecture for Large Telescopes: Laying a Foundation at the VLT

Large telescopes are characterized by a high level of distribution of control-related tasks and will feature diverse data flow patterns and large ranges of sampling frequencies; there will often be no single, fixed server-client relationship between the control tasks. the architecture is also challenged by the task of integrating heterogeneous subsystems which will be delivered by multiple different contractors. Due to the high number of distributed components, the control system needs to effectively detect errors and faults, impede their propagation, and accurately mitigate them in the shortest time possible, enabling the service to be restored. The presented Data-Driven Architecture is based on a decentralized approach with an end-to-end integration of disparate, independently developed software components. These components employ a high-performance standards-based communication middle-ware infrastructure, based on the Data Distribution Service. A set of rules and principles, based on JPL's State Analysis method and architecture, are use to constrain component-to component interactions, where the Control System and System Under Control are clearly separated. State Analysis provide a model-based process for capturing system and software requirements and design, greatly reducing the gap between the requirements on software specified by systems engineers and the implementation by software engineers. The method and architecture has been field tested at the Very Large Telescope, where it has been integrated into an operational system.

European Extremely Large Telescope (E-ELT)↗
DOE OSTI2024

Zero Power Reactor Database (ZPRD) Development Plan

Past sodium-cooled fast reactors (SFR) were built with an active experimental program in place to support the design and development work. Most of the experimental facilities in the United States that were important for SFR design were shutdown in the 1980s and 1990s. Reactor licensing and construction requires any reactor design to be verified against existing reactor facilities or experimental measurements. With the absence of those experimental facilities, modern SFR projects must rely on historical measurements to demonstrate that the engineering modeling software and data being used for the new reactor design work are reliable. There has been a considerable push in the last 6 years by both DOE and commercial companies to obtain historical experimental measurements that are relevant for SFRs, in particular those with features that are important for the new reactor designs of interest. The zero power reactor experiments carried out at Argonne National Laboratory’s critical facilities (ZPR-3, ZPR-6, ZPR-9, and ZPPR) from the 1950s to the 1980s are some of the best reactor physics experiments on SFR technology that are available today. Of particular interest today are the ZPPR-15 measurements done at the ZPPR facility for the Integral Fast Reactor project in the 1980s as they are in line with most commercial and DOE interests today. In the past 10 years, the measurements done on ZPPR-15 have been processed into both Monte Carlo (MCNP) and deterministic models (MC2-3 and DIF3D) useable for validating the engineering modeling software for key parts of the SFR design work. To achieve this, a detailed model description must be created for the experiment and the experimental measurement that the engineering modeling software is to reproduce. Then, an assessment of the uncertainty on the measured quantity which considers all of the sources of uncertainty in defining the model must be obtained and documented. The models created for ZPPR-15 provide the best validation basis available today for neutronics modeling software. Reference 2 is a good resource to understand how these models were built and how the uncertainties on the measured quantities were derived. The intention of the Zero Power Reactor Database (ZPRD), hosted at frdb.ne.anl.gov, is to make available the experimental measurements and models that have been constructed to-date. Though ZPPR-15 measurements are the primary data requested for validation needs, other measurements on ZPPR, ZPR-6, and ZPR-9 in support of the Clinch River Breeder Reactor (CRBR) and Fast Test Reactor (FFTF) should also be considered important for future software validation needs. In this manuscript, the details of available measurements on ZPR-3, ZPR-6, ZPR-9, and ZPPR facilities are summarized, and a general organization of the web interface is displayed. Many of the documents associated with the measurements are export controlled information so access to the database will also have to be controlled.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS1991

Training, Quality Assurance Factors, and Tools Investigation: a Work Report and Suggestions on Software Quality Assurance

Previously, several research tasks have been conducted, some observations were obtained, and several possible suggestions have been contemplated involving software quality assurance engineering at NASA Johnson. These research tasks are briefly described. Also, a brief discussion is given on the role of software quality assurance in software engineering along with some observations and suggestions. A brief discussion on a training program for software quality assurance engineers is provided. A list of assurance factors as well as quality factors are also included. Finally, a process model which can be used for searching and collecting software quality assurance tools is presented.

Lee, Pen-Nan↗
NASA NTRS2016

Marshall Space Flight Center Ground Systems Development and Integration

Ground Systems Development and Integration performs a variety of tasks in support of the Mission Operations Laboratory (MOL) and other Center and Agency projects. These tasks include various systems engineering processes such as performing system requirements development, system architecture design, integration, verification and validation, software development, and sustaining engineering of mission operations systems that has evolved the Huntsville Operations Support Center (HOSC) into a leader in remote operations for current and future NASA space projects. The group is also responsible for developing and managing telemetry and command configuration and calibration databases. Personnel are responsible for maintaining and enhancing their disciplinary skills in the areas of project management, software engineering, software development, software process improvement, telecommunications, networking, and systems management. Domain expertise in the ground systems area is also maintained and includes detailed proficiency in the areas of real-time telemetry systems, command systems, voice, video, data networks, and mission planning systems.

Wade, Gina↗
NASA NTRS1994

Implementing Software Safety in the NASA Environment

Until recently, NASA did not consider allowing computers total control of flight systems. Human operators, via hardware, have constituted the ultimate safety control. In an attempt to reduce costs, NASA has come to rely more and more heavily on computers and software to control space missions. (For example. software is now planned to control most of the operational functions of the International Space Station.) Thus the need for systematic software safety programs has become crucial for mission success. Concurrent engineering principles dictate that safety should be designed into software up front, not tested into the software after the fact. 'Cost of Quality' studies have statistics and metrics to prove the value of building quality and safety into the development cycle. Unfortunately, most software engineers are not familiar with designing for safety, and most safety engineers are not software experts. Software written to specifications which have not been safety analyzed is a major source of computer related accidents. Safer software is achieved step by step throughout the system and software life cycle. It is a process that includes requirements definition, hazard analyses, formal software inspections, safety analyses, testing, and maintenance. The greatest emphasis is placed on clearly and completely defining system and software requirements, including safety and reliability requirements. Unfortunately, development and review of requirements are the weakest link in the process. While some of the more academic methods, e.g. mathematical models, may help bring about safer software, this paper proposes the use of currently approved software methodologies, and sound software and assurance practices to show how, to a large degree, safety can be designed into software from the start. NASA's approach today is to first conduct a preliminary system hazard analysis (PHA) during the concept and planning phase of a project. This determines the overall hazard potential of the system to be built. Shortly thereafter, as the system requirements are being defined, the second iteration of hazard analyses takes place, the systems hazard analysis (SHA). During the systems requirements phase, decisions are made as to what functions of the system will be the responsibility of software. This is the most critical time to affect the safety of the software. From this point, software safety analyses as well as software engineering practices are the main focus for assuring safe software. While many of the steps proposed in this paper seem like just sound engineering practices, they are the best technical and most cost effective means to assure safe software within a safe system.

Wetherholt, Martha S.↗
NASA NTRS1992

Myths and realities: Defining re-engineering for a large organization

This paper describes the background and results of three studies concerning software reverse engineering, re-engineering, and reuse (R3) hosted by the Internal Revenue Service in 1991 and 1992. The situation at the Internal Revenue--aging, piecemeal computer systems and outdated technology maintained by a large staff--is familiar to many institutions, especially among management information systems. The IRS is distinctive for the sheer magnitude and diversity of its problems; the country's tax records are processed using assembly language and COBOL and spread across tape and network DBMS files. How do we proceed with replacing legacy systems? The three software re-engineering studies looked at methods, CASE tool support, and performed a prototype project using re-engineering methods and tools. During the course of these projects, we discovered critical issues broader than the mechanical definitions of methods and tool technology.

Yin, Sandra↗
DOE OSTI2020

Optical follow-up of gravitational wave triggers with DECam during the first two LIGO/VIRGO observing runs

Gravitational wave (GW) events detectable by LIGO and Virgo have several possible progenitors, including black hole mergers, neutron star mergers, black hole–neutron star mergers, supernovae, and cosmic string cusps. A subset of GW events is expected to produce electromagnetic (EM) emission that, once detected, will provide complementary information about their astrophysical context. To that end, the LIGO–Virgo Collaboration (LVC) sends GW candidate alerts to the astronomical community so that searches for their EM counterparts can be pursued. The DESGW group, consisting of members of the Dark Energy Survey (DES), the LVC, and other members of the astronomical community, uses the Dark Energy Camera (DECam) to perform a search and discovery program for optical signatures of LVC GW events. DESGW aims to use a sample of GW events as standard sirens for cosmology. Due to the short decay timescale of the expected EM counterparts and the need to quickly eliminate survey areas with no counterpart candidates, it is critical to complete the initial analysis of each night’s images as quickly as possible. We discuss our search area determination, imaging pipeline, and candidate selection processes. We review results from the DESGW program during the first two LIGO–Virgo observing campaigns and introduce other science applications that our pipeline enables.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
DOE OSTI2020

FPDetect: Efficient Reasoning About Stencil Programs Using Selective Direct Evaluation

We present FPDetect, a low-overhead approach for detecting logical errors and soft errors affecting stencil computations without generating false positives. We develop an offline analysis that tightly estimates the number of floating-point bits preserved across stencil applications. This estimate rigorously bounds the values expected in the data space of the computation. Violations of this bound can be attributed with certainty to errors. FPDetect helps synthesize error detectors customized for user-specified levels of accuracy and coverage. FPDetect also enables overhead reduction techniques based on deploying these detectors coarsely in space and time. Experimental evaluations demonstrate the practicality of our approach.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

QASMBench: A Low-Level Quantum Benchmark Suite for NISQ Evaluation and Simulation

The rapid development of quantum computing (QC) in the NISQ era urgently demands a low-level benchmark suite and insightful evaluation metrics for characterizing the properties of prototype NISQ devices, the efficiency of QC programming compilers, schedulers and assemblers, and the capability of quantum system simulators in a classical computer. In this work, we fill this gap by proposing a low-level, easy-to-use benchmark suite called QASMBench based on the OpenQASM assembly representation. It consolidates commonly used quantum routines and kernels from a variety of domains including chemistry, simulation, linear algebra, searching, optimization, arithmetic, machine learning, fault tolerance, cryptography, and so on, trading-off between generality and usability. To analyze these kernels in terms of NISQ device execution, in addition to circuit width and depth, we propose four circuit metrics including gate density, retention lifespan, measurement density, and entanglement variance, to extract more insights about the execution efficiency, the susceptibility to NISQ error, and the potential gain from machine-specific optimizations. Applications in QASMBench can be launched and verified on several NISQ platforms, including IBM-Q, Rigetti, IonQ and Quantinuum. For evaluation, we measure the execution fidelity of a subset of QASMBench applications on 12 IBM-Q machines through density matrix state tomography, comprising 25K circuit evaluations. In addition we also compare the fidelity of executions among the IBM-Q machines, the IonQ QPU and the Rigetti Aspen M-1 system.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

Architecture-Preserving Provable Repair of Deep Neural Networks

Deep neural networks (DNNs) are becoming increasingly important components of software, and are considered the state-of-the-art solution for a number of problems, such as image recognition. However, DNNs are far from infallible, and incorrect behavior of DNNs can have disastrous real-world consequences. This paper addresses the problem of architecture-preserving V-polytope provable repair of DNNs. A V-polytope defines a convex bounded polytope using its vertex representation. V-polytope provable repair guarantees that the repaired DNN satisfies the given specification on the infinite set of points in the given V-polytope. An architecture-preserving repair only modifies the parameters of the DNN, without modifying its architecture. The repair has the flexibility to modify multiple layers of the DNN, and runs in polynomial time. It supports DNNs with activation functions that have some linear pieces, as well as fully-connected, convolutional, pooling and residual layers. To the best our knowledge, this is the first provable repair approach that has all of these features. We implement our approach in a tool called APRNN. Using MNIST, ImageNet, and ACAS Xu DNNs, we show that it has better efficiency, scalability, and generalization compared to PRDNN and REASSURE, prior provable repair methods that are not architecture preserving.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2014

NASA Wearable Technology CLUSTER 2013-2014 Report

Wearable technology has the potential to revolutionize the way humans interact with one another, with information, and with the electronic systems that surround them. This change can already be seen in the dramatic increase in the availability and use of wearable health and activity monitors. These devices continuously monitor the wearer using on-­‐body sensors and wireless communication. They provide feedback that can be used to improve physical health and performance. Smart watches and head mounted displays are also receiving a great deal of commercial attention, providing immediate access to information via graphical displays, as well as additional sensing features. For the purposes of the Wearable Technology CLUSTER, wearable technology is broadly defined as any electronic sensing, human interfaces, computing, or communication that is mounted on the body. Current commercially available wearable devices primarily house electronics in rigid packaging to provide protection from flexing, moisture, and other contaminants. NASA mentors are interested in this approach, but are also interested in direct integration of electronics into clothing to enable more comfortable systems. For human spaceflight, wearable technology holds a great deal of promise for significantly improving safety, efficiency, autonomy, and research capacity for the crew in space and support personnel on the ground. Specific capabilities of interest include: Continuous biomedical monitoring for research and detection of health problems. Environmental monitoring for individual exposure assessments and alarms. Activity monitoring for responsive robotics and environments. Multi-modal caution and warning using tactile, auditory, and visual alarms. Wireless, hands-free, on-demand voice communication. Mobile, on-demand access to space vehicle and robotic displays and controls. Many technical challenges must be overcome to realize these wearable technology applications. For example, to make a wearable device that is both functional and comfortable for long duration wear, developers must strive to reduce electronic mass and volume while also addressing constraints imposed by the body attachment method. Depending on the application, the device must be placed in a location that the user can see and reach, and that provides the appropriate access to air and the wearer's skin. Limited power is available from body-­‐worn batteries and heat must be managed to prevent discomfort. If the clothing is to be washed, there are additional durability and washability hurdles that traditional electronics are not designed to address. Finally, each specific capability has unique technical challenges that will likely require unique solutions. In addition to the technical challenges, development of wearable devices is made more difficult by the diversity of skills required and the historic lack of collaboration across domains. Wearable technology development requires expertise in textiles engineering, apparel design, software and computer engineering, electronic design and manufacturing, human factors engineering, and application-­‐specific fields such as acoustics, medical devices, and sensing. Knowledge from each of these domains must be integrated to create functional and comfortable devices. For this reason, the diversity of knowledge and experience represented in the Wearable Technology is critical to overcoming the fundamental challenges in the field.

Simon, Cory↗
NASA NTRS2015

Open Source Mission Control for Chrome

New technology presents the possibility to evolve mission control. WARP (Web Applications for Resource Prospector) a new open source toolset for mission visualization, brings mission control to the Chrome Web Browser. WARP integrates multiple data sources into a coherent visualization toolset from which users may assemble their own software, thus giving mission controllers more flexibility. This frees us to operate based on mission needs, rather than constraints enforced by software application boundaries.

software engineering↗
NASA NTRS2021

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗
DOE OSTI2024

Software Quality Assurance Plan ANSYS LSDYNA Version 2023R1

ANSYS Inc. develops and markets engineering simulation software and services used in the aerospace, automotive, manufacturing, electronics, biomedical, energy, defense, and many other industries. ANSYS is dedicated to engineering simulation and is the world’s leading software provider. ANSYS was founded in 1970 and is headquartered in Canonsburg, Pennsylvania. ANSYS provides an engineering analysis tool combining structural, thermal, computational fluid dynamics, acoustic and electromagnetic simulation capabilities. ANSYS LS-DYNA is the most used explicit simulation program capable of simulating the response of materials to short periods of severe loading. Its many elements, contact formulations, material models, and other controls can be used to simulate complex models with control over all the details of the problem. ANSYS LS-DYNA has a vast array of capabilities to simulate extreme deformation problems using its explicit solver. Engineers can tackle simulations involving material failure and look at how the failure progresses through a part or through a system. Models with large amounts of parts or surfaces interacting with each other are also easily handled, and the interactions and load passing between complex behaviors are modeled accurately. Using computers with higher numbers of CPU cores can drastically reduce solution times. In addition, many consulting firms and hundreds of universities use ANSYS for analysis, research, and educational purposes. ANSYS is recognized worldwide as one of the most widely used and capable programs of its type. ANSYS has successfully passed over 100 customer quality system audits against American Society of Mechanical Engineers (ASME) NQA-1 and 10 CFR Part 50, Appendix B, since the company was founded, over 60 of which have been since 1997. ANSYS has successfully passed over 100 International Organization for Standardization (ISO) 9001 assessments. ANSYS design analysis software is the first created within a quality system with ISO 9001 certification, which is the internationally accepted quality standard. Product development, testing, maintenance, and support processes also meet the US Nuclear Regulatory Commission’s (NRC’s) quality requirements, as they have for nearly four decades. ANSYS staff perform more than 60,000 software verification tests before releasing each new product. ASME NQA-1-2012 (Subpart 2.7 is specific to software) is the industry- and NRC-accepted approach (consensus standard) for meeting 10 CFR Part 50, Appendix B, requirements.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2021

Influence of Fuel Properties on Gasoline Direct Injection Particulate Matter Emissions Over First 200 s of World-Harmonized Light-Duty Test Procedure Using an Engine Dynamometer and Novel “Virtual Drivetrain” Software

Abstract The influence of fuel properties on particulate matter (PM) emissions from a catalytic gasoline particulate filter (GPF) equipped gasoline direct injection (GDI) engine was investigated using novel “virtual drivetrain” software and an engine mated to an engine dynamometer. The virtual drivetrain software was developed in labview to operate the engine on an engine dynamometer as if it were in a vehicle undergoing a driving cycle. The software uses a physics-based approach to determine vehicle acceleration and speed based on engine load and a programed “shift” schedule to control engine speed. The software uses a control algorithm to modulate engine load and braking to match a calculated vehicle speed with the prescribed speed trace of the driving cycle of choice. The first 200 s of the World-harmonized Light-duty Test Procedure (WLTP) driving cycle was tested using six different fuel formulations of varying volatility, aromaticity, and ethanol concentration. The first 200 s of the WLTP was chosen as the test condition because it is the most problematic section of the driving cycle for controlling PM emissions due to the cold start and cold drive off. It was found that there was a strong correlation between aromaticity of the fuel and the engine-out PM emissions, with the highest emitting fuel producing more than double the mass emissions of the low PM production fuel. However, the post-GPF PM emissions depended greatly on the soot loading state of the GPF. The fuel with the highest engine-out PM emissions produced comparable post-GPF emissions to the lowest PM producing fuel over the driving cycle when the GPF was loaded over three cycles with the respective fuels. These results demonstrate the importance of GPF loading state when aftertreatment systems are used for PM reduction. It also shows that GPF control may be more important than fuel properties, and that regulatory compliance for PM can be achieved with proper GPF control calibration irrespective of fuel type.

Energy & Fuels↗
NASA NTRS1986

Software maintenance in scientific and engineering environments: An introduction and guide

The purpose of software maintenance techniques is addressed. The aims of perfective, adaptive and corrective software maintenance are defined and discussed, especially in the NASA research environment. Areas requiring maintenance, and tools available for this, and suggestions for their use are made. Stress is placed on the organizational aspect of maintenance at both the individual and group level. Particular emphasis is placed on the use of various forms of documentation as the basis around which to organize. Finally, suggestions are given on how to proceed in the partial or complete absence of such documentation.

Wright, David↗
NASA NTRS1991

Software reengineering

Today's software systems generally use obsolete technology, are not integrated properly with other software systems, and are difficult and costly to maintain. The discipline of reverse engineering is becoming prominent as organizations try to move their systems up to more modern and maintainable technology in a cost effective manner. JSC created a significant set of tools to develop and maintain FORTRAN and C code during development of the Space Shuttle. This tool set forms the basis for an integrated environment to re-engineer existing code into modern software engineering structures which are then easier and less costly to maintain and which allow a fairly straightforward translation into other target languages. The environment will support these structures and practices even in areas where the language definition and compilers do not enforce good software engineering. The knowledge and data captured using the reverse engineering tools is passed to standard forward engineering tools to redesign or perform major upgrades to software systems in a much more cost effective manner than using older technologies. A beta vision of the environment was released in Mar. 1991. The commercial potential for such re-engineering tools is very great. CASE TRENDS magazine reported it to be the primary concern of over four hundred of the top MIS executives.

Fridge, Ernest M., III↗