SEARCH · Engineering Papers

Results for “Software Requirements”

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.

SourceResearch connectionFrom yearThrough year

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

At least 1,423 records · Page 79

All sources NASA NTRS DOE OSTI

NASA NTRS2012

Software Analysis of New Space Gravity Data for Geophysics and Climate Research

Both the Gravity Recovery and Climate Experiment (GRACE) and Gravity field and steady-state Ocean Circulation Explorer (GOCE) satellites are returning rich data for the study of the solid earth, the oceans, and the climate. Current software analysis tools do not provide researchers with the ease and flexibility required to make full use of this data. We evaluate the capabilities and shortcomings of existing software tools including Mathematica, the GOCE User Toolbox, the ICGEM's (International Center for Global Earth Models) web server, and Tesseroids. Using existing tools as necessary, we design and implement software with the capability to produce gridded data and publication quality renderings from raw gravity data. The straight forward software interface marks an improvement over previously existing tools and makes new space gravity data more useful to researchers. Using the software we calculate Bouguer anomalies of the gravity tensor's vertical component in the Gulf of Mexico, Antarctica, and the 2010 Maule earthquake region. These maps identify promising areas of future research.

Gravity Recovery and Climate Experiment (GRACE)↗

NASA NTRS1990

GCS support/development system configuration document

The software programming environment used in the development of Guidance and Control Software (GCS) implementations used in a software error studies experiment conducted by the Research Triangle Institute (RTI) and the NASA-Langley is described. The Radio Technical Commission for Aeronautics RTCA/DO-178A guidelines are fulfilled, and requirements for document number 9 in which the hardware, software, and processes used to develop and maintain the software for the GCS project are described. The software programming environment for GCS largely consists of tools that are included in Digital Equipment Corporations software layered product library or are a part of the VAX/VMS baseline system.

Lowman, Douglas S.↗

NASA NTRS2014

VARED: Verification and Analysis of Requirements and Early Designs

Requirements are a part of every project life cycle; everything going forward in a project depends on them. Good requirements are hard to write, there are few useful tools to test, verify, or check them, and it is difficult to properly marry them to the subsequent design, especially if the requirements are written in natural language. In fact, the inconsistencies and errors in the requirements along with the difficulty in finding these errors contribute greatly to the cost of the testing and verification stage of flight software projects [1]. Large projects tend to have several thousand requirements written at various levels by different groups of people. The design process is distributed and a lack of widely accepted standards for requirements often results in a product that varies widely in style and quality. A simple way to improve this would be to standardize the design process using a set of tools and widely accepted requirements design constraints. The difficulty with this approach is finding the appropriate constraints and tools. Common complaints against the tools available include ease of use, functionality, and available features. Also, although preferable, it is rare that these tools are capable of testing the quality of the requirements.

Badger, Julia↗

NASA NTRS2016

Technical Reference Suite Addressing Challenges of Providing Assurance for Fault Management Architectural Design

Research into complexities of software systems Fault Management (FM) and how architectural design decisions affect safety, preservation of assets, and maintenance of desired system functionality has coalesced into a technical reference (TR) suite that advances the provision of safety and mission assurance. The NASA Independent Verification and Validation (IV&V) Program, with Software Assurance Research Program support, extracted FM architectures across the IV&V portfolio to evaluate robustness, assess visibility for validation and test, and define software assurance methods applied to the architectures and designs. This investigation spanned IV&V projects with seven different primary developers, a wide range of sizes and complexities, and encompassed Deep Space Robotic, Human Spaceflight, and Earth Orbiter mission FM architectures. The initiative continues with an expansion of the TR suite to include Launch Vehicles, adding the benefit of investigating differences intrinsic to model-based FM architectures and insight into complexities of FM within an Agile software development environment, in order to improve awareness of how nontraditional processes affect FM architectural design and system health management. The identification of particular FM architectures, visibility, and associated IV&V techniques provides a TR suite that enables greater assurance that critical software systems will adequately protect against faults and respond to adverse conditions. Additionally, the role FM has with regard to strengthened security requirements, with potential to advance overall asset protection of flight software systems, is being addressed with the development of an adverse conditions database encompassing flight software vulnerabilities. Capitalizing on the established framework, this TR suite provides assurance capability for a variety of FM architectures and varied development approaches. Research results are being disseminated across NASA, other agencies, and the software community. This paper discusses the findings and TR suite informing the FM domain in best practices for FM architectural design, visibility observations, and methods employed for IV&V and mission assurance.

