Engineering Papers⌕ Search

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.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS1991

Automatic derivation of formal software specifications from informal descriptions

SPECIFIER, an interactive system which derives formal specifications of data types and programs from their informal descriptions, is described. The process of deriving formal specifications is viewed as a problem-solving process. The system uses common problem-solving techniques such as schemas, analogy, and difference-based reasoning to derive formal specifications. If an informal description is a commonly occurring operation for which the system has a schema, then the formal specification is derived by instantiating the schema. If there is no such schema, SPECIFIER tries to find a previously solved problem which is analogous to the current problem. If the problem found is directly analogous to the current problem, it applies an analogy mapping to obtain a formal specification. On the other hand, if the analogy found is only approximate, it solves the directly analogous part of the problem by analogy and performs difference-based reasoning using the remaining (unmatched) parts to transform the formal specification obtained by analogy to a formal specification for the entire original problem.

Miriyala, Kanth↗
NASA NTRS1993

ARIES: Acquisition of Requirements and Incremental Evolution of Specifications

This paper describes a requirements/specification environment specifically designed for large-scale software systems. This environment is called ARIES (Acquisition of Requirements and Incremental Evolution of Specifications). ARIES provides assistance to requirements analysts for developing operational specifications of systems. This development begins with the acquisition of informal system requirements. The requirements are then formalized and gradually elaborated (transformed) into formal and complete specifications. ARIES provides guidance to the user in validating formal requirements by translating them into natural language representations and graphical diagrams. ARIES also provides ways of analyzing the specification to ensure that it is correct, e.g., testing the specification against a running simulation of the system to be built. Another important ARIES feature, especially when developing large systems, is the sharing and reuse of requirements knowledge. This leads to much less duplication of effort. ARIES combines all of its features in a single environment that makes the process of capturing a formal specification quicker and easier.

Roberts, Nancy A.↗
NASA NTRS1993

Towards the formal specification of the requirements and design of a processor interface unit: HOL listings

This technical report contains the HOL listings of the specification of the design and major portions of the requirements for a commercially developed processor interface unit (or PIU). The PIU is an interface chip performing memory interface, bus interface, and additional support services for a commercial microprocessor within a fault-tolerant computer system. This system, the Fault-Tolerant Embedded Processor (FTEP), is targeted towards applications in avionics and space requiring extremely high levels of mission reliability, extended maintenance-free operation, or both. This report contains the actual HOL listings of the PIU specification as it currently exists. Section two of this report contains general-purpose HOL theories that support the PIU specification. These theories include definitions for the hardware components used in the PIU, our implementation of bit words, and our implementation of temporal logic. Section three contains the HOL listings for the PIU design specification. Aside from the PIU internal bus (I-Bus), this specification is complete. Section four contains the HOL listings for a major portion of the PIU requirements specification. Specifically, it contains most of the definition for the PIU behavior associated with memory accesses initiated by the local processor.

Fura, David A.↗
NASA NTRS2009

System and method for deriving a process-based specification

A system and method for deriving a process-based specification for a system is disclosed. The process-based specification is mathematically inferred from a trace-based specification. The trace-based specification is derived from a non-empty set of traces or natural language scenarios. The process-based specification is mathematically equivalent to the trace-based specification. Code is generated, if applicable, from the process-based specification. A process, or phases of a process, using the features disclosed can be reversed and repeated to allow for an interactive development and modification of legacy systems. The process is applicable to any class of system, including, but not limited to, biological and physical systems, electrical and electro-mechanical systems in addition to software, hardware and hybrid hardware-software systems.

Hinchey, Michael Gerard↗
NASA NTRS1972

Social impact evaluation : Some implications of the specific decisional context approach for anticipatory project assessment with special reference to available alternatives and to techniques of evaluating the social impacts of the anticipated effects of such alternatives

The implications are explored of the specific decision context approach to anticipatory project assessment. More specifically, it is hypothesized that with respect to any given effect of a proposed project or action (mobility, job opportunities, air pollution, population distribution, etc.) such effect will likely differ in probability and/or magnitude from one decisional context to another; that the social desirability or undesirability of a given effect is a function (will differ with) each specific decisional context; that therefore the social impact of such effect will in all likelihood differ with each specific decisional context; and that the social significance of even the dame social impact of a given effect will vary from one decisional context to another when such social impact interacts with (competes with or reinforces) the social impacts of other effects. It also follows from this analysis that the respective roles of scientific method (demonstrable data) and adversarial system will not only differ with each specific decisional context but with each alternative course of action available to the decisional entity in each specific context.

