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,009 records · Page 56

All sources NASA NTRS DOE OSTI

NASA NTRS2018

Considerations When Building Thermal Models that Require Conversion Between Formats

At times, it is inevitable to require conversion of thermal models from one software format to another. This most often occurs for missions with international partners where not all parties utilize the same software packages for thermal analysis. Mandating a single tool for all parties is one possible solution, but this approach can introduce problems if significant effort is required to overcome inexperience with the designated tool and may result in difficulty meeting analysis schedule requirements. Alternatively, allowing all parties to use their own familiar tools minimizes the impact to analysis schedules but does introduce the need to convert the models later to a common format for analysis at a higher level of assembly. External conversion tools and formats have been developed through the years to aid in this process, but have had limited success in fully converting models seamlessly. Having a basic familiarity with tool capabilities on both sides of the conversion process allows for models to be built in a manner to better facilitate conversion by avoiding features and capabilities which are unsupported by the destination tool or for which no workarounds exist. Also, the effort to convert a model is often neglected when developing the schedules for analysis at the higher assembly levels; delivery of models preconditioned for convertibility minimizes the schedule risk. This paper seeks to provide some guidance on modeling techniques to avoid when developing Geometrical Math Models (GMM) and Thermal Math Models (TMM) when conversion is required. The recommendations are based on GMM conversion experiences between TSS/ThermalDesktop/ESARAD and TMM conversions between SINDA-FLUINT/ESATAN.

Modeling↗

NASA NTRS2014

Dynamic Weather Routes Architecture Overview

Dynamic Weather Routes Architecture Overview, presents the high level software architecture of DWR, based on the CTAS software framework and the Direct-To automation tool. The document also covers external and internal data flows, required dataset, changes to the Direct-To software for DWR, collection of software statistics, and the code structure.

DWR↗

NASA NTRS1976

Central Data Processing System (CDPS) user's manual: Solar heating and cooling program

The software and data base management system required to assess the performance of solar heating and cooling systems installed at multiple sites is presented. The instrumentation data associated with these systems is collected, processed, and presented in a form which supported continuity of performance evaluation across all applications. The CDPS consisted of three major elements: communication interface computer, central data processing computer, and performance evaluation data base. Users of the performance data base were identified, and procedures for operation, and guidelines for software maintenance were outlined. The manual also defined the output capabilities of the CDPS in support of external users of the system.

Source record↗

NASA NTRS1988

NASA follow-on on the Fiji South Pacific Severe Storm Warning System Project (SPSSD/WS)

The follow-on agreement will implement needed systems enhancements of the satellite ground station installed under the previous SPSSD/WS project. These enhancements include the purchase and installation of an Uninterruptible Power Supply (UPS) and lightning protection unit, hardware modifications to provide system redundancy and increased data storage capacity, software modifications for the new Japanese GMS digital data, upgrades of the image processing software, and both hardware maintenance and tropical cyclone analysis training, and a non-renewable grant to provide emergency field repairs and replacement/spare parts. In March 1988, the UPS and lightning protection unit was installed at the Fiji Meteorological Service by NASA personnel. A tape recorder and demodulator was shipped to Fiji to record the new digital GMS data. Data tapes are not yet available from the Japanese Meteorological Service of the new digital format. This data is required to test the GMS digital software being developed for the Fiji SPSSD/WS facility.

Vermillion, C.↗

NASA NTRS2010

Range Safety for an Autonomous Flight Safety System

The Range Safety Algorithm software encapsulates the various constructs and algorithms required to accomplish Time Space Position Information (TSPI) data management from multiple tracking sources, autonomous mission mode detection and management, and flight-termination mission rule evaluation. The software evaluates various user-configurable rule sets that govern the qualification of TSPI data sources, provides a prelaunch autonomous hold-launch function, performs the flight-monitoring-and-termination functions, and performs end-of-mission safing

Lanzi, Raymond J.↗

NASA NTRS2019

Improving Security of Ground System Software

