Engineering Papers⌕ Search

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.

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

At least 883 records · Page 49
All sourcesNASA NTRSDOE OSTI
NASA NTRS2003

Software Engineering Improvement Activities/Plan

bd Systems personnel accomplished the technical responsibilities for this reporting period, as planned. A close working relationship was maintained with personnel of the MSFC Avionics Department Software Group (ED14). Work accomplishments included development, evaluation, and enhancement of a software cost model, performing literature search and evaluation of software tools available for code analysis and requirements analysis, and participating in other relevant software engineering activities. Monthly reports were submitted. This support was provided to the Flight Software Group/ED 1 4 in accomplishing the software engineering improvement engineering activities of the Marshall Space Flight Center (MSFC) Software Engineering Improvement Plan.

Source record↗
NASA NTRSDate not supplied

Risk Reduction through Early Software Prototyping for the Mars Ascent Vehicle

Despite the critical nature flight software plays in the development of spacecraft, software development teams are often brought on to the project after initial requirements definition and design efforts have started, and well after the conceptual design phase has completed. The flight software development team for the Mars Ascent Vehicle has supported the project from project formulation and conceptual design into the formal design and development. This approach has allowed for the development of a robust software prototype that supported risk reduction in numerous areas for the project. Early software prototyping supported decision making in the areas of hardware selection and considerations, software architecture, and simulation requirements. The prototype software actively supported ongoing trade studies and analyses for the project and enable valuable collaboration across multiple subsystems as well as between MSFC and the Jet Propulsion Laboratory. This early development also allowed the team to leverage past projects’ lessons learned to make valuable process improvements.

Stefanie Justice↗
DOE OSTI2023

Uncovering I/O demands on HPC platforms: Peeking under the hood of Santos Dumont

High-Performance Computing (HPC) platforms are required to solve the most diverse large-scale scientific problems in various research areas, such as biology, chemistry, physics, and health sciences. Researchers use a multitude of scientific softwares, which have different requirements. These include input and output operations, which directly impact performance due to the existing difference in processing and data access speeds. Thus, supercomputers must efficiently handle mixed workload when storing data from the applications. Understanding the set of applications and their performance running in a supercomputer is paramount to understanding the storage system's usage, pinpointing possible bottlenecks, and guiding optimization techniques. This research proposes a methodology and visualization tool to evaluate a supercomputer's data storage infrastructure's performance, taking into account the diverse workload and demands of the system over a long period of operation. As a study case, we focus on the Santos Dumont supercomputer, identifying inefficient usage, problematic performance factors, and providing guidelines on how to tackle those issues.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2013

Distributed Engine Control Empirical/Analytical Verification Tools

NASA's vision for an intelligent engine will be realized with the development of a truly distributed control system featuring highly reliable, modular, and dependable components capable of both surviving the harsh engine operating environment and decentralized functionality. A set of control system verification tools was developed and applied to a C-MAPSS40K engine model, and metrics were established to assess the stability and performance of these control systems on the same platform. A software tool was developed that allows designers to assemble easily a distributed control system in software and immediately assess the overall impacts of the system on the target (simulated) platform, allowing control system designers to converge rapidly on acceptable architectures with consideration to all required hardware elements. The software developed in this program will be installed on a distributed hardware-in-the-loop (DHIL) simulation tool to assist NASA and the Distributed Engine Control Working Group (DECWG) in integrating DCS (distributed engine control systems) components onto existing and next-generation engines.The distributed engine control simulator blockset for MATLAB/Simulink and hardware simulator provides the capability to simulate virtual subcomponents, as well as swap actual subcomponents for hardware-in-the-loop (HIL) analysis. Subcomponents can be the communication network, smart sensor or actuator nodes, or a centralized control system. The distributed engine control blockset for MATLAB/Simulink is a software development tool. The software includes an engine simulation, a communication network simulation, control algorithms, and analysis algorithms set up in a modular environment for rapid simulation of different network architectures; the hardware consists of an embedded device running parts of the CMAPSS engine simulator and controlled through Simulink. The distributed engine control simulation, evaluation, and analysis technology provides unique capabilities to study the effects of a given change to the control system in the context of the distributed paradigm. The simulation tool can support treatment of all components within the control system, both virtual and real; these include communication data network, smart sensor and actuator nodes, centralized control system (FADEC full authority digital engine control), and the aircraft engine itself. The DECsim tool can allow simulation-based prototyping of control laws, control architectures, and decentralization strategies before hardware is integrated into the system. With the configuration specified, the simulator allows a variety of key factors to be systematically assessed. Such factors include control system performance, reliability, weight, and bandwidth utilization.

DeCastro, Jonathan↗
NASA NTRS1996

QFD Application to a Software - Intensive System Development Project

