Search NASA⌕ Search

SEARCH · Search NASA

Results for “Design Information Verification”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2008

J-2X Abort System Development

The J-2X is an expendable liquid hydrogen (LH2)/liquid oxygen (LOX) gas generator cycle rocket engine that is currently being designed as the primary upper stage propulsion element for the new NASA Ares vehicle family. The J-2X engine will contain abort logic that functions as an integral component of the Ares vehicle abort system. This system is responsible for detecting and responding to conditions indicative of impending Loss of Mission (LOM), Loss of Vehicle (LOV), and/or catastrophic Loss of Crew (LOC) failure events. As an earth orbit ascent phase engine, the J-2X is a high power density propulsion element with non-negligible risk of fast propagation rate failures that can quickly lead to LOM, LOV, and/or LOC events. Aggressive reliability requirements for manned Ares missions and the risk of fast propagating J-2X failures dictate the need for on-engine abort condition monitoring and autonomous response capability as well as traditional abort agents such as the vehicle computer, flight crew, and ground control not located on the engine. This paper describes the baseline J-2X abort subsystem concept of operations, as well as the development process for this subsystem. A strategy that leverages heritage system experience and responds to an evolving engine design as well as J-2X specific test data to support abort system development is described. The utilization of performance and failure simulation models to support abort system sensor selection, failure detectability and discrimination studies, decision threshold definition, and abort system performance verification and validation is outlined. The basis for abort false positive and false negative performance constraints is described. Development challenges associated with information shortfalls in the design cycle, abort condition coverage and response assessment, engine-vehicle interface definition, and abort system performance verification and validation are also discussed.

Santi, Louis M.↗
NASA NTRS1987

Space station System Engineering and Integration (SE and I). Volume 2: Study results

A summary of significant study results that are products of the Phase B conceptual design task are contained. Major elements are addressed. Study results applicable to each major element or area of design are summarized and included where appropriate. Areas addressed include: system engineering and integration; customer accommodations; test and program verification; product assurance; conceptual design; operations and planning; technical and management information system (TMIS); and advanced development.

Source record↗
NASA NTRS1993

Reactive system verification case study: Fault-tolerant transputer communication

A reactive program is one which engages in an ongoing interaction with its environment. A system which is controlled by an embedded reactive program is called a reactive system. Examples of reactive systems are aircraft flight management systems, bank automatic teller machine (ATM) networks, airline reservation systems, and computer operating systems. Reactive systems are often naturally modeled (for logical design purposes) as a composition of autonomous processes which progress concurrently and which communicate to share information and/or to coordinate activities. Formal (i.e., mathematical) frameworks for system verification are tools used to increase the users' confidence that a system design satisfies its specification. A framework for reactive system verification includes formal languages for system modeling and for behavior specification and decision procedures and/or proof-systems for verifying that the system model satisfies the system specifications. Using the Ostroff framework for reactive system verification, an approach to achieving fault-tolerant communication between transputers was shown to be effective. The key components of the design, the decoupler processes, may be viewed as discrete-event-controllers introduced to constrain system behavior such that system specifications are satisfied. The Ostroff framework was also effective. The expressiveness of the modeling language permitted construction of a faithful model of the transputer network. The relevant specifications were readily expressed in the specification language. The set of decision procedures provided was adequate to verify the specifications of interest. The need for improved support for system behavior visualization is emphasized.

Crane, D. Francis↗
NASA NTRS2012

A Design Rationale Capture Tool to Support Design Verification and Re-use

A design rationale tool (DR tool) was developed to capture design knowledge to support design verification and design knowledge re-use. The design rationale tool captures design drivers and requirements, and documents the design solution including: intent (why it is included in the overall design); features (why it is designed the way it is); information about how the design components support design drivers and requirements; and, design alternatives considered but rejected. For design verification purposes, the tool identifies how specific design requirements were met and instantiated within the final design, and which requirements have not been met. To support design re-use, the tool identifies which design decisions are affected when design drivers and requirements are modified. To validate the design tool, the design knowledge from the Taxiway Navigation and Situation Awareness (T-NASA; Foyle et al., 1996) system was captured and the DR tool was exercised to demonstrate its utility for validation and re-use.

design verification↗
NASA NTRS1974

Shuttle active thermal control system development testing. Volume 1: Overall summary

A summary is given of a series of thermal vacuum tests designed to support the development of the orbiter active thermal control system (ATCS) and included testing of a wide heat load range modular radiator system (MRS) configured to the March 1973 orbiter baseline system, a candidate weight reducing radiator/water cooling system, and a smaller radiator system with a high performance radiator coating. The tests verified the performance of the baseline system and obtained detailed design information for application of a wide heat load range modular radiator system to the orbiter. The two candidate ATCS weight reducing designs have undergone extensive concept verification testing and their system operating characteristics have been determined in sufficient detail for application to the orbiter. Design information has been obtained for an integrated radiator/water cooling system that provides for vehicle heat rejection as well as water management of the excess fuel cell water. Processing techniques have been developed and verified for the application of a high performance thermal control coating to large radiator areas subjected to a temperature range of -280 F to +160 F.

Howell, H. R.↗
NASA NTRS1983

ECUT: Energy Conversion and Utilization Technologies program. Heterogeneous catalysis modeling program concept

Insufficient theoretical definition of heterogeneous catalysts is the major difficulty confronting industrial suppliers who seek catalyst systems which are more active, selective, and stable than those currently available. In contrast, progress was made in tailoring homogeneous catalysts to specific reactions because more is known about the reaction intermediates promoted and/or stabilized by these catalysts during the course of reaction. However, modeling heterogeneous catalysts on a microscopic scale requires compiling and verifying complex information on reaction intermediates and pathways. This can be achieved by adapting homogeneous catalyzed reaction intermediate species, applying theoretical quantum chemistry and computer technology, and developing a better understanding of heterogeneous catalyst system environments. Research in microscopic reaction modeling is now at a stage where computer modeling, supported by physical experimental verification, could provide information about the dynamics of the reactions that will lead to designing supported catalysts with improved selectivity and stability.

Voecks, G. E.↗
NASA NTRS1981

Wind Turbine Dynamics

Recent progress in the analysis and prediction of the dynamic behavior of wind turbine generators is discussed. The following areas were addressed: (1) the adequacy of state of the art analysis tools for designing the next generation of wind power systems; (2) the use of state of the art analysis tools designers; and (3) verifications of theory which might be lacking or inadequate. Summaries of these informative discussions as well as the questions and answers which followed each paper are documented in the proceedings.

Thresher, R. W.↗
NASA NTRS1984

Definition of ground test for Large Space Structure (LSS) control verification

An overview for the definition of a ground test for the verification of Large Space Structure (LSS) control is given. The definition contains information on the description of the LSS ground verification experiment, the project management scheme, the design, development, fabrication and checkout of the subsystems, the systems engineering and integration, the hardware subsystems, the software, and a summary which includes future LSS ground test plans. Upon completion of these items, NASA/Marshall Space Flight Center will have an LSS ground test facility which will provide sufficient data on dynamics and control verification of LSS so that LSS flight system operations can be reasonably ensured.

Waites, H. B.↗
NASA NTRS2016

A Generic Modeling Process to Support Functional Fault Model Development

Functional fault models (FFMs) are qualitative representations of a system's failure space that are used to provide a diagnostic of the modeled system. An FFM simulates the failure effect propagation paths within a system between failure modes and observation points. These models contain a significant amount of information about the system including the design, operation and off nominal behavior. The development and verification of the models can be costly in both time and resources. In addition, models depicting similar components can be distinct, both in appearance and function, when created individually, because there are numerous ways of representing the failure space within each component. Generic application of FFMs has the advantages of software code reuse: reduction of time and resources in both development and verification, and a standard set of component models from which future system models can be generated with common appearance and diagnostic performance. This paper outlines the motivation to develop a generic modeling process for FFMs at the component level and the effort to implement that process through modeling conventions and a software tool. The implementation of this generic modeling process within a fault isolation demonstration for NASA's Advanced Ground System Maintenance (AGSM) Integrated Health Management (IHM) project is presented and the impact discussed.

Design Analysis↗
NASA NTRS2017

Crewed Space Vehicle Battery Safety Requirements Revision D

The Crewed Space Vehicle Battery Safety Requirements document has been prepared for use by designers of battery-powered vehicles, portable equipment, and experiments intended for crewed spaceflight. The purpose of the requirements document is to provide battery designers with information on design provisions to be incorporated in and around the battery and on the verification to be undertaken to demonstrate a safe battery is provided. The term "safe battery" means that the battery is safe for ground personnel and crew members to handle and use; safe to be used in the enclosed environment of a crewed space vehicle; and safe to be mounted or used in unpressurized spaces adjacent to habitable areas. Battery design review, approval, and certification is required before the batteries can be used for ground operations and be certified for flight.

Russell, Samuel↗
NASA NTRSDate not supplied

Power Quality Analysis for a High Voltage Power System for Urban Air Mobility Application

Maturation of electric power technologies has opened the door for deployment of new types of aircraft within urban air mobility (UAM) markets. These new types of aircraft use non-conventional designs, which do not fall within existing regulatory requirements; this is especially true for the design and verification of the high voltage primary power systems which are being proposed for many of these aircraft. The purpose of this paper is to investigate and inform integration requirements, mainly related to power quality, based on a point design of a NASA Lift-plus-Cruise Vehicle Electrical Power System (EPS) and Utilization Equipment (UE). The results will be used to inform normal and abnormal operating performance of the EPS and UE for future standards in regards to Power Quality.

Nuha S Nawash↗
NASA NTRS1991

NASA software documentation standard software engineering program

The NASA Software Documentation Standard (hereinafter referred to as Standard) can be applied to the documentation of all NASA software. This Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. This basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.

Source record↗
NASA NTRS1991

NASA Software Documentation Standard

The NASA Software Documentation Standard (hereinafter referred to as "Standard") is designed to support the documentation of all software developed for NASA; its goal is to provide a framework and model for recording the essential information needed throughout the development life cycle and maintenance of a software system. The NASA Software Documentation Standard can be applied to the documentation of all NASA software. The Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. The basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.

Source record↗
NASA NTRS2010

NASA Docking System (NDS) Users Guide: International Space Station Program. Type 4

The NASA Docking System (NDS) Users Guide provides an overview of the basic information needed to integrate the NDS onto a Host Vehicle (HV). This Users Guide is intended to provide a vehicle developer with a fundamental understanding of the NDS technical and operations information to support their program and engineering integration planning. The Users Guide identifies the NDS Specification, Interface Definition or Requirement Documents that contain the complete technical details and requirements that a vehicle developer must use to design, develop and verify their systems will interface with NDS. This Guide is an initial reference and must not be used as a design document. In the event of conflict between this Users Guide and other applicable interface definition or requirements documents; the applicable document will take precedence. This Users Guide is organized in three main sections. Chapter 1 provides an overview of the NDS and CDA hardware and the operations concepts for the NDS. Chapter 2 provides information for Host Vehicle Program integration with the NDS Project Office. Chapter 2 describes the NDS Project organization, integration and verification processes, user responsibilities, and specification and interface requirement documents. Chapter 3 provides a summary of basic technical information for the NDS design. Chapter 3 includes NDS hardware component descriptions, physical size and weight characteristics, and summary of the capabilities and constraints for the various NDS sub-systems.

Tabakman, Alexander↗
NASA NTRS2014

Spot: A Programming Language for Verified Flight Software

The C programming language is widely used for programming space flight software and other safety-critical real time systems. C, however, is far from ideal for this purpose: as is well known, it is both low-level and unsafe. This paper describes Spot, a language derived from C for programming space flight systems. Spot aims to maintain compatibility with existing C code while improving the language and supporting verification with the SPIN model checker. The major features of Spot include actor-based concurrency, distributed state with message passing and transactional updates, and annotations for testing and verification. Spot also supports domain-specific annotations for managing spacecraft state, e.g., communicating telemetry information to the ground. We describe the motivation and design rationale for Spot, give an overview of the design, provide examples of Spot's capabilities, and discuss the current status of the implementation.

validation↗
NASA NTRS2011

From Paper to Production to Test: An Update on NASA's J-2X Engine for Exploration

The NASA/industry team responsible for developing the J-2X upper stage engine for the Space Launch System (SLS) Program has made significant progress toward moving beyond the design phase and into production, assembly, and test of development hardware. The J-2X engine exemplifies the SLS Program goal of using proven technology and experience from more than 50 years of United States spaceflight experience combined with modern manufacturing processes and approaches. It will power the second stage of the fully evolved SLS Program launch vehicle that will enable a return to human exploration of space beyond low earth orbit. Pratt & Whitney Rocketdyne (PWR) is under contract to develop and produce the engine, leveraging its flight-proven LH2/LOX, gas generator cycle J-2 and RS-68 engine capabilities, recent experience with the X-33 aerospike XRS-2200 engine, and development knowledge of the J-2S tap-off cycle engine. The J- 2X employs a gas generator operating cycle designed to produce 294,000 pounds of vacuum thrust in primary operating mode with its full nozzle extension. With a truncated nozzle extension suitable to support engine clustering on the stage, the nominal vacuum thrust level in primary mode is 285,000 pounds. It also has a secondary mode, during which it operates at 80 percent thrust by altering its mixture ratio. The J-2X development philosophy is based on proven hardware, an aggressive development schedule, and early risk reduction. NASA Marshall Space Flight Center (MSFC) and PWR began development of the J-2X in June 2006. The government/industry team of more than 600 people within NASA and PWR successfully completed the Critical Design Review (CDR) in November 2008, following extensive risk mitigation testing. Assembly of the first development engine was completed in May 2011 and the first engine test was conducted at the NASA Stennis Space Center (SSC), test stand A2, on 14 July 2011. Testing of the first development engine will continue through the autumn of 2011, be paused for test stand modifications to the passive diffuser, and then restart in the spring of 2012. This testing will be followed by specialized powerpack testing intended to examine the design and operating margins of the engine turbomachinery. The development plan beyond this point leads through more system-level, engine testing of several samples, analytical model validation activities, functional and performance verification, and then ultimate certification to support human spaceflight. This paper will discuss the J-2X development background, provide top-level information on design and development planning, and will explore some of the development challenges and mitigation activities pursued to date.

Kynard, Michael↗
NASA NTRS2008

Guidance and Control Software Project Data - Volume 2: Development Documents

The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes the development documents from the GCS project. Volume 2 contains three appendices: A. Guidance and Control Software Development Specification; B. Design Description for the Pluto Implementation of the Guidance and Control Software; and C. Source Code for the Pluto Implementation of the Guidance and Control Software

Hayhurst, Kelly J.↗
NASA NTRS1994

Cascaded clocks measurement and simulation findings

This paper will examine aspects related to network synchronization distribution and the cascading of timing elements. Methods of timing distribution have become a much debated topic in standards forums and among network service providers (both domestically and internationally). Essentially these concerns focus on the need to migrate their existing network synchronization plans (and capabilities) to those required for the next generation of transport technologies (namely, the Synchronous Digital Hierarchy (SDH), Synchronous Optical Networks (SONET), and Asynchronous Transfer Mode (ATM). The particular choices for synchronization distribution network architectures are now being evaluated and are demonstrating that they can indeed have a profound effect on the overall service performance levels that will be delivered to the customer. The salient aspects of these concerns reduce to the following: (1) identifying that the devil is in the details of the timing element specifications and the distribution of timing information (i.e., small design choices can have a large performance impact); (2) developing a standardized method of performance verification that will yield unambiguous results; and (3) presentation of those results. Specifically, this will be done for two general cases: an ideal input, and a noisy input to a cascaded chain of slave clocks.

Chislow, Don↗