An estimated 84% of all security breaches are application-related, not firewall violations. To what extent is your organization focused on addressing security issues in its software? Software plays a critical role in mission success, and software similarly plays a role in mission security. However, software can introduce vulnerabilities to the system, such as use of a COTS product that has a backdoor, or a hole in the security of the system deliberately left in place by designers or maintainers. The motivations for such holes are not always sinister, but can provide a means for malicious intrusion into the mission. Students will learn an approach to securing ground software within the context of federal information systems. Federal requirements, coding standards, tool usage will be discussed as part of the solution to securing software.

Bailey, Brandon↗

NASA NTRS2010

Injecting Errors for Testing Built-In Test Software

Two algorithms have been conceived to enable automated, thorough testing of Built-in test (BIT) software. The first algorithm applies to BIT routines that define pass/fail criteria based on values of data read from such hardware devices as memories, input ports, or registers. This algorithm simulates effects of errors in a device under test by (1) intercepting data from the device and (2) performing AND operations between the data and the data mask specific to the device. This operation yields values not expected by the BIT routine. This algorithm entails very small, permanent instrumentation of the software under test (SUT) for performing the AND operations. The second algorithm applies to BIT programs that provide services to users application programs via commands or callable interfaces and requires a capability for test-driver software to read and write the memory used in execution of the SUT. This algorithm identifies all SUT code execution addresses where errors are to be injected, then temporarily replaces the code at those addresses with small test code sequences to inject latent severe errors, then determines whether, as desired, the SUT detects the errors and recovers

Gender, Thomas K.↗

NASA NTRS2001

Structures for the 3rd Generation Reusable Concept Vehicle

A major goal of NASA is to create an advance space transportation system that provides a safe, affordable highway through the air and into space. The long-term plans are to reduce the risk of crew loss to 1 in 1,000,000 missions and reduce the cost of Low-Earth Orbit by a factor of 100 from today's costs. A third generation reusable concept vehicle (RCV) was developed to assess technologies required to meet NASA's space access goals. The vehicle will launch from Cape Kennedy carrying a 25,000 lb. payload to the International Space Station (ISS). The system is an air breathing launch vehicle (ABLV) hypersonic lifting body with rockets and uses triple point hydrogen and liquid oxygen propellant. The focus of this paper is on the structural concepts and analysis methods used in developing the third generation reusable launch vehicle (RLV). Member sizes, concepts and material selections will be discussed as well as analysis methods used in optimizing the structure. Analysis based on the HyperSizer structural sizing software will be discussed. Design trades required to optimize structural weight will be presented.

Hrinda, Glenn A.↗

NASA NTRSDate not supplied

Feature-Guided Analysis of Neural Networks

Applying standard software engineering practices to neural networks is challenging due to the lack of high-level abstractions describing a neural network’s behavior. To address this challenge, we propose to extract high-level task-specific features from the neural network internal representation, based on monitoring the neural network activations.The extracted feature representations can serve as a link to high-level requirements and can be leveraged to enable fundamental software engineering activities, such as automated testing, debugging, requirements analysis, and formal verification, leading to better engineering of neural networks. Using two case studies, we present initial empirical evidence demonstrating the feasibility of our ideas.

Features↗

NASA NTRS1995

Architecture for Payload Planning System (PPS) Software Distribution

The complex and diverse nature of the pay load operations to be performed on the Space Station requires a robust and flexible planning approach, and the proper software tools which tools to support that approach. To date, the planning software for most manned operations in space has been utilized in a centralized planning environment. Centralized planning is characterized by the following: performed by a small team of people, performed at a single location, and performed using single-user planning systems. This approach, while valid for short duration flights, is not conducive to the long duration and highly distributed payload operations environment of the Space Station. The Payload Planning System (PPS) is being designed specifically to support the planning needs of the large number of geographically distributed users of the Space Station. This paper problem provides a general description of the distributed planning architecture that PPS must support and describes the concepts proposed for making PPS available to the Space Station payload user community.

Howell, Eric↗

NASA NTRS1988