This paper describes the use of Quality Function Deployment (QFD), adapted to requirements engineering for a software-intensive system development project, and sysnthesizes the lessons learned from the application of QFD to the Network Control System (NCS) pre-project of the Deep Space Network.

QFD Quality Function Deployment NCS Network Contro↗
NASA NTRS2018

Next Gen One Portal Usability Evaluation

Each exercise device on the International Space Station (ISS) has a unique, customized software system interface with unique layouts / hierarchy, and operational principles that require significant crew training. Furthermore, the software programs are not adaptable and provide no real-time feedback or motivation to enhance the exercise experience and/or prevent injuries. Additionally, the graphical user interfaces (GUI) of these systems present information through multiple layers resulting in difficulty navigating to the desired screens and functions. These limitations of current exercise device GUI's lead to increased crew time spent on initiating, loading, performing exercises, logging data and exiting the system. To address these limitations a Next Generation One Portal (NextGen One Portal) Crew Countermeasure System (CMS) was developed, which utilizes the latest industry guidelines in GUI designs to provide an intuitive ease of use approach (i.e., 80% of the functionality gained within 5-10 minutes of initial use without/limited formal training required). This is accomplished by providing a consistent interface using common software to reduce crew training, increase efficiency & user satisfaction while also reducing development & maintenance costs. Results from the usability evaluations showed the NextGen One Portal UI having greater efficiency, learnability, memorability, usability and overall user experience than the current Advanced Resistive Exercise Device (ARED) UI used by astronauts on ISS. Specifically, the design of the One-Portal UI as an app interface similar to those found on the Apple and Google's App Store, assisted many of the participants in grasping the concepts of the interface with minimum training. Although the NextGen One-Portal UI was shown to be an overall better interface, observations by the test facilitators noted specific exercise tasks appeared to have a significant impact on the NextGen One-Portal UI efficiency. Future updates to the NextGen One Portal UI will address these inefficiencies.

Cross, E. V., III↗
NASA NTRS1992

In the soft-to-hard technical spectrum: Where is software engineering?

In the computer journals and tabloids, there have been a plethora of articles written about the software engineering field. But while advocates of the need for an engineering approach to software development, it is impressive how many authors have treated the subject of software engineering without adequately addressing the fundamentals of what engineering as a discipline consists of. A discussion is presented of the various related facets of this issue in a logical framework to advance the thesis that the software development process is necessarily an engineering process. The purpose is to examine more of the details of the issue of whether or not the design and development of software for digital computer processing systems should be both viewed and treated as a legitimate field of professional engineering. Also, the type of academic and professional level education programs that would be required to support a software engineering discipline is examined.

Leibfried, Theodore F.↗
DOE OSTI2021

AutoCCS: automated collision cross-section calculation software for ion mobility spectrometry–mass spectrometry

Abstract Motivation Ion mobility spectrometry (IMS) separations are increasingly used in conjunction with mass spectrometry (MS) for separation and characterization of ionized molecular species. Information obtained from IMS measurements includes the ion’s collision cross section (CCS), which reflects its size and structure and constitutes a descriptor for distinguishing similar species in mixtures that cannot be separated using conventional approaches. Incorporating CCS into MS-based workflows can improve the specificity and confidence of molecular identification. At present, there is no automated, open-source pipeline for determining CCS of analyte ions in both targeted and untargeted fashion, and intensive user-assisted processing with vendor software and manual evaluation is often required. Results We present AutoCCS, an open-source software to rapidly determine CCS values from IMS-MS measurements. We conducted various IMS experiments in different formats to demonstrate the flexibility of AutoCCS for automated CCS calculation: (i) stepped-field methods for drift tube-based IMS (DTIMS), (ii) single-field methods for DTIMS (supporting two calibration methods: a standard and a new enhanced method) and (iii) linear calibration for Bruker timsTOF and non-linear calibration methods for traveling wave based-IMS in Waters Synapt and Structures for Lossless Ion Manipulations. We demonstrated that AutoCCS offers an accurate and reproducible determination of CCS for both standard and unknown analyte ions in various IMS-MS platforms, IMS-field methods, ionization modes and collision gases, without requiring manual processing. Availability and implementation https://github.com/PNNL-Comp-Mass-Spec/AutoCCS. Supplementary information Supplementary data are available at Bioinformatics online. Demo datasets are publicly available at MassIVE (Dataset ID: MSV000085979).

47 OTHER INSTRUMENTATION↗
NASA NTRS2017

Upgrades to Common Data Acquisition System Software Development for NASA's Rocket Propulsion Test Facilities and Software Reuse

