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 109 records · Page 6

All sources NASA NTRS DOE OSTI

NASA NTRS1988

Expert system structures for fault detection in spaceborne power systems

This paper presents an architecture for an expert system structure suitable for use with power system fault detection algorithms. The system described is not for the purpose of reacting to faults which have occurred, but rather for the purpose of performing on-line diagnostics and parameter evaluation to determine potential or incipient fault conditions. The system is also designed to detect high impedance or arcing faults which cannot be detected by conventional protection devices. This system is part of an overall monitoring computer hierarchy which would provide a full evaluation of the status of the power system and react to both incipient and catastrophic faults. An approximate hardware structure is suggested and software requirements are discussed. Modifications to CLIPS software, to capitalize on features offered by expert systems, are presented. It is suggested that such a system would have significant advantages over existing protection philosophy.

Watson, Karan↗

NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, attitude control, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on previous missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the perceived benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗

NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, knowledge of attitude control, and attitude control hardware, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on other missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗

NASA NTRS1981

Design requirements for SRB production control system. Volume 3: Package evaluation, modification and hardware

The software package evaluation was designed to analyze commercially available, field-proven, production control or manufacturing resource planning management technology and software package. The analysis was conducted by comparing SRB production control software requirements and conceptual system design to software package capabilities. The methodology of evaluation and the findings at each stage of evaluation are described. Topics covered include: vendor listing; request for information (RFI) document; RFI response rate and quality; RFI evaluation process; and capabilities versus requirements.

Source record↗

NASA NTRS1991

Space shuttle entry terminal area energy management

A historical account of the development for Shuttle's Terminal Area Energy Management (TAEM) is presented. A derivation and explanation of logic and equations are provided as a supplement to the well documented guidance computation requirements contained within the official Functional Subsystem Software Requirements (FSSR) published by Rockwell for NASA. The FSSR contains the full set of equations and logic, whereas this document addresses just certain areas for amplification.

Moore, Thomas E.↗

DOE OSTI2023

Graph-based machine learning improves just-in-time defect prediction

The increasing complexity of today’s software requires the contribution of thousands of developers. This complex collaboration structure makes developers more likely to introduce defect-prone changes that lead to software faults. Determining when these defect-prone changes are introduced has proven challenging, and using traditional machine learning (ML) methods to make these determinations seems to have reached a plateau. In this work, we build contribution graphs consisting of developers and source files to capture the nuanced complexity of changes required to build software. By leveraging these contribution graphs, our research shows the potential of using graph-based ML to improve Just-In-Time (JIT) defect prediction. We hypothesize that features extracted from the contribution graphs may be better predictors of defect-prone changes than intrinsic features derived from software characteristics. We corroborate our hypothesis using graph-based ML for classifying edges that represent defect-prone changes. This new framing of the JIT defect prediction problem leads to remarkably better results. We test our approach on 14 open-source projects and show that our best model can predict whether or not a code change will lead to a defect with an F1 score as high as 77.55% and a Matthews correlation coefficient (MCC) as high as 53.16%. This represents a 152% higher F1 score and a 3% higher MCC over the state-of-the-art JIT defect prediction. We describe limitations, open challenges, and how this method can be used for operational JIT defect prediction.

59 BASIC BIOLOGICAL SCIENCES↗

NASA NTRS1972

Design and flight experience with a digital fly-by-wire control system using Apollo guidance system hardware on an F-8 aircraft.

This paper discusses the design and initial flight tests of the first digital fly-by-wire system to be flown in an aircraft. The system, which used components from the Apollo guidance system, was installed in an F-8 aircraft. A lunar module guidance computer is the central element in the three-axis, single-channel, multimode, digital, primary control system. An electrohydraulic triplex system providing unaugmented control of the F-8 aircraft is the only backup to the digital system. Emphasis is placed on the digital system in its role as a control augmentor, a logic processor, and a failure detector. A sampled-data design synthesis example is included to demonstrate the role of various analytical and simulation methods. The use of a digital system to implement conventional control laws was shown to be practical for flight. Logic functions coded as an integral part of the control laws were found to be advantageous. Verification of software required an extensive effort, but confidence in the software was achieved. Initial flight results showed highly successful system operation, although quantization of pilot's stick and trim were areas of minor concern from the piloting standpoint.

Deets, D. A.↗

NASA NTRS1990

Small Explorer project: Submillimeter Wave Astronomy Satellite (SWAS). Mission operations and data analysis plan

The Mission Operations and Data Analysis Plan is presented for the Submillimeter Wave Astronomy Satellite (SWAS) Project. It defines organizational responsibilities, discusses target selection and navigation, specifies instrument command and data requirements, defines data reduction and analysis hardware and software requirements, and discusses mission operations center staffing requirements.

Melnick, Gary J.↗

NASA NTRS2018

Strategic Center for Networking, Integration, and Communications Orbit Propagation Front-End Software Development

