Search NASA⌕ Search

SEARCH · Search NASA

Results for “specification”

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 217 records · Page 12
All sourcesNASA NTRSDOE OSTI
NASA NTRS1982

Space Research and Technology Program: Program and specific objectives, document approval

A detailed view of the Space Research and Technology program work breakdown structure is provided down to the specific objective level. Goals or objectives at each of these levels are set forth. The specific objective narratives are structured into several parts. First, a short paragraph statement of the specific objective is given. This is followed by a list of subobjectives. A list of targets is then provided for those areas of the specific objective that are amenable to a quantitative description of technical accomplishment and schedule. Fluid and thermal physics, materials and structures, computer science and electronics, space energy conversion, multidisciplinary research, controls and human factors, chemical propulsion, spacecraft systems, transportation systems, platform systems, and spacecraft systems technology comprise the principal research programs.

Source record↗
NASA NTRS1982

Component-specific modeling

The ability to accurately structurally analyze engine components to assure that they can survive for their designed lifetime in an increasingly harsh environment is discussed. Under the HOST (HOt Section Technology) program, advanced component-specific modeling methods, with built-in analysis capability, will be developed separately for burner liners, turbine blades and vanes. These modeling methods will make maximum use of, but will not rely solely on, existing analysis methods and techniques, to analyze the three identified components. Nor will the complete structural analysis of a component necessarily be performed as a single analysis. The approach to be taken will develop complete software analysis packages with internal, component-specific, self-adaptive solution strategies. Each package will contain a set of modeling and analysis tools. The selection and order of specific methods and techniques within the set to be applied will depend on the specific-component, the current thermo-mechanical loading, and the current state of the component. All modeling and analysis decisions will be made internally based on developed decision criteria within the solution strategies; minimal user intervention will be required.

Hirschbein, M. S.↗
NASA NTRS1985

NASA/aircraft industry standard specification for graphite fiber toughened thermoset resin composite material

A standard specification for a selected class of graphite fiber/toughened thermoset resin matrix material was developed through joint NASA/Aircraft Industry effort. This specification was compiled to provide uniform requirements and tests for qualifying prepreg systems and for acceptance of prepreg batches. The specification applies specifically to a class of composite prepreg consisting of unidirectional graphite fibers impregnated with a toughened thermoset resin that produce laminates with service temperatures from -65 F to 200 F when cured at temperatures below or equal to 350 F. The specified prepreg has a fiber areal weight of 145 g sq m. The specified tests are limited to those required to set minimum standards for the uncured prepreg and cured laminates, and are not intended to provide design allowable properties.

Source record↗
NASA NTRS1987

Cockpit management and Specific Behavioral Objectives (SBOs)

One of the primary tools used to accomplish the task of effective training is the specific behavioral objective (SBO). An SBO is simply a statement which specifically identifies a small segment of the final behavior sought, and a little more. The key word is specific. The company pinpoints exactly what it is it wants the pilot to do after completing training, and what it should evaluate from the point of view of both the program and the pilot. It tells the junior crewmember exactly, specifically, what he should monitor and support insofar as the management function is concerned. It gives greater meaning to the term second in command. And finally, it tells the supervisory pilot exactly what he should observe, evaluate, and instruct, insofar as the management function is concerned.

Mudge, R. W.↗
NASA NTRS1988

MODIS Information, Data, and Control System (MIDACS) system specifications and conceptual design

The MODIS Information, Data, and Control System (MIDACS) Specifications and Conceptual Design Document discusses system level requirements, the overall operating environment in which requirements must be met, and a breakdown of MIDACS into component subsystems, which include the Instrument Support Terminal, the Instrument Control Center, the Team Member Computing Facility, the Central Data Handling Facility, and the Data Archive and Distribution System. The specifications include sizing estimates for the processing and storage capacities of each data system element, as well as traffic analyses of data flows between the elements internally, and also externally across the data system interfaces. The specifications for the data system, as well as for the individual planning and scheduling, control and monitoring, data acquisition and processing, calibration and validation, and data archive and distribution components, do not yet fully specify the data system in the complete manner needed to achieve the scientific objectives of the MODIS instruments and science teams. The teams have not yet been formed; however, it was possible to develop the specifications and conceptual design based on the present concept of EosDIS, the Level-1 and Level-2 Functional Requirements Documents, the Operations Concept, and through interviews and meetings with key members of the scientific community.

Han, D.↗
NASA NTRS1986

Analysis and specification tools in relation to the APSE

Ada and the Ada Programming Support Environment (APSE) specifically address the phases of the system/software life cycle which follow after the user's problem was translated into system and software development specifications. The waterfall model of the life cycle identifies the analysis and requirements definition phases as preceeding program design and coding. Since Ada is a programming language and the APSE is a programming support environment, they are primarily targeted to support program (code) development, tecting, and maintenance. The use of Ada based or Ada related specification languages (SLs) and program design languages (PDLs) can extend the use of Ada back into the software design phases of the life cycle. Recall that the standardization of the APSE as a programming support environment is only now happening after many years of evolutionary experience with diverse sets of programming support tools. Restricting consideration to one, or even a few chosen specification and design tools, could be a real mistake for an organization or a major project such as the Space Station, which will need to deal with an increasingly complex level of system problems. To require that everything be Ada-like, be implemented in Ada, run directly under the APSE, and fit into a rigid waterfall model of the life cycle would turn a promising support environment into a straight jacket for progress.

Hendricks, John W.↗
NASA NTRS1991

Formal specification and verification of Ada software

The use of formal methods in software development achieves levels of quality assurance unobtainable by other means. The Larch approach to specification is described, and the specification of avionics software designed to implement the logic of a flight control system is given as an example. Penelope is described which is an Ada-verification environment. The Penelope user inputs mathematical definitions, Larch-style specifications and Ada code and performs machine-assisted proofs that the code obeys its specifications. As an example, the verification of a binary search function is considered. Emphasis is given to techniques assisting the reuse of a verification effort on modified code.

Hird, Geoffrey R.↗
NASA NTRS1991

Integrated flight/propulsion control specifications for systems with two-way coupling

A general technique for generating specifications for integrated flight propulsion control is extended to include systems with significant two-way coupling between the flight and propulsion systems. These specification define how the subsystems must perform within an integrated control system in order to assure that performance goals (specifically stability) are met when the subsystems are combined to form a closed-loop integrated system. Such specifications are useful for a large class of integrated control problems that are best approached in a partitioned or decentralized manner. An example demonstrating the application of these techniques to a simple helicopter problem is provided.

Rock, Stephen M.↗
NASA NTRS1991

Experiment module/support module interface specification for the reusable reentry satellite

This Interface Specification (IFS) identifies, defines, and controls the interface between the Reusable Reentry Satellite (RRS) Vehicle (RRV) Experiment Module (EM) and the Support Module (SM) equipment. Contained in this specification are the physical, functional, and environmental interface requirements for the SM and EM. This specification is tailored to the unique requirements of the EM associated with the Rodent Module. The addenda to this specification contain the requirements for alternate EM's.

Source record↗
NASA NTRS1992

On the nature of bias and defects in the software specification process

Implementation bias in a specification is an arbitrary constraint in the solution space. This paper describes the problem of bias. Additionally, this paper presents a model of the specification and design processes describing individual subprocesses in terms of precision/detail diagrams and a model of bias in multi-attribute software specifications. While studying how bias is introduced into a specification we realized that software defects and bias are dual problems of a single phenomenon. This was used to explain the large proportion of faults found during the coding phase at the Software Engineering Laboratory at NASA/GSFC.

Straub, Pablo A.↗
NASA NTRS1992

The KASE approach to domain-specific software systems

Designing software systems, like all design activities, is a knowledge-intensive task. Several studies have found that the predominant cause of failures among system designers is lack of knowledge: knowledge about the application domain, knowledge about design schemes, knowledge about design processes, etc. The goal of domain-specific software design systems is to explicitly represent knowledge relevant to a class of applications and use it to partially or completely automate various aspects of the designing systems within that domain. The hope is that this would reduce the intellectual burden on the human designers and lead to more efficient software development. In this paper, we present a domain-specific system built on top of KASE, a knowledge-assisted software engineering environment being developed at the Stanford Knowledge Systems Laboratory. We introduce the main ideas underlying the construction of domain specific systems within KASE, illustrate the application of the idea in the synthesis of a system for tracking aircraft from radar signals, and discuss some of the issues in constructing domain-specific systems.

Bhansali, Sanjay↗
NASA NTRS1992

Comparison of specificity and information for fuzzy domains

This paper demonstrates how an integrated theory can be built on the foundation of possibility theory. Information and uncertainty were considered in 'fuzzy' literature since 1982. Our departing point is the model proposed by Klir for the discrete case. It was elaborated axiomatically by Ramer, who also introduced the continuous model. Specificity as a numerical function was considered mostly within Dempster-Shafer evidence theory. An explicity definition was given first by Yager, who has also introduced it in the context of possibility theory. Axiomatic approach and the continuous model have been developed very recently by Ramer and Yager. They also establish a close analytical correspondence between specificity and information. In literature to date, specificity and uncertainty are defined only for the discrete finite domains, with a sole exception. Our presentation removes these limitations. We define specificity measures for arbitrary measurable domains.

Ramer, Arthur↗
NASA NTRS1988

NASA specification for manufacturing and performance requirements of NASA standard aerospace nickel-cadmium cells

On November 25, 1985, the NASA Chief Engineer established a NASA-wide policy to maintain and to require the use of the NASA standard for aerospace nickel-cadmium cells and batteries. The Associate Administrator for Safety, Reliability, Maintainability, and Quality Assurance stated on December 29, 1986, the intent to retain the NASA standard cell usage policy established by the Office of the Chief Engineer. The current NASA policy is also to incorporate technological advances as they are tested and proven for spaceflight applications. This policy will be implemented by modifying the existing standard cells or by developing new NASA standards and their specifications in accordance with the NASA's Aerospace Battery Systems Program Plan. This NASA Specification for Manufacturing and Performance Requirements of NASA Standard Aerospace Nickel-Cadmium Cells is prepared to provide requirements for the NASA standard nickel-cadmium cell. It is an interim specification pending resolution of the separator material availability. This specification has evolved from over 15 years of nickel-cadmium cell experience by NASA. Consequently, considerable experience has been collected and cell performance has been well characterized from many years of ground testing and from in-flight operations in both geosynchronous (GEO) and low earth orbit (LEO) applications. NASA has developed and successfully used two standard flight qualified cell designs.

Source record↗
NASA NTRS1993

An elementary tutorial on formal specification and verification using PVS

A tutorial on the development of a formal specification and its verification using the Prototype Verification System (PVS) is presented. The tutorial presents the formal specification and verification techniques by way of specific example - an airline reservation system. The airline reservation system is modeled as a simple state machine with two basic operations. These operations are shown to preserve a state invariant using the theorem proving capabilities of PVS. The technique of validating a specification via 'putative theorem proving' is also discussed and illustrated in detail. This paper is intended for the novice and assumes only some of the basic concepts of logic. A complete description of user inputs and the PVS output is provided and thus it can be effectively used while one is sitting at a computer terminal.

Butler, Ricky W.↗
NASA NTRS1994

NASA geometry data exchange specification for computational fluid dynamics (NASA IGES)

This document specifies a subset of an existing product data exchange specification that is widely used in industry and government. The existing document is called the Initial Graphics Exchange Specification. This document, a subset of IGES, is intended for engineers analyzing product performance using tools such as computational fluid dynamics (CFD) software. This document specifies how to define mathematically and exchange the geometric model of an object. The geometry is represented utilizing nonuniform rational B-splines (NURBS) curves and surfaces. Only surface models are represented; no solid model representation is included. This specification does not include most of the other types of product information available in IGES (e.g., no material properties or surface finish properties) and does not provide all the specific file format details of IGES. The data exchange protocol specified in this document is fully conforming to the American National Standard (ANSI) IGES 5.2.

Blake, Matthew W.↗
NASA NTRS1994

The meteorological parameterization of specific attenuation in rain viewed at Nadir

Polynomial expressions are presented for the parameterization of the specific attenuation in rain from 9 to 38 GHz that are applicable to a wide range of naturally occurring drop size distributions and for viewing angles close to nadir. Because the temperature T affects the specific attenuation at some frequencies, expressions for the polynomial coefficients as functions of T are also provided for -10C less than or equal to T less than or equal to 30C. The advantage of this parameterization is that even without a detailed specification of the drop size distribution, useful estimates of the specific attenuation are often possible given only two out of three parameters, namely, the rainfall rate R, the rainwater content W, or D(sub m) (the mass-weighted mean drop diameter), particularly if the temperature is also specified.

Jameson, A. R.↗
NASA NTRS1992

Domain and Specification Models for Software Engineering

This paper discusses our approach to representing application domain knowledge for specific software engineering tasks. Application domain knowledge is embodied in a domain model. Domain models are used to assist in the creation of specification models. Although many different specification models can be created from any particular domain model, each specification model is consistent and correct with respect to the domain model. One aspect of the system-hierarchical organization is described in detail.

Iscoe, Neil↗
NASA NTRS1995

Formal Methods Specification and Verification Guidebook for Software and Computer Systems: Planning and Technology Insertion - Volume 1

The Formal Methods Specification and Verification Guidebook for Software and Computer Systems describes a set of techniques called Formal Methods (FM), and outlines their use in the specification and verification of computer systems and software. Development of increasingly complex systems has created a need for improved specification and verification techniques. NASA's Safety and Mission Quality Office has supported the investigation of techniques such as FM, which are now an accepted method for enhancing the quality of aerospace applications. The guidebook provides information for managers and practitioners who are interested in integrating FM into an existing systems development process. Information includes technical and administrative considerations that must be addressed when establishing the use of FM on a specific project. The guidebook is intended to aid decision makers in the successful application of FM to the development of high-quality systems at reasonable cost. This is the first volume of a planned two-volume set. The current volume focuses on administrative and planning considerations for the successful application of FM.

Source record↗