Approximately five years ago, the National Aeronautics and Space Administration (NASA) Stennis Space Center (SSC) resumed operation of its large rocket engine test facilities after thirty years of contractor control. During this period, contactors used their own proprietary Data Acquisition System (DAS) to record and process rocket propulsion test data. The transition from a contractor managed facility to a NASA managed facility posed a difficult challenge. In order to support the commercial space launch initiative, SSC needed to develop a software replacement for the contractor proprietary DAS. This replacement software would enable SSC to operate propulsion test facilities more cost effectively and to be more readily able to adapt software for reuse, while at the same time provide internal and external customers with reliable population test data. Therefore, SSC developed in-house, a non-proprietary software suite of applications to replace the previously used proprietary DAS. The requirements for the DAS suite included recording and processing propulsion test data. This capability eliminates the necessity for customers to provide a DAS or rely on a competitor's DAS. An additional benefit of owning the software suite included enabling the ability to add additional features and functionality at a lower cost. The Rocket Propulsion Test (RPT) Program Office reviewed consideration for funding this project with the caveat that development of the software included availability for use with minimal modifications to all SSC test facilities and RPT centers: Marshall Space Flight Center (MSFC), White Sands Test Facility (WSTF), and Glenn Research Center (GRC) Plum Brook Station. Based upon this guideline, SSC created the NASA Data Acquisition System (NDAS) software suite. The ability to use the software at multiple centers, even though each field center uses differing DAS hardware with different capabilities, drove a requirement that the software design be portable with minimal modifications to the software. Then, with software release requirements, evaluations, and approvals completed, the NDAS software suite could also become available to other government agencies, corporations, universities, and the general United States public.

Herbert, Phillip W., Sr.↗
NASA NTRSDate not supplied

Computational Heat Flux Analysis for HEATheR Electric Aircraft Wing Ice Protection Systems

Increased electrification of aircraft systems, a growing trend in the aircraft industry, affects subsystems that have historically been pneumatically driven by the engine. Optimized design of propulsion and power systems must account for the requirements of these subsystems. One such subsystem, the wing ice protection system, is the focus of this paper. A preliminary computational icing analysis has been conducted using the LEWICE and ANSYS FENSAP-ICE software to characterize the requirements of a thermal ice protection system for three More Electric Aircraft concepts. This paper summarizes the methodology, simulation execution, and icing conditions used for the analysis as well as discusses the results, observed trends, and impacts to system design. This initial analysis indicates that the computed heat requirements for the wing ice protection systems are not within the capabilities of known traditional systems. A discussion of potential methods for reducing the heat flow requirement by the ice protection system is included. Potential refinements to the analysis to improve the accuracy are also discussed.

Nic Heersema↗
NASA NTRS2011

Seven Processes that Enable NASA Software Engineering Technologies

This slide presentation reviews seven processes that NASA uses to ensure that software is developed, acquired and maintained as specified in the NPR 7150.2A requirement. The requirement is to ensure that all software be appraised for the Capability Maturity Model Integration (CMMI). The enumerated processes are: (7) Product Integration, (6) Configuration Management, (5) Verification, (4) Software Assurance, (3) Measurement and Analysis, (2) Requirements Management and (1) Planning & Monitoring. Each of these is described and the group(s) that are responsible is described.

Housch, Helen↗
DOE OSTI2025

Method of Test for Evaluating Building Performance Simulation Software

ANSI/ASHRAE Standard 140 Method of Test for Evaluating Building Performance Simulation Software specifies the method to test the core competency of building performance simulation (BPS) software, a broad class of software which includes building energy modeling (BEM) software. Standard 140 has been widely used by BEM software vendors to help diagnose and compare the results from the program with other modeling programs. The Standard is also referenced by codes, standards, government programs, and other incentive programs as a part of minimum requirements for qualifying BEM software. The explanatory information, summary tables and figures in this 140 User’s Manual (referred to as “this Manual”) are provided to help users in implementing various suites of tests specified in Standard 140-2023 (referred to in this manual as “Standard 140” or “the Standard”).

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1996

Conversion-Integration of MSFC Nonlinear Signal Diagnostic Analysis Algorithms for Realtime Execution of MSFC's MPP Prototype System