Orbit propagation is fundamental for space-based mission analysis, requiring software tools to predict the time-based positions and velocities of orbiting satellites. Many system analysts currently rely on commercial software, which is effective but expensive. NASA’s Space Communications and Navigation (SCaN) Strategic Center for Networking, Integration, and Communications (SCENIC) project intends to provide these analysis capabilities by using a combination of internal and open-source software, allowing for a greater flexibility while maintaining low costs. Several routines were created to take different forms of user input to translate input into the standard set of orbital elements to be utilized within the current SCENIC analysis capabilities. These inputs range from two-line elements (TLEs) and Cartesian vectors, to coordinate transformations and Walker Delta constellations. These routines will be integrated into the SCENIC user interface (UI) in order to provide greater customization and flexibility for orbit propagation and other dynamic-analysis capabilities.

Kuhl, Nick↗

NASA NTRS1987

A report on NASA software engineering and Ada training requirements

NASA's software engineering and Ada skill base are assessed and information that may result in new models for software engineering, Ada training plans, and curricula are provided. A quantitative assessment which reflects the requirements for software engineering and Ada training across NASA is provided. A recommended implementation plan including a suggested curriculum with associated duration per course and suggested means of delivery is also provided. The distinction between education and training is made. Although it was directed to focus on NASA's need for the latter, the key relationships to software engineering education are also identified. A rationale and strategy for implementing a life cycle education and training program are detailed in support of improved software engineering practices and the transition to Ada.

Legrand, Sue↗

NASA NTRS1976

Mission planning, mission analysis and software formulation. Level C requirements for the shuttle mission control center orbital guidance software

The formulation of Level C requirements for guidance software was reported. Requirements for a PEG supervisor which controls all input/output interfaces with other processors and determines which PEG mode is to be utilized were studied in detail. A description of the two guidance modes for which Level C requirements have been formulated was presented. Functions required for proper execution of the guidance software were defined. The requirements for a navigation function that is used in the prediction logic of PEG mode 4 were discussed. It is concluded that this function is extracted from the current navigation FSSR.

Langston, L. J.↗

NASA NTRS2006

Autonomy Software: V&V Challenges and Characteristics

The successful operation of unmanned air vehicles requires software with a high degree of autonomy. Only if high level functions can be carried out without human control and intervention, complex missions in a changing and potentially unknown environment can be carried out successfully. Autonomy software is highly mission and safety critical: failures, caused by flaws in the software cannot only jeopardize the mission, but could also endanger human life (e.g., a crash of an UAV in a densely populated area). Due to its large size, high complexity, and use of specialized algorithms (planner, constraint-solver, etc.), autonomy software poses specific challenges for its verification, validation, and certification. -- - we have carried out a survey among researchers aid scientists at NASA to study these issues. In this paper, we will present major results of this study, discussing the broad spectrum. of notions and characteristics of autonomy software and its challenges for design and development. A main focus of this survey was to evaluate verification and validation (V&V) issues and challenges, compared to the development of "traditional" safety-critical software. We will discuss important issues in V&V of autonomous software and advanced V&V tools which can help to mitigate software risks. Results of this survey will help to identify and understand safety concerns in autonomy software and will lead to improved strategies for mitigation of these risks.

Schumann, Johann↗

DOE OSTI2021

SAM Co-Development to Support Fluoride-salt-cooled High-temperature Reactor Design and Licensing (CRADA 2018-18177 Final Report)

This project aims to raise the SAM code's technical and commercial maturity level to enable the Kairos Power ("Kairos") to use SAM to support its KP-FHR design analysis and licensing application. Argonne National Laboratory ("Argonne") has actively developed and maintained SAM, a modern system-level analysis tool for advanced nonlight water reactors safety analysis. Kairos is currently actively pursuing development of an FHR design and associated technology, and consequently requires a pedigreed safety analysis tool. The purpose of this project is to increase the maturity of the SAM code for the modeling and simulation of the KP-FHR design, thus enabling its use in safety analyses that support licensing application. Argonne will primarily be responsible for software design, development, and testing; while Kairos will be responsible for software requirements, assessment of software capabilities, needs, gaps, and priorities, and development of proprietary models. The research and development activities for the joint SAM development project include: a series of identification and prioritization studies on design characteristics, event sequences, relevant phenomena, and software capabilities; SAM capability enhancements for specific KP-FHR systems and components; performing code verification and validations; integrating uncertainty quantification (UQ), model calibration, and sensitivity analysis (SA) techniques in safety analyses; and raising the software quality rigor level for commercial-grade applications.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

NASA NTRS1987

Flow visualization of CFD using graphics workstations