Mayo, L. H.↗
NASA NTRS1983

The Hierarchical Specification and Mechanical Verification of the SIFT Design

The formal specification and proof methodology employed to demonstrate that the SIFT computer system meets its requirements are described. The hierarchy of design specifications is shown, from very abstract descriptions of system function down to the implementation. The most abstract design specifications are simple and easy to understand, almost all details of the realization were abstracted out, and are used to ensure that the system functions reliably and as intended. A succession of lower level specifications refines these specifications into more detailed, and more complex, views of the system design, culminating in the Pascal implementation. The section describes the rigorous mechanical proof that the abstract specifications are satisfied by the actual implementation.

Source record↗
NASA NTRS1991

Report on the formal specification and partial verification of the VIPER microprocessor

The VIPER microprocessor chip is partitioned into four levels of abstractions. At the highest level, VIPER is described with decreasingly abstract sets of functions in LCF-LSM. At the lowest level are the gate-level models in proprietary CAD languages. The block-level and gate-level specifications are also given in the ELLA simulation language. Among VIPER's deficiencies are the fact that there is no notion of external events in the top-level specification, and it is impossible to use the top-level specifications to prove abstract properties of programs running on VIPER computers. There is no complete proof that the gate-level specifications implement the top-level specifications. Cohn's proof that the major-state machine correctly implements the top-level specifications has no formal connection with any of the other proof attempts. None of the latter address resetting the machine, memory timeout, forced error, or single step modes.

Brock, Bishop↗
NASA NTRS2012

mREST Interface Specification

mREST is an implementation of the REST architecture specific to the management and sharing of data in a system of logical elements. The purpose of this document is to clearly define the mREST interface protocol. The interface protocol covers all of the interaction between mREST clients and mREST servers. System-level requirements are not specifically addressed. In an mREST system, there are typically some backend interfaces between a Logical System Element (LSE) and the associated hardware/software system. For example, a network camera LSE would have a backend interface to the camera itself. These interfaces are specific to each type of LSE and are not covered in this document. There are also frontend interfaces that may exist in certain mREST manager applications. For example, an electronic procedure execution application may have a specialized interface for configuring the procedures. This interface would be application specific and outside of this document scope. mREST is intended to be a generic protocol which can be used in a wide variety of applications. A few scenarios are discussed to provide additional clarity but, in general, application-specific implementations of mREST are not specifically addressed. In short, this document is intended to provide all of the information necessary for an application developer to create mREST interface agents. This includes both mREST clients (mREST manager applications) and mREST servers (logical system elements, or LSEs).

McCartney, Patrick↗
NASA NTRS1973

NASIS data base management system: IBM 360 TSS implementation. Volume 4: Program design specifications

The design specifications for the programs and modules within the NASA Aerospace Safety Information System (NASIS) are presented. The purpose of the design specifications is to standardize the preparation of the specifications and to guide the program design. Each major functional module within the system is a separate entity for documentation purposes. The design specifications contain a description of, and specifications for, all detail processing which occurs in the module. Sub-models, reference tables, and data sets which are common to several modules are documented separately.

Source record↗
NASA NTRS1973

NASIS data base management system - IBM 360/370 OS MVT implementation. 4: Program design specifications

The design specifications for the programs and modules within the NASA Aerospace Safety Information System (NASIS) are presented. The purpose of the design specifications is to standardize the preparation of the specifications and to guide the program design. Each major functional module within the system is a separate entity for documentation purposes. The design specifications contain a description of, and specifications for, all detail processing which occurs in the module. Sub-modules, reference tables, and data sets which are common to several modules are documented separately.

Source record↗
NASA NTRS1980

NASA Broad-Specification Fuels Combustion Technology Program - Status and description

The use of 'broad-specification' fuels in aircraft gas turbine engines can be a significant factor in offsetting anticipated shortages of current-specification jet fuel in the latter part of the century. The changes in fuel properties accompanying the use of broad-specification fuels will tend to cause numerous emissions, performance, and durability problems in currently-designed combustion systems. The NASA Broad-Specification Fuels Combustion Technology Program is a contracted effort to evolve and demonstrate the technology required to utilize broad-specification fuels in current and next generation commercial Conventional Takeoff and Landing (CTOL) aircraft engines, and to verify this technology in full-scale engine tests in 1983. The program consists of three phases: Combustor Concept Screening, Combustor Optimization Testing, and Engine Verification Testing.

Fear, J. S.↗
NASA NTRS1981

Hierarchical specification of the SIFT fault tolerant flight control system

The specification and mechanical verification of the Software Implemented Fault Tolerance (SIFT) flight control system is described. The methodology employed in the verification effort is discussed, and a description of the hierarchical models of the SIFT system is given. To meet the objective of NASA for the reliability of safety critical flight control systems, the SIFT computer must achieve a reliability well beyond the levels at which reliability can be actually measured. The methodology employed to demonstrate rigorously that the SIFT computer meets as reliability requirements is described. The hierarchy of design specifications from very abstract descriptions of system function down to the actual implementation is explained. The most abstract design specifications can be used to verify that the system functions correctly and with the desired reliability since almost all details of the realization were abstracted out. A succession of lower level models refine these specifications to the level of the actual implementation, and can be used to demonstrate that the implementation has the properties claimed of the abstract design specifications.

Melliar-Smith, P. M.↗
NASA NTRS1983

An error-specific approach to testing

The main objective of software testing in the software development life cycle is to verify conformance of the implemented software with its intended requirements. Such requirements include system requirements, and programming requirements. Non-conformance with such requirements causes what are known as software errors. Specifying an appropriate testing strategy to expose software errors is still an art. Traditional approaches do succeed in revealing many errrors but none is powerful enough to expose all errors. The best that is hoped for is to use a specific test strategy to expose a specific error type in specific program locations. This limitation is exploited to develop a new approach to software testing which is called an error-specific testing (EST) strategy. Error specific testing is in fact a dual to the traditional testing approaches.

Valdes, P. M.↗
NASA NTRS1987

Military specifications

The current situation relative to the military specification is that there is not one specific model of turbulence which people are using. Particular disagreement exists on how turbulence levels will vary with qualitative analysis. It does not tie one down to specifics. When it comes to flying quality specifications, many feel that one should stay with the definitions of the Cooper-Harper rating scale but allow the levels to shift depending on the level of turbulence. There is a ride quality specification in the MIL-SPEC having to do with flight control systems design that is related to a turbulence model. This spec (MIL-F8785C) and others are discussed.

Reynolds, Philip↗
NASA NTRS1991

Structured representation for requirements and specifications

This document was generated in support of NASA contract NAS1-18586, Design and Validation of Digital Flight Control Systems suitable for Fly-By-Wire Applications, Task Assignment 2. Task 2 is associated with a formal representation of requirements and specifications. In particular, this document contains results associated with the development of a Wide-Spectrum Requirements Specification Language (WSRSL) that can be used to express system requirements and specifications in both stylized and formal forms. Included with this development are prototype tools to support the specification language. In addition a preliminary requirements specification methodology based on the WSRSL has been developed. Lastly, the methodology has been applied to an Advanced Subsonic Civil Transport Flight Control System.

Cohen, Gerald C.↗
NASA NTRS1990

Effect of formal specifications on program complexity and reliability: An experimental study

The results are presented of an experimental study undertaken to assess the improvement in program quality by using formal specifications. Specifications in the Z notation were developed for a simple but realistic antimissile system. These specifications were then used to develop 2 versions in C by 2 programmers. Another set of 3 versions in Ada were independently developed from informal specifications in English. A comparison of the reliability and complexity of the resulting programs suggests the advantages of using formal specifications in terms of number of errors detected and fault avoidance.

Goel, Amrit L.↗
NASA NTRS1992

Requirements Specification Language (RSL) and supporting tools

This document describes a general purpose Requirement Specification Language (RSL). RSL is a hybrid of features found in several popular requirement specification languages. The purpose of RSL is to describe precisely the external structure of a system comprised of hardware, software, and human processing elements. To overcome the deficiencies of informal specification languages, RSL includes facilities for mathematical specification. Two RSL interface tools are described. The Browser view contains a complete document with all details of the objects and operations. The Dataflow view is a specialized, operation-centered depiction of a specification that shows how specified operations relate in terms of inputs and outputs.

Frincke, Deborah↗
NASA NTRS1993

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

This report describes 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, such as SADT (Structured Analysis and Design Technique), PSL (Problem Statement Language), and RMF (Requirements Modeling Framework). While languages such as these have useful features for structuring a specification, they generally lack formality. To overcome the deficiencies of informal requirements languages, RSL has constructs for formal mathematical specification. These constructs are similar to those found in formal specification languages such as EHDM (Enhanced Hierarchical Development Methodology), Larch, and OBJ3.

Fisher, Gene L.↗