A communication channel model of the software process

Beginning research into a noisy communication channel analogy of software development process productivity, in order to establish quantifiable behavior and theoretical bounds is discussed. The analogy leads to a fundamental mathematical relationship between human productivity and the amount of information supplied by the developers, the capacity of the human channel for processing and transmitting information, the software product yield (object size) the work effort, requirements efficiency, tool and process efficiency, and programming environment advantage. An upper bound to productivity is derived that shows that software reuse is the only means that can lead to unbounded productivity growth; practical considerations of size and cost of reusable components may reduce this to a finite bound.

Tausworthe, Robert C.↗

NASA NTRS2020

GN&C Sequencing for Orion Rendezvous, Proximity Operations, and Docking

As part of the Artemis program to return humans to the lunar surface, the National Aeronautics and Space Administration is planning to use the Orion Multi- Purpose Crew Vehicle to transport crew to a small orbital platform called Gate- way in cislunar space. To facilitate this activity, Orion is required to perform Rendezvous, Proximity Operations, and Docking (RPOD) with both the Gate- way and the launch vehicle upper stage. The Orion spacecraft uses sequencing in the form of Phases, Segments, Activities, and Modes (PSAM) to configure Guidance, Navigation, & Control (GN&C) software during each portion of the mission. Significant updates to Orion PSAM definitions are required for RPOD. This paper describes the process of defining these new sequencing elements, implementing them in prototype flight software, and testing them in an integrated simulation environment. First, requirements are specified to determine the nominal and off-nominal sequencing behavior necessary to complete the mission. These requirements also specify which software functions should be fully autonomous and which functions require manual interactions from crew or ground operators. Next, the RPOD concept of operations is defined with detailed events listed in a mission timeline. Third, a state machine diagram is developed to show all PSAM states, including all possible transitions between them. After this, the PSAM states and transitions are entered into a sequencing software emulator and parameter values and modes are defined for GN&C software elements. Finally, the PSAM architecture is tested within an integrated simulation environment by connecting it with prototypes of relevant GN&C flight software elements and with detailed vehicle models. After the sequencing design has been finalized and tested, it is implemented in flight software.

Schulte, Peter Z.↗

NASA NTRS1990

GCS programmer's manual

A variety of instructions to be used in the development of implementations of software for the Guidance and Control Software (GCS) project is described. This document fulfills the Radio Technical Commission for Aeronautics RTCA/DO-178A guidelines, 'Software Considerations in Airborne Systems and Equipment Certification' requirements for document No. 4, which specifies the information necessary for understanding and programming the host computer, and document No. 12, which specifies the software design and implementation standards that are applicable to the software development and testing process. Information on the following subjects is contained: activity recording, communication protocol, coding standards, change management, error handling, design standards, problem reporting, module testing logs, documentation formats, accuracy requirements, and programmer responsibilities.

Lowman, Douglas S.↗

NASA NTRS2002

Issues in Software System Safety: Polly Ann Smith Co. versus Ned I. Ludd

This paper is a work of fiction, but it is fiction with a very real purpose: to stimulate careful thought and friendly discussion about some questions for which thought is often careless and discussion is often unfriendly. To accomplish this purpose, the paper creates a fictional legal case. The most important issue in this fictional case is whether certain proffered expert testimony about software engineering for safety critical systems should be admitted. Resolving this issue requires deciding the extent to which current practices and research in software engineering, especially for safety-critical systems, can rightly be considered based on knowledge, rather than opinion.

Holloway, C. Michael↗

NASA NTRS2016

Analyzing and Predicting Effort Associated with Finding and Fixing Software Faults