NASA's advanced propulsion system Small Scale Magnetic Disturbances/Advanced Technology Development (SSME/ATD) has been undergoing extensive flight certification and developmental testing, which involves large numbers of health monitoring measurements. To enhance engine safety and reliability, detailed analysis and evaluation of the measurement signals are mandatory to assess its dynamic characteristics and operational condition. Efficient and reliable signal detection techniques will reduce the risk of catastrophic system failures and expedite the evaluation of both flight and ground test data, and thereby reduce launch turn-around time. During the development of SSME, ASRI participated in the research and development of several advanced non- linear signal diagnostic methods for health monitoring and failure prediction in turbomachinery components. However, due to the intensive computational requirement associated with such advanced analysis tasks, current SSME dynamic data analysis and diagnostic evaluation is performed off-line following flight or ground test with a typical diagnostic turnaround time of one to two days. The objective of MSFC's MPP Prototype System is to eliminate such 'diagnostic lag time' by achieving signal processing and analysis in real-time. Such an on-line diagnostic system can provide sufficient lead time to initiate corrective action and also to enable efficient scheduling of inspection, maintenance and repair activities. The major objective of this project was to convert and implement a number of advanced nonlinear diagnostic DSP algorithms in a format consistent with that required for integration into the Vanderbilt Multigraph Architecture (MGA) Model Based Programming environment. This effort will allow the real-time execution of these algorithms using the MSFC MPP Prototype System. ASRI has completed the software conversion and integration of a sequence of nonlinear signal analysis techniques specified in the SOW for real-time execution on MSFC's MPP Prototype. This report documents and summarizes the results of the contract tasks; provides the complete computer source code; including all FORTRAN/C Utilities; and all other utilities/supporting software libraries that are required for operation.

Jong, Jen-Yi↗
NASA NTRS2008

A Testbed for Evaluating Lunar Habitat Autonomy Architectures

A lunar outpost will involve a habitat with an integrated set of hardware and software that will maintain a safe environment for human activities. There is a desire for a paradigm shift whereby crew will be the primary mission operators, not ground controllers. There will also be significant periods when the outpost is uncrewed. This will require that significant automation software be resident in the habitat to maintain all system functions and respond to faults. JSC is developing a testbed to allow for early testing and evaluation of different autonomy architectures. This will allow evaluation of different software configurations in order to: 1) understand different operational concepts; 2) assess the impact of failures and perturbations on the system; and 3) mitigate software and hardware integration risks. The testbed will provide an environment in which habitat hardware simulations can interact with autonomous control software. Faults can be injected into the simulations and different mission scenarios can be scripted. The testbed allows for logging, replaying and re-initializing mission scenarios. An initial testbed configuration has been developed by combining an existing life support simulation and an existing simulation of the space station power distribution system. Results from this initial configuration will be presented along with suggested requirements and designs for the incremental development of a more sophisticated lunar habitat testbed.

Lawler, Dennis G.↗
NASA NTRS1991

Expert system verification and validation study. Phase 2: Requirements Identification. Delivery 2: Current requirements applicability

The second phase of a task is described which has the ultimate purpose of ensuring that adequate Expert Systems (ESs) Verification and Validation (V and V) tools and techniques are available for Space Station Freedom Program Knowledge Based Systems development. The purpose of this phase is to recommend modifications to current software V and V requirements which will extend the applicability of the requirements to NASA ESs.

Source record↗
NASA NTRS1986

Towards a software profession

An increasing number of programmers have attempted to change their image. They have made it plain that they wish not only to be taken seriously, but they also wish to be regarded as professionals. Many programmers now wish to referred to as software engineers. If programmers wish to be considered professionals in every sense of the word, two obstacles must be overcome: the inability to think of software as a product, and the idea that little or no skill is required to create and handle software throughout its life cycle. The steps to be taken toward professionalization are outlined along with recommendations.

Berard, Edward V.↗
NASA NTRS1990

Space Station transportation node concepts and analysis

Accommodation of the new Human Exploration Initiative being developed by NASA requires Space Station Freedom to serve three major roles: first, as a facility for precursory technology development and life sciences research for both transportation systems and lunar/Mars outpost systems; second, as a transportation node capable of processing both lunar- and Mars-class transportation vehicles and their accompanying payloads. This processing includes all required initial vehicle assembly, mating, servicing, refurbishment, and repair. In addition, some amount of mission propellant may be stored and transferred on Freedom. Third, Freedom provides an ideal test bed for developing operational techniques that are applicable to the Human Exploration Initiative missions. The work performed under this task and presented in this briefing serves to define and prepare Space Station Freedom evolution in keeping with the mission needs stated above by: defining Freedom transportation node evolution configurations consistent with user requirements and program constraints; defining and incorporating baseline design accommodations (hardware 'scars' and software 'hooks') to satisfy evolution requirements; and identifying advanced technology that will enhance Freedom's capabilities and enables its evolution.

Cirillo, William↗
DOE OSTI2021

DUNE Software and Computing Challenges

The DUNE experiment will begin running in the late 2020's. The goals of the experiment include 1) studying neutrino oscillations using a beam of neutrinos from Fermilab in Illinois to the Sanford Underground Research Facility, 2) studying astrophysical neutrino sources and rare processes and 3) understanding the physics of neutrino interactions in matter. The DUNE Far Detector, consisting of four 17 kt LArTPC modules, will produce "events" rang-ing in size from 6 GBs to more than 100 TBs, posing unique challenges for DUNE software and computing. The data processing algorithms, particularly for raw data, drive the requirements for the future DUNE software framework documented here.

97 MATHEMATICS AND COMPUTING↗