Fitz, Rhonda↗

NASA NTRSDate not supplied

Assessing Engine Hot Fire Data for Human Spaceflight Applications

Development and certification of liquid engine systems for human spaceflight missions requires exhaustive analysis to meet the NASA’s requirements for engine health, reliability, and performance. The techniques used to assess requirement conformance and test-to-test engine health pose many unique challenges including the unusually large scale of data, complex component and system analysis, and rigorous engineering judgement standards. To address these challenges, NASA Marshall Space Flight Center’s Engine Systems branch has developed and maintained a robust software suite and operational processes that satisfy programmatic requirements levied on engines and the 7 Elements of Flight Rationale. Analysis at a systems level includes subsystem assessment of components such as turbomachinery and combustion devices as well as structural and fluid dynamics and transient and steady-state assessment at a systems level. Some of the most important tools to accomplish this analysis are automated script databases, creation of historical and statistical comparisons, and parameters calculated at the full data rate. These tools greatly simplify the crucial processes of anomaly investigation, limit monitoring, health assessment, and timely communication of key conclusions drawn from hot fire testing and flight data analysis.

Data Assessment↗

NASA NTRSDate not supplied

Assessing Engine Hot Fire Data for Human Spaceflight Applications

Data Assessment↗

NASA NTRS2014

Adapting the Reconfigurable SpaceCube Processing System for Multiple Mission Applications

This paper will detail the use of SpaceCube in multiple space flight applications including the Hubble Space Telescope Servicing Mission 4 (HST-SM4), an International Space Station (ISS) radiation test bed experiment, and the main avionics subsystem for two separate ISS attached payloads. Each mission has had varying degrees of data processing complexities, performance requirements, and external interfaces. We will show the methodology used to minimize the changes required to the physical hardware, FPGA designs, embedded software interfaces, and testing.This paper will summarize significant results as they apply to each mission application. In the HST-SM4 application we utilized the FPGA resources to accelerate portions of the image processing algorithms more than 25 times faster than a standard space processor in order to meet computational speed requirements. For the ISS radiation on-orbit demonstration, the main goal is to show that we can rely on the commercial FPGAs and processors in a space environment. We describe our FPGA and processor radiation mitigation strategies that have resulted in our eight PowerPCs being available and error free for more than 99.99 of the time over the period of four years. This positive data and proven reliability of the SpaceCube on ISS resulted in the Department of Defense (DoD) selecting SpaceCube, which is replacing an older and slower computer currently used on ISS, as the main avionics for two upcoming ISS experiment campaigns. This paper will show how we quickly reconfigured the SpaceCube system to meet the more stringent reliability requirements

SpaceCube↗

NASA NTRSDate not supplied

Assessing Hot Fire Data with WinPlot

Development and certification of liquid engine systems for human spaceflight missions requires exhaustive analysis to meet the NASA’s requirements for engine health, reliability, and performance. The techniques used to assess requirement conformance and test-to-test engine health and performance pose many unique challenges including the unusually large scale of data, complex component and system analysis, and rigorous engineering judgement standards. To address these challenges, NASA Marshall Space Flight Center’s Engine Systems branch has developed and maintained a robust software suite and operational processes that satisfy programmatic requirements levied on engines and the 7 Elements of Flight Rationale. Analysis at a systems level includes subsystem assessment of components such as turbomachinery and combustion devices as well as structural and fluid dynamics and transient and steady-state assessment at a systems level. Some of the most important tools to accomplish this analysis are automated script databases, creation of historical and statistical comparisons, and parameters calculated at the full data rate. These tools greatly simplify the crucial processes of anomaly investigation, limit monitoring, health assessment, and timely communication of key conclusions drawn from hot fire testing and flight data analysis.