Context: Software developers spend a significant amount of time fixing faults. However, not many papers have addressed the actual effort needed to fix software faults. Objective: The objective of this paper is twofold: (1) analysis of the effort needed to fix software faults and how it was affected by several factors and (2) prediction of the level of fix implementation effort based on the information provided in software change requests. Method: The work is based on data related to 1200 failures, extracted from the change tracking system of a large NASA mission. The analysis includes descriptive and inferential statistics. Predictions are made using three supervised machine learning algorithms and three sampling techniques aimed at addressing the imbalanced data problem. Results: Our results show that (1) 83% of the total fix implementation effort was associated with only 20% of failures. (2) Both safety critical failures and post-release failures required three times more effort to fix compared to non-critical and pre-release counterparts, respectively. (3) Failures with fixes spread across multiple components or across multiple types of software artifacts required more effort. The spread across artifacts was more costly than spread across components. (4) Surprisingly, some types of faults associated with later life-cycle activities did not require significant effort. (5) The level of fix implementation effort was predicted with 73% overall accuracy using the original, imbalanced data. Using oversampling techniques improved the overall accuracy up to 77%. More importantly, oversampling significantly improved the prediction of the high level effort, from 31% to around 85%. Conclusions: This paper shows the importance of tying software failures to changes made to fix all associated faults, in one or more software components and/or in one or more software artifacts, and the benefit of studying how the spread of faults and other factors affect the fix implementation effort.

software fix implementation effort↗

NASA NTRS2001

Fast Formal Analysis of Requirements via "Topoi Diagrams"

Early testing of requirements can decrease the cost of removing errors in software projects. However, unless done carefully, that testing process can significantly add to the cost of requirements analysis. We show here that requirements expressed as topoi diagrams can be built and tested cheaply using our SP2 algorithm, the formal temporal properties of a large class of topoi can be proven very quickly, in time nearly linear in the number of nodes and edges in the diagram. There are two limitations to our approach. Firstly, topoi diagrams cannot express certain complex concepts such as iteration and sub-routine calls. Hence, our approach is more useful for requirements engineering than for traditional model checking domains. Secondly, out approach is better for exploring the temporal occurrence of properties than the temporal ordering of properties. Within these restrictions, we can express a useful range of concepts currently seen in requirements engineering, and a wide range of interesting temporal properties.

Menzies, Tim↗

NASA NTRS2002

MAC/GMC 4.0 User's Manual: Keywords Manual

This document is the second volume in the three volume set of User's Manuals for the Micromechanics Analysis Code with Generalized Method of Cells Version 4.0 (MAC/GMC 4.0). Volume 1 is the Theory Manual, this document is the Keywords Manual, and Volume 3 is the Example Problem Manual. MAC/GMC 4.0 is a composite material and laminate analysis software program developed at the NASA Glenn Research Center. It is based on the generalized method of cells (GMC) micromechanics theory, which provides access to the local stress and strain fields in the composite material. This access grants GMC the ability to accommodate arbitrary local models for inelastic material behavior and various types of damage and failure analysis. MAC/GMC 4.0 has been built around GMC to provide the theory with a user-friendly framework, along with a library of local inelastic, damage, and failure models. Further, applications of simulated thermo-mechanical loading, generation of output results, and selection of architectures to represent the composite material have been automated in MAC/GMC 4.0. Finally, classical lamination theory has been implemented within MAC/GMC 4.0 wherein GMC is used to model the composite material response of each ply. Consequently, the full range of GMC composite material capabilities is available for analysis of arbitrary laminate configurations as well. This volume describes the basic information required to use the MAC/GMC 4.0 software, including a 'Getting Started' section, and an in-depth description of each of the 22 keywords used in the input file to control the execution of the code.

Bednarcyk, Brett A.↗

NASA NTRS1988

A communication channel model of the software process

Reported here is beginning research into a noisy communication channel analogy of software development process productivity, in order to establish quantifiable behavior and theoretical bounds. The analogy leads to a fundamental mathematical relationship between human productivity and the amount of information supplied by the developers, the capacity of the human channel for processing and transmitting information, the software product yield (object size), the work effort, requirements efficiency, tool and process efficiency, and programming environment advantage. Also derived is an upper bound to productivity that shows that software reuse is the only means than can lead to unbounded productivity growth; practical considerations of size and cost of reusable components may reduce this to a finite bound.

Tausworthe, R. C.↗