High performance graphics workstations are used to visualize the fluid flow dynamics obtained from supercomputer solutions of computational fluid dynamic programs. The visualizations can be done independently on the workstation or while the workstation is connected to the supercomputer in a distributed computing mode. In the distributed mode, the supercomputer interactively performs the computationally intensive graphics rendering tasks while the workstation performs the viewing tasks. A major advantage of the workstations is that the viewers can interactively change their viewing position while watching the dynamics of the flow fields. An overview of the computer hardware and software required to create these displays is presented. For complex scenes the workstation cannot create the displays fast enough for good motion analysis. For these cases, the animation sequences are recorded on video tape or 16 mm film a frame at a time and played back at the desired speed. The additional software and hardware required to create these video tapes or 16 mm movies are also described. Photographs illustrating current visualization techniques are discussed. Examples of the use of the workstations for flow visualization through animation are available on video tape.

Lasinski, Thomas↗

NASA NTRS1979

Spacelab interface development tests. Software description

The software requirements for the Spacelab Interface Development Tests are described. The software operates in two modes. The multiplexer-demultiplexer mode transmits operator-controlled information to the Spacelab. The pulse coded modulation (PCM) mode records and displays operator selected PCM data for visual analysis.

Akers, J. W.↗

NASA NTRS2000

Software Released by LEWICE 2.0 Ice Accretion Software Development Project

Computational icing simulation methods are making the transition from the realm of research to commonplace use in design and certification. As such, standards of software management, design, validation, and documentation must be adjusted to accommodate the increased expectations of the user community with respect to accuracy, reliability, capability, and usability. With this in mind, in collaboration with Glenn's Engineering Design and Analysis Division, the Icing Branch of the NASA Glenn Research Center at Lewis Field began a software improvement project focused on the two-dimensional ice accretion simulation tool LEWICE. This project is serving as an introduction to the concepts of software management and is intended to serve as a pilot project for future icing simulation code development. The LEWICE 2.0 Software Development Project consisted of two major elements: software management and software validation. The software management element consisted of identifying features of well-designed and well-managed software that are appropriate for an analytical prediction tool such as LEWICE and applying them to a revised version of the code. This element included tasks such as identification of software requirements, development and implementation of coding standards, and implementation of software revision control practices. With the application of these techniques, the LEWICE ice accretion code became a more stable and reliable software product. In addition, the lessons learned about software development and maintenance can be factored into future software projects at the outset. The software validation activity was an integral part of our effort to make LEWICE a more accurate and reliable analysis tool. Because of the efforts taken to extensively validate this software, LEWICE 2.0 is more robust than previous releases and can reproduce results accurately across several computing platforms. It also differs from previous versions in the extensive quantitative comparisons of its results with a data base of ice shapes that were generated in Glenn's Icing Research Tunnel. The results of the shape comparisons were analyzed to determine the range of meteorological conditions under which LEWICE 2.0 is within the repeatability found for ice shapes obtained from experiments. These comparisons show that the average variation of LEWICE 2.0 from experimental data is 7.2 percent, whereas the overall variability of the experimental data is 2.5 percent. The LEWICE 2.0 Software Development Project resulted in the release, at the recent Icing Branch LEWICE Workshop, of a more useful and robust analysis tool than was previously available to the icing community. The lessons learned from this project will be applied to the Icing Branch s future software development efforts.

Potapczuk, Mark G.↗

NASA NTRS1986

The testability of Ada programs

Software development for NASA's Space Station poses a significant problem; considered the most difficult by some. The difficulty is the magnitude and complexity of the required software. The concerns raised by consideration of the requirements for testing and checkout procedures for the Space Station software are addressed. In particular, it addresses the use of Ada in the development of widely distributed yet closely coordinated processing.

Auty, David↗

NASA NTRS1996

SEDSAT 1 Technologies

The original goals of this project were to support the development of SEDSAT 1 for a tethered launch in July of 1997. This specifically required: (1) Monitoring development progress against a comprehensive delivery plan; (2) Incremental development and release of CDS and SEASIS software; (3) Supporting the integration of version 1.0 SEASIS software that will allow minimal autonomous operation without a software reload. These algorithms would include image quality evaluation, attitude determination, and autonomous earth imaging; and (4) Developing software requirements and design for ground segment software, concentrating on command and data download capability; and interface to external development efforts for a more comprehensive software suite to be used after the initial mission. Because of an unfavorable space shuttle safety review of the SEDS-3 tether deployer, and cost and schedule problems in upgrading the deployer, the mission was changed to an independent launch of SEDSAT. The original plan was to do a tether-less deployment from the space shuttle. Since this would have resulted in an unacceptable orbital lifetime, the mission was changed again to a tethered launch from a Delta II in June 1998. As a result of Marshall Space Flight Center's redirection of the SEDS-3 mission away from a tether launch, the whole question of a tether endmass had to be reconsidered. The net result of these multiple changes was twofold. First, we completed work needed to define some aspects of ground software on SEDSAT 1 that would remain constant no matter the launch mode. Second, we developed a set of concepts for using SEDSAT 1 technology to support alternative endmass missions on SEDS-3. Both of these are included.

Maier, Mark W.↗