J. Davis Hunter↗

NASA NTRS2009

Human-System Integration Scorecard Update to VB.Net

The purpose of this project was to create Human-System Integration (HSI) scorecard software, which could be utilized to validate that human factors have been considered early in hardware/system specifications and design. The HSI scorecard is partially based upon the revised Human Rating Requirements (HRR) intended for NASA's Constellation program. This software scorecard will allow for quick appraisal of HSI factors, by using visual aids to highlight low and rapidly changing scores. This project consisted of creating a user-friendly Visual Basic program that could be easily distributed and updated, to and by fellow colleagues. Updating the Microsoft Word version of the HSI scorecard to a computer application will allow for the addition of useful features, improved easy of use, and decreased completion time for user. One significant addition is the ability to create Microsoft Excel graphs automatically from scorecard data, to allow for clear presentation of problematic areas. The purpose of this paper is to describe the rational and benefits of creating the HSI scorecard software, the problems and goals of project, and future work that could be done.

Sanders, Blaze D.↗

NASA NTRS2006

Experiences using Visualization Techniques to Present Requirements, Risks to Them, and Options for Risk Mitigation

For several years we have been employing a risk-based decision process to guide development and application of advanced technologies, and for research and technology portfolio planning. The process is supported by custom software, in which visualization plays an important role. During requirements gathering, visualization is used to help scrutinize the status (completeness, extent) of the information. During decision making based on the gathered information, visualization is used to help decisionmakers understand the space of options and their consequences. In this paper we summarize the visualization capabilities that we have employed, indicating when and how they have proven useful.

requirements↗

DOE OSTI2024

SAM: A Modern System Code for Advanced Non-LWR Safety Analysis

The System Analysis Module (SAM), developed at Argonne National Laboratory and by collaborators at other organizations, is for advanced non–light water reactor safety analysis. SAM aims to provide fast-running, modest-fidelity, whole-plant transient analysis capabilities that are essential for fast-turnaround design scoping and engineering analyses of advanced reactor concepts. To facilitate code development, SAM utilizes the MOOSE object-oriented application framework, its underlying finite element library, and linear and nonlinear solvers to leverage modern advanced software environments and numerical methods. SAM aims to solve tightly coupled physical phenomena, including fission reaction, heat transfer, fluid dynamics, and thermal-mechanical responses in advanced reactor structures, systems, and components with high accuracy and efficiency. Finally, this paper gives an overview of the SAM code development, including goals and functional requirements, physical models, current capabilities, verification and validation, software quality assurance, and examples of simulations for advanced nuclear reactor applications.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

NASA NTRS1973

Design of Mariner 9 Science Sequences using Interactive Graphics Software

This paper discusses the analyst/computer system used to design the daily science sequences required to carry out the desired Mariner 9 science plan. The Mariner 9 computer environment, the development and capabilities of the science sequence design software, and the techniques followed in the daily mission operations are discussed. Included is a discussion of the overall mission operations organization and the individual components which played an essential role in the sequence design process. A summary of actual sequences processed, a discussion of problems encountered, and recommendations for future applications are given.

Freeman, J. E.↗

NASA NTRS1992

Software assurance standard

This standard specifies the software assurance program for the provider of software. It also delineates the assurance activities for the provider and the assurance data that are to be furnished by the provider to the acquirer. In any software development effort, the provider is the entity or individual that actually designs, develops, and implements the software product, while the acquirer is the entity or individual who specifies the requirements and accepts the resulting products. This standard specifies at a high level an overall software assurance program for software developed for and by NASA. Assurance includes the disciplines of quality assurance, quality engineering, verification and validation, nonconformance reporting and corrective action, safety assurance, and security assurance. The application of these disciplines during a software development life cycle is called software assurance. Subsequent lower-level standards will specify the specific processes within these disciplines.

Source record↗

NASA NTRS1981

The electric Orbiter

