SEARCH · Engineering Papers
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.
The potential user requirements for Information Services Platforms at geosynchronous orbits were investigated. A rationale for identifying the corollary system requirements and supporting research and technology needs was provided.
Manned space flight programming language and compiler requirements analysis
Data from the Viking Orbiter Modal Test Program are used to illustrate modal test measurement and analysis requirements. The test was performed using a multiple shake dwell technique where data were acquired one channel at a time and recorded on paper tape. Up to ten shakers were used simultaneously, with a complete set of data consisting of 290 strain-gage readings and 125 accelerometer readings. The data analysis provided information sufficient to minimize errors in the data. The list of analyses in order of value is orthogonality, residual mass, frequency sweep, data checks to assure good test data, multilevel trends, global kinetic energy, and global strain energy.
Analysis of functional requirements for data management systems used with space shuttle - Vol. 1
This paper describes the use of a technique called 'paper simulation' in the analysis of user requirements for interactive computer systems. In a paper simulation, the user solves problems with the aid of a 'computer', as in normal man-in-the-loop simulation. In this procedure, though, the computer does not exist, but is simulated by the experimenters. This allows simulated problem solving early in the design effort, and allows the properties and degree of structure of the system and its dialogue to be varied. The technique, and a method of analyzing the results, are illustrated with examples from a recent paper simulation exercise involving a Space Shuttle flight design task
This paper provides a Safety Checklist for use during the analysis of software requirements for spacecraft and other safety-critical, embedded systems.
Living and working on Mars will require model-based computer systems for maintaining and controlling complex life support, communication, transportation, and power systems. This technology must work properly on the first three-year mission, augmenting human autonomy, without adding-yet more complexity to be diagnosed and repaired. One design method is to work with scientists in analog (mars-like) setting to understand how they prefer to work, what constrains will be imposed by the Mars environment, and how to ameliorate difficulties. We describe how we are using empirical requirements analysis to prototype model-based tools at a research station in the High Canadian Arctic.
This report presents various use case scenarios for wireless technology -including radio frequency (RF), optical, and acoustic- and studies requirements and boundary conditions in each scenario. The results of this study can be used to prioritize technology evaluation and development and in the long run help in development of a roadmap for future use of wireless technology. The presented scenarios cover the following application areas: (i) Space Vehicles (manned/unmanned), (ii) Satellites and Payloads, (iii) Surface Explorations, (iv) Ground Systems, and (v) Habitats. The requirement analysis covers two parallel set of conditions. The first set includes the environmental conditions such as temperature, radiation, noise/interference, wireless channel characteristics and accessibility. The second set of requirements are dictated by the application and may include parameters such as latency, throughput (effective data rate), error tolerance, and reliability. This report provides a comprehensive overview of all requirements from both perspectives and details their effects on wireless system reliability and network design. Application area examples are based on 2015 NASA Technology roadmap with specific focus on technology areas: TA 2.4, 3.3, 5.2, 5.5, 6.4, 7.4, and 10.4 sections that might benefit from wireless technology.
This Technical Publication (TP) is meant to address a number of topics related to the application of Monte Carlo simulation to launch vehicle design and requirements analysis. Although the focus is on a launch vehicle application, the methods may be applied to other complex systems as well. The TP is organized so that all the important topics are covered in the main text, and detailed derivations are in the appendices. The TP first introduces Monte Carlo simulation and the major topics to be discussed, including discussion of the input distributions for Monte Carlo runs, testing the simulation, how many runs are necessary for verification of requirements, what to do if results are desired for events that happen only rarely, and postprocessing, including analyzing any failed runs, examples of useful output products, and statistical information for generating desired results from the output data. Topics in the appendices include some tables for requirements verification, derivation of the number of runs required and generation of output probabilistic data with consumer risk included, derivation of launch vehicle models to include possible variations of assembled vehicles, minimization of a consumable to achieve a two-dimensional statistical result, recontact probability during staging, ensuring duplicated Monte Carlo random variations, and importance sampling.
In fiscal year 1997, Strategic Insight performed analytical studies for NASA's Highly Reusable Space Transportation (HRST) program, creating program documents which illuminated technical requirements and critical research opportunities. Studies were performed to structure and confirm HRST's evolving technical requirements, building on Marshall's Phase 1 work, which defined HRST system concepts, analytical tools and high-level issues for assessment in Phase 2. Specifically, Strategic Insight: (1) Performed a requirements analysis to update HRST: An Advanced Concepts Study, Study Guidelines, Version 2.0 of January 22, 1996; only minor changes were recommended for the given parameters of interest to concept designers; (2) Conducted mini-workshops during HRST Working Group meetings on April 14-15, 1997 and July 22-24, 1997; and (3) Created structures for technology road maps of candidate HRST concepts, both subsystem and end-to-end concepts, emerging from the 13 cooperative agreement projects.
Life support systems are a critical part of human exploration beyond low earth orbit. NASA s Altair Lunar Lander has unique missions to perform and will need a unique life support system to complete them. Initial work demonstrated a feasible minimally-functional Lander design. This work was completed in Design Analysis Cycles (DAC) 1, 2, and 3 were reported in a previous paper. On October 21, 2008, the Altair project completed the Mission Concept Review (MCR), moving the project into Phase A. In Phase A activities, the project is preparing for the System Requirements Review (SRR). Altair has conducted two Requirements Analysis Cycles (RACs) to begin this work. During this time, the life support team must examine the Altair mission concepts, Constellation Program level requirements, and interfaces with other vehicles and spacesuits to derive the right set of requirements for the new vehicle. The minimum functionality design meets some of these requirements already and can be easily adapted to meet others. But Altair must identify which will be more costly in mass, power, or other resources to meet. These especially costly requirements must be analyzed carefully to be sure they are truly necessary, and are the best way of explaining and meeting the true need. If they are necessary and clear, they become important mass threats to track at the vehicle level. If they are not clear or do not seem necessary to all stakeholders, Altair must work to redefine them or push back on the requirements writers. Additionally, the life support team is evaluating new technologies to see if they are more effective than the existing baseline design at performing necessary functions in Altair s life support system.
Life support systems are a critical part of human exploration beyond low earth orbit. NASA's Altair Lunar Lander has unique missions to perform and will need a unique life support system to complete them. Initial work demonstrated a feasible minimally -functional Lander design. This work was completed in Design Analysis Cycles (DAC) 1, 2, and 3 were reported in a previous paper'. On October 21, 2008, the Altair project completed the Mission Concept Review (MCR), moving the project into Phase A. In Phase A activities, the project is preparing for the System Requirements Review (SRR). Altair has conducted two Requirements Analysis Cycles (RACs) to begin this work. During this time, the life support team must examine the Altair mission concepts, Constellation Program level requirements, and interfaces with other vehicles and spacesuits to derive the right set of requirements for the new vehicle. The minimum functionality design meets some of these requirements already and can be easily adapted to meet others. But Altair must identify which will be more costly in mass, power, or other resources to meet. These especially costly requirements must be analyzed carefully to be sure they are truly necessary, and are the best way of explaining and meeting the true need. If they are necessary and clear, they become important mass threats to track at the vehicle level. If they are not clear or do not seem necessary to all stakeholders, Altair must work to redefine them or push back on the requirements writers. Additionally, the life support team is evaluating new technologies to see if they are more effective than the existing baseline design at performing necessary functions in Altair's life support system.
Operations conducted from a space station in low Earth orbit which have different constraints and opportunities than those conducted from direct Earth launch were examined. While a space station relieves many size and performance constraints on the space shuttle, the space station's inertial orbit has different launch window constraints from those associated with customary Earth launches which reflect upon upper stage capability. A performance requirements analysis was developed to provide a reference source of parametric data, and specific case solutions and upper stage sizing trade to assist potential space station users and space station and upper stage developers assess the impacts of a space station on missions of interest.
Space station requirements and design, discussing space shuttles, operational personnel, long term effects, logistical systems, functions, etc
A study of laboratory measurement and analysis of pyrotechnic shock prompted by a discrepancy in preliminary Mariner Jupiter/Saturn shock test data is reported. It is shown that before generating shock response plots from any recorded pyrotechnic event, a complete review of each instrumentation and analysis system must be made. In addition, the frequency response capability of the tape recorder used should be as high as possible; the discrepancies in the above data were due to inadequate frequency response in the FM tape recorders. The slew rate of all conditioning amplifiers and input converters must be high enough to prevent signal distortion at maximum input voltage; amplifier ranges should be selected so that the input pulse is approximately 50% of full scale; the Bessel response type should be chosen for digital shock analysis if antialiasing filters are employed; and transducer selection must consider maximum acceleration limit, mounted resonance frequency, flat clean mounting surfaces, base bending sensitivity, and proper torque.
An investigation of laboratory measurement and analysis of pyrotechnic shock is described which was prompted when two separate facilities produced discrepant pyrotechnic-shock data while testing Mariner Jupiter/Saturn 1977 spacecraft hardware. Both testing facilities are thoroughly examined to find a possible cause for the discrepancies, and it is noted that one facility incorporated an FM tape recorder operating at 60 in./sec with a frequency response of 20 kHz while the other incorporated a tape recorder operating at 120 in./sec with a frequency response of 80 kHz. It is found that the discrepancies were a direct result of the inadequate recording frequency response of the tape recorders. Other factors involved in obtaining more accurate data are discussed.
A set of procedural and functional requirements are presented for the interface between software development environments and software integration and test systems used for space station ground systems software. The requirements focus on the need for centralized configuration management of software as it is transitioned from development to formal, target based testing. This concludes the GSDE Interface Requirements study. A summary is presented of findings concerning the interface itself, possible interface and prototyping directions for further study, and results of the investigation of the Cronus distributed applications environment.
The use of software fault trees for requirements identification and analysis in an Intrusion Detection System (IDS) is described.