SEARCH · Engineering Papers

Results for “SPECIFICATIONS”

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 379 records · Page 21

All sources NASA NTRS DOE OSTI

NASA NTRS1989

Outline for reusable reentry satellite system specification, volumes 1 - volume 9

This document describes the outline proposed by the SAIC team for the RRS System Specification document. This document will be updated periodically during the course of the study, providing design insights and information pertinent to the various elements of the RRS design. The RRS System Specification document organization is shown schematically. The RRS Vehicle (RRV), Payload Module (PM), and the Operations Support (OS) are the three main segments of the overall system for which formal interface control will exist. The number and relationship of these interface specifications to the main segments is also shown.

Source record↗

NASA NTRS1992

Domain-specific functional software testing: A progress report

Software Engineering is a knowledge intensive activity that involves defining, designing, developing, and maintaining software systems. In order to build effective systems to support Software Engineering activities, Artificial Intelligence techniques are needed. The application of Artificial Intelligence technology to Software Engineering is called Knowledge-based Software Engineering (KBSE). The goal of KBSE is to change the software life cycle such that software maintenance and evolution occur by modifying the specifications and then rederiving the implementation rather than by directly modifying the implementation. The use of domain knowledge in developing KBSE systems is crucial. Our work is mainly related to one area of KBSE that is called automatic specification acquisition. One example is the WATSON prototype on which our current work is based. WATSON is an automatic programming system for formalizing specifications for telephone switching software mainly restricted to POTS, i.e., plain old telephone service. Our current approach differentiates itself from other approaches in two antagonistic ways. On the one hand, we address a large and complex real-world problem instead of a 'toy domain' as in many research prototypes. On the other hand, to allow such scaling, we had to relax the ambitious goal of complete automatic programming, to the easier task of automatic testing.

Nonnenmann, Uwe↗

NASA NTRS1993

Automatic specification of reliability models for fault-tolerant computers

The calculation of reliability measures using Markov models is required for life-critical processor-memory-switch structures that have standby redundancy or that are subject to transient or intermittent faults or repair. The task of specifying these models is tedious and prone to human error because of the large number of states and transitions required in any reasonable system. Therefore, model specification is a major analysis bottleneck, and model verification is a major validation problem. The general unfamiliarity of computer architects with Markov modeling techniques further increases the necessity of automating the model specification. Automation requires a general system description language (SDL). For practicality, this SDL should also provide a high level of abstraction and be easy to learn and use. The first attempt to define and implement an SDL with those characteristics is presented. A program named Automated Reliability Modeling (ARM) was constructed as a research vehicle. The ARM program uses a graphical interface as its SDL, and it outputs a Markov reliability model specification formulated for direct use by programs that generate and evaluate the model.

Liceaga, Carlos A.↗

NASA NTRS1993

Reference manual for a Requirements Specification Language (RSL), version 2.0

This report is a Reference Manual for a general-purpose Requirements Specification Language, RSL. The purpose of RSL is to specify precisely the external structure of a mechanized system and to define requirements that the system must meet. A system can be comprised of a mixture of hardware, software, and human processing elements. RSL is a hybrid of features found in several popular requirements specification languages and includes constructs for formal mathematical specification.

Fisher, Gene L.↗

NASA NTRS1992

Khoros software specification format and interoperability

Khoros defines formats for User Interface Specification (UIS) and Program Specification (PS) files. From such files, its code generator, Ghostwriter, creates source files and documentation. The great advantage of the system is that the code fragments that make up part of the PS file are purely generic. All Khoros-related code is created by the code generator; this includes all user interface code. As a matter of fact, both specification files are very generic in nature. Thus, one could imagine using it as the basis for other software systems. A case is made that writing a code generator that would create IRAF-compatible code from the Khoros UIS and PS files is fairly trivial. Another aspect of the Khoros system conventions concerns the way execution commands are generated by the user interface and the actual syntax of those commands. The protocols are such that interoperability at the level of executable modules is readily possible.

Rots, A. H.↗

NASA NTRS1994

Specific features of space-time variations of ozone during the development of intensive tropical disturbances

An analysis of specific features of space-time variations of ozone in the tropical areas which has been performed on the basis of processing of the results of special expedition studies in the Atlantic and Pacific in 1987-1990 and the data of observations at the stations of the world ozonometric network over the 25-year period. The existence of a cause-and-effect relation has been revealed between the processes determining tropical cyclone (TC) development, and specific features of variations of the total content of ozone (TCO) and the vertical distribution of ozone (VDO) in the regions of TC action. Characteristic features of day-to-day and daily variations of TCO during TC development have been found. On the periphery of a developing TC, 1-4 days before it reaches the stage of storm, TCO increases, on average, by 5-8 percent, and a substantial increase in the concentration of ozone occurs in the middle and upper troposphere. The most probable physical mechanisms relating the observed specific features of ozone variations to TC evolution have been suggested. A hypothesis of the possibility of using ozone as an indicator for early prediction of TC development has been substantiated.

Nerushev, Alexander F.↗

NASA NTRS1994

AMPHION: Specification-based programming for scientific subroutine libraries

AMPHION is a knowledge-based software engineering (KBSE) system that guides a user in developing a diagram representing a formal problem specification. It then automatically implements a solution to this specification as a program consisting of calls to subroutines from a library. The diagram provides an intuitive domain oriented notation for creating a specification that also facilitates reuse and modification. AMPHION'S architecture is domain independent. AMPHION is specialized to an application domain by developing a declarative domain theory. Creating a domain theory is an iterative process that currently requires the joint expertise of domain experts and experts in automated formal methods for software development.

Lowry, Michael↗

NASA NTRS1995

The effect of environmental initiatives on NASA specifications and standards activities

The NASA Operational Environment Team (NOET) has conducted a survey of NASA centers specifications and standards that require the use of Ozone Depleting Substances (ODS's) (Chlorofluorocarbons (CFCs), Halons, and chlorinated solvents). The results of this survey are presented here, along with a pathfinder approach utilized at Marshall Space Flight Center (MSFC) to eliminate the use of ODS's in targeted specifications and standards. Presented here are the lessons learned from a pathfinder effort to replace CFC-113 in a significant MSFC specification for cleaning and cleanliness verification methods for oxygen, fuel and pneumatic service, including Shuttle propulsion elements.

Griffin, Dennis↗

NASA NTRS1995

Integrated performance and reliability specification for digital avionics systems

This paper describes an automated tool for performance and reliability assessment of digital avionics systems, called the Automated Design Tool Set (ADTS). ADTS is based on an integrated approach to design assessment that unifies traditional performance and reliability views of system designs, and that addresses interdependencies between performance and reliability behavior via exchange of parameters and result between mathematical models of each type. A multi-layer tool set architecture has been developed for ADTS that separates the concerns of system specification, model generation, and model solution. Performance and reliability models are generated automatically as a function of candidate system designs, and model results are expressed within the system specification. The layered approach helps deal with the inherent complexity of the design assessment process, and preserves long-term flexibility to accommodate a wide range of models and solution techniques within the tool set structure. ADTS research and development to date has focused on development of a language for specification of system designs as a basis for performance and reliability evaluation. A model generation and solution framework has also been developed for ADTS, that will ultimately encompass an integrated set of analytic and simulated based techniques for performance, reliability, and combined design assessment.

Brehm, Eric W.↗

NASA NTRS1993

Position-specific behaviors and their impact on crew performance: Implications for training

The present study was motivated by results from a preliminary report documenting the impact of specific crewmembers on overall crew performance (Wilhelm & Law, 1992), and a cross-airline cross-fleet project investigating human factors behaviors of commercial aviation flightcrews (Helmreich, Butler, Whilhelm, & Lofaro, 1992). The purpose of the current investigation is to study how position-specific behaviors impact flightcrew performance, and how these position-specific behaviors differ between two airlines and two flying environments. Implications for training will also be addressed.

Law, J. Randolph↗

NASA NTRS1995

The specification-based validation of reliable multicast protocol: Problem Report

Reliable Multicast Protocol (RMP) is a communication protocol that provides an atomic, totally ordered, reliable multicast service on top of unreliable IP multicasting. In this report, we develop formal models for RMP using existing automated verification systems, and perform validation on the formal RMP specifications. The validation analysis help identifies some minor specification and design problems. We also use the formal models of RMP to generate a test suite for conformance testing of the implementation. Throughout the process of RMP development, we follow an iterative, interactive approach that emphasizes concurrent and parallel progress of implementation and verification processes. Through this approach, we incorporate formal techniques into our development process, promote a common understanding for the protocol, increase the reliability of our software, and maintain high fidelity between the specifications of RMP and its implementation.

Wu, Yunqing↗

NASA NTRS1995

The Specification-Based Validation of Reliable Multicast Protocol

Reliable Multicast Protocol (RMP) is a communication protocol that provides an atomic, totally ordered, reliable multicast service on top of unreliable IP multicasting. In this report, we develop formal models for RMP using existing automated verification systems, and perform validation on the formal RMP specifications. The validation analysis help identifies some minor specification and design problems. We also use the formal models of RMP to generate a test suite for conformance testing of the implementation. Throughout the process of RMP development, we follow an iterative, interactive approach that emphasizes concurrent and parallel progress of the implementation and verification processes. Through this approach, we incorporate formal techniques into our development process, promote a common understanding for the protocol, increase the reliability of our software, and maintain high fidelity between the specifications of RMP and its implementation.

Wu, Yunqing↗

NASA NTRS1997

An Automated Method for Identifying Inconsistencies within Diagrammatic Software Requirements Specifications

The development of large-scale, composite software in a geographically distributed environment is an evolutionary process. Often, in such evolving systems, striving for consistency is complicated by many factors, because development participants have various locations, skills, responsibilities, roles, opinions, languages, terminology and different degrees of abstraction they employ. This naturally leads to many partial specifications or viewpoints. These multiple views on the system being developed usually overlap. From another aspect, these multiple views give rise to the potential for inconsistency. Existing CASE tools do not efficiently manage inconsistencies in distributed development environment for a large-scale project. Based on the ViewPoints framework the WHERE (Web-Based Hypertext Environment for requirements Evolution) toolkit aims to tackle inconsistency management issues within geographically distributed software development projects. Consequently, WHERE project helps make more robust software and support software assurance process. The long term goal of WHERE tools aims to the inconsistency analysis and management in requirements specifications. A framework based on Graph Grammar theory and TCMJAVA toolkit is proposed to detect inconsistencies among viewpoints. This systematic approach uses three basic operations (UNION, DIFFERENCE, INTERSECTION) to study the static behaviors of graphic and tabular notations. From these operations, subgraphs Query, Selection, Merge, Replacement operations can be derived. This approach uses graph PRODUCTIONS (rewriting rules) to study the dynamic transformations of graphs. We discuss the feasibility of implementation these operations. Also, We present the process of porting original TCM (Toolkit for Conceptual Modeling) project from C++ to Java programming language in this thesis. A scenario based on NASA International Space Station Specification is discussed to show the applicability of our approach. Finally, conclusion and future work about inconsistency management issues in WHERE project will be summarized.

Zhang, Zhong↗

NASA NTRS1998

Electrical Bonding: A Survey of Requirement, Methods, and Specifications

This document provides information helpful to engineers imposing electrical bonding requirements, reviewing waiver requests, or modifying specifications on various space programs. Electrical bonding specifications and some of the processes used in the United States have been reviewed. This document discusses the specifications, the types of bonds, the intent of each, and the basic requirements where possible. Additional topics discussed are resistance versus impedance, bond straps, corrosion, finishes, and special applications.

Evans, R. W.↗

NASA NTRS1982

Handling Qualities Specifications for U.S. Military Helicopters

Inadequacies in the military specification for helicopter handling qualities, MIL-H-8501A, have long been recognized, and the latest procurements by the U.S. Army used special Prime Item Development Specifications (PIDS). This paper assesses the efficacy of these PIDS and suggests that changes should be made. In particular, the structure developed in MIL-F-8785B (ASG) (the specification for flying qualities of piloted airplanes) should be incorporated. Improved requirements must be based on a systematic data base and concentrated on topics most important in preliminary design: static and dynamic stability, control power and sensitivity, and interaction with controllers and displays. Emphasis should be on current military helicopter missions and helicopter idiosyncrasies such as cross-coupling, nonlinearities, and higher-order dynamics.

Key, David L.↗

NASA NTRS1999

A Methodology for Writing High Quality Requirement Specifications and for Evaluating Existing Ones

Requirements development and management have always been critical in the implementation of software systems-engineers are unable to build what analysts can not define. It is generally accepted that the earlier in the life cycle potential risks are identified the easier it is to eliminate or manage the conditions that introduce that risk. Problems that are not found until testing are approximately 14 times more costly to fix than if the problem was found in the requirement phase. The requirements specification, as the first tangible representation of the capability to be produced, establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor it can give rise to risks in all areas of the project. Recently, automated tools have become available to support requirements management. The use of these tools not only provides support in the definition and tracing of requirements, but it also opens the door to effective use of metrics in characterizing and assessing the quality of the requirement specifications.

Rosenberg, Linda↗

NASA NTRS1999

A Methodology for Writing High Quality Requirements Specification and Evaluating Existing Ones

Requirements development and management have always been critical in the implementation of software systems; engineers are unable to build what analysts can't define. It is generally accepted that the earlier in the life cycle potential risks are identified the easier it is to eliminate or manage the conditions that introduce that risk. Problems that are not found until testing are approximately 14 times more costly to fix than if the problem was found in the requirement phase. The requirements specification, as the first tangible representation of the capability to be produced, establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor it can give rise to risks in all areas of the project. Recently, automated tools have become available to support requirements management. The use of these tools not only provides support in the definition and tracing of requirements, but it also opens the door to effective use of metrics in characterizing and assessing the quality of the requirement specifications.

Rosenberg, Linda↗

NASA NTRS1999

Context-Specific Adaptation of Gravity-Dependent Vestibular Reflex Responses (NSBRI Neurovestibular Project 1)

Impairment of gaze and head stabilization reflexes can lead to disorientation and reduced performance in sensorimotor tasks such as piloting of spacecraft. Transitions between different gravitoinertial force (gif) environments - as during different phases of space flight - provide an extreme test of the adaptive capabilities of these mechanisms. We wish to determine to what extent the sensorimotor skills acquired in one gravity environment will transfer to others, and to what extent gravity serves as a context cue for inhibiting such transfer. We use the general approach of adapting a response (saccades, vestibuloocular reflex: VOR, or vestibulocollic reflex: VCR) to a particular change in gain or phase in one gif condition, adapting to a different gain or phase in a second gif condition, and then seeing if gif itself - the context cue - can recall the previously-learned adapted responses. Previous evidence indicates that unless there is specific training to induce context-specificity, reflex adaptation is sequential rather than simultaneous. Various experiments in this project investigate the behavioral properties, neurophysiological basis, and anatomical substrate of context-specific learning, using otolith (gravity) signals as a context cue. In the following, we outline the methods for all experiments in this project, and provide details and results on selected experiments.

Shelhamer, Mark↗