An electromechanical actuator (EMA) system is described and compared to the baseline hydraulic system for the Shuttle. Employment of the EMA depends on minimal changes in the avionics and software, no change in the vehicle configuration, and satisfaction of performance requirements. There are 13 actuators on the Shuttle, all subject to the standard four (redundant) command channels. The actuator control units, motor control units, mechanical actuators, and motors are discussed, and system and sizing requirements are outlined. The effects on the displays and controls, the environmental control system, electrical power and distribution, and software are mentioned, and projected to be minimal. It is noted that although the EMA total systems' costs have not been calculated, substantial weight, turnaround time, and power savings are available by use of EMA.

Swingle, W. L.↗

NASA NTRS2004

SCA Waveform Development for Space Telemetry

The NASA Glenn Research Center is investigating and developing suitable reconfigurable radio architectures for future NASA missions. This effort is examining software-based open-architectures for space based transceivers, as well as common hardware platform architectures. The Joint Tactical Radio System's (JTRS) Software Communications Architecture (SCA) is a candidate for the software approach, but may need modifications or adaptations for use in space. An in-house SCA compliant waveform development focuses on increasing understanding of software defined radio architectures and more specifically the JTRS SCA. Space requirements put a premium on size, mass, and power. This waveform development effort is key to evaluating tradeoffs with the SCA for space applications. Existing NASA telemetry links, as well as Space Exploration Initiative scenarios, are the basis for defining the waveform requirements. Modeling and simulations are being developed to determine signal processing requirements associated with a waveform and a mission-specific computational burden. Implementation of the waveform on a laboratory software defined radio platform is proceeding in an iterative fashion. Parallel top-down and bottom-up design approaches are employed.

Mortensen, Dale J.↗

NASA NTRS1998

Compositional Specification of Software Architecture

This paper describes our experience using parameterized algebraic specifications to model properties of software architectures. The goal is to model the decomposition of requirements independent of the style used to implement the architecture. We begin by providing an overview of the role of architecture specification in software development. We then describe how architecture specifications are build up from component and connector specifications and give an overview of insights gained from a case study used to validate the method.

Penix, John↗

DOE OSTI2021

Use of Receiver Operating Curve Analysis and Machine Learning With an Independent Dose Calculation System Reduces the Number of Physical Dose Measurements Required for Patient-Specific Quality Assurance

Our purpose was to assess the use of machine learning methods and Mobius 3D (M3D) dose calculation software to reduce the number of physical ion chamber (IC) dose measurements required for patient-specific quality assurance during corona virus disease 2019.

62 RADIOLOGY AND NUCLEAR MEDICINE↗

DOE OSTI2021

Towards performance portability in the Spark astrophysical magnetohydrodynamics solver in the Flash-X simulation framework

Simulations of core-collapse supernovae, and other astrophysical phenomena, are quintessential extreme-scale computing challenges. For core-collapse supernova simulations to be carried out by the ExaStar project under the Exascale Computing Project umbrella, a robust, efficient, and state-of-the-art magnetohydrodynamics solver is a critical requirement. In Flash-X, the primary software instrument for ExaStar, a new magnetohydrodynamics solver has been designed and implemented from the ground up to achieve accuracy and efficiency for simulations of complex astrophysical flows. This new solver, dubbed Spark, uses high-order spatial reconstruction, Runge-Kutta time integration, and an efficient cell-centered approach to satisfying the divergence-free condition for the magnetic fields. Spark was written to be optimized for data locality in cache hierarchy of CPUs. Since data locality optimizations for cache hierarchy are not directly compatible with those of accelerators, we have taken the approach of using program synthesis to avoid massive amounts of code replication that would be necessary if we were to maintain two different versions of the solver. Our program synthesis relies on a simple key-dictionary approach, implemented in python, that enables us to assemble the version of the solver suitable for the target hardware from code fragments identified by specific keys. In this work, we describe the data locality optimizations of the solver for CPUs and accelerators and the program synthesis tools that enable this portability. We also detail the parallel performance of Spark for both CPUs and accelerators.

97 MATHEMATICS AND COMPUTING↗