Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Reliability 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 361 records · Page 20
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Thermal Cycle Reliability of PBGA/CCGA 717 I/Os

Status of thermal cycle test results for a nonfunctional daisy-chained peripheral ceramic column grid array (CCGA) and its plastic ball grid array (PBGA) version. both having 560 I/Os. were presented in last year's conference. Test results included environmental data for three different thermal cycle regimes (-55 C/125 C, -55 C/100 C, and -50 C /75 C). Update information on these - especially failure type for assemblies with high and low solder volumes-were presented. The thermal cycle test procedure followed those recommended IPC-9701 for tin-lead solder joint assemblies. Revision A of this specification covers guideline thermal cycle requirements for Pb-free solder joints. Some background information discussed during release of this specification with its current guideline recommendations were also presented. In a recent reliability investigation a fully populated CCGA with 717 I/Os was also considered for assembly reliability. evaluation. The functional package is a field-programmable gate array that has much higher processing power than its previous version. This new package is smaller in dimension, has no interposer, and has a thinner column wrapped with copper for reliability improvement. This paper will also present thermal cycle test results for this package assembly and its plastic version with 728 I/Os. both of which were exposed to three different cycle regimes. Two cycle profiles were those specified by IPC- 9701A for tin-lead, i.e. -55 to 100 C and -55 to 125 C and one was a cycle profile specified by Mil-Std-883, i.e.. -65 C/150 C which is generally used for ceramic hybrid packages. Per IPC-9701 A, test vehicles were built using daisy chain packages and were continuously monitored. The effects of many process and assembly variables-including corner staking commonly used for improving resistance to mechanical loading such as drop and vibration loads--were also considered as part of the test matrix. Optical photomicrographs were taken at various thermal cycle intervals to document damage progress and behavior. Representative samples of these along with cross-sectional photomicrographs at higher magnification taken by scanning electron microscopy (SEM) to determine crack propagation and failure analyses for packages are also presented.

staking↗
NASA NTRSDate not supplied

Common Cause Failures Dominate and Defeat Redundancy

Common cause failures occur when several malfunctions are produced by a single event or process. They are especially damaging when they eliminate an entire set of redundant systems and disable their intended function. Redundancy is used when the individual system failure probability is unacceptably high. Redundancy can improve the overall system failure probability if the failures are independent, but the reliability gain is limited if there are dependent failures having a common cause. No amount of redundancy can reduce the total failure probability below the common cause failure probability. Common cause failures defeat redundancy. Systems with high reliability requirements often use extensive redundancy. These highly redundant systems rarely fail unless all the redundant components providing a particular function fail. Complete failures of such highly redundant systems are then usually common cause failures. Common cause failures are prevalent in highly redundant, high reliability systems. Common cause failures dominate redundancy. Redundant systems may fail due to specification, design, manufacturing, operations, or maintenance problems that disable all the identical redundant systems. Common cause failures typically account for one tenth of all failures. If the failure probability is relatively low and common cause failures are significant, adding more than two or three redundant identical units usually gives little added reliability improvement. Common cause failures can be reduced by using diverse components with different technologies and manufacturers, by separating and shielding subsystems, and by avoiding shared control, power, or location. External events and shared vulnerabilities may still cause common cause failures.

common cause failures↗
NASA NTRSDate not supplied

Common Cause Failures Dominate and Defeat Redundancy

Common cause failures occur when several malfunctions are produced by a single event or process. They are especially damaging when they eliminate an entire set of redundant systems and disable their intended function. Redundancy is used when the individual system failure probability is unacceptably high. Redundancy can improve the overall system failure probability if the failures are independent, but the reliability gain is limited if there are dependent failures having a common cause. No amount of redundancy can reduce the total failure probability below the common cause failure probability. Common cause failures defeat redundancy. Systems with high reliability requirements often use extensive redundancy. These highly redundant systems rarely fail unless all the redundant components providing a particular function fail. Complete failures of such highly redundant systems are then usually common cause failures. Common cause failures are prevalent in highly redundant, high reliability systems. Common cause failures dominate redundancy. Redundant systems may fail due to specification, design, manufacturing, operations, or maintenance problems that disable all the identical redundant systems. Common cause failures typically account for one tenth of all failures. If the failure probability is relatively low and common cause failures are significant, adding more than two or three redundant identical units usually gives little added reliability improvement. Common cause failures can be reduced by using diverse components with different technologies and manufacturers, by separating and shielding subsystems, and by avoiding shared control, power, or location. External events and shared vulnerabilities may still cause common cause failures.

common cause failures↗
NASA NTRS1990

A highly reliable, autonomous data communication subsystem for an advanced information processing system

The need to meet the stringent performance and reliability requirements of advanced avionics systems has frequently led to implementations which are tailored to a specific application and are therefore difficult to modify or extend. Furthermore, many integrated flight critical systems are input/output intensive. By using a design methodology which customizes the input/output mechanism for each new application, the cost of implementing new systems becomes prohibitively expensive. One solution to this dilemma is to design computer systems and input/output subsystems which are general purpose, but which can be easily configured to support the needs of a specific application. The Advanced Information Processing System (AIPS), currently under development has these characteristics. The design and implementation of the prototype I/O communication system for AIPS is described. AIPS addresses reliability issues related to data communications by the use of reconfigurable I/O networks. When a fault or damage event occurs, communication is restored to functioning parts of the network and the failed or damage components are isolated. Performance issues are addressed by using a parallelized computer architecture which decouples Input/Output (I/O) redundancy management and I/O processing from the computational stream of an application. The autonomous nature of the system derives from the highly automated and independent manner in which I/O transactions are conducted for the application as well as from the fact that the hardware redundancy management is entirely transparent to the application.

Nagle, Gail↗
NASA NTRS2011

Estimating the Loss of Crew and Loss of Mission for Crew Spacecraft

Once the US Space Shuttle retires in 2011, the Russian Soyuz Launcher and Soyuz Spacecraft will comprise the only means for crew transportation to and from the International Space Station (ISS). The U.S. Government and NASA have contracted for crew transportation services to the ISS with Russia. The resulting implications for the US space program including issues such as astronaut safety must be carefully considered. Are the astronauts and cosmonauts safer on the Soyuz than the Space Shuttle system? Is the Soyuz launch system more robust than the Space Shuttle? The Soyuz launcher has been in operation for over 40 years. There have been only two loss of life incidents and two loss of mission incidents. Given that the most recent incident took place in 1983, how do we determine current reliability of the system? Do failures of unmanned Soyuz rockets impact the reliability of the currently operational man-rated launcher? Does the Soyuz exhibit characteristics that demonstrate reliability growth and how would that be reflected in future estimates of success? NASA s next manned rocket and spacecraft development project will have to meet the Agency Threshold requirements set forth by NASA. The reliability targets are currently several times higher than the Shuttle and possibly even the Soyuz. Can these targets be compared to the reliability of the Soyuz to determine whether they are realistic and achievable? To help answer these questions this paper will explore how to estimate the reliability of the Soyuz Launcher/Spacecraft system, compare it to the Space Shuttle, and its potential impacts for the future of manned spaceflight. Specifically it will look at estimating the Loss of Crew (LOC) and Loss of Mission (LOM) probability using historical data, reliability growth, and Probabilistic Risk Assessment techniques used to generate these numbers.

Lutomski, Michael G.↗
NASA NTRS1974

Sequential cumulative fatigue reliability

A component is assumed to be subjected to a sequence of several groups of sinusoidal stresses. Each group consists of a specific number of cycles having the same maximum alternating stress level and the same mean stress level, the maximum alternating stress level being different from group to group. A method for predicting the reliability of components subjected to such loads is proposed, given their distributional alternating stress versus cycles-to-failure (S-N) diagram. It is called the 'conditional reliability-equivalent life' method. It is applied to four-cases using distributional fatigue data generated in the Reliability Research Laboratory of The University of Arizona, and the predicted reliabilities are compared and discussed.

Kececioglu, D.↗
NASA NTRS2024

Forced Response Aeromechanics Analysis in MATLAB®-Based Environment Code With Application to Distortion-Tolerant Fan R24 Blade Geometry

Researchers at the NASA Glenn Research Center have developed a research-level code for forced response analysis for turbomachinery that provides a streamlined framework for aeromechanics analysis, as well as for generating Goodman diagrams. The Forced Response Aeromechanics Analysis in a MATLAB-Based Environment (FRAAME, Version 1) code is designed to accept blade surface unsteady pressure time histories generated by three-dimensional (3D) Unsteady Reynolds-Averaged Navier-Stokes (URANS) code TURBO and modal displacements, modal stresses, and static stresses generated via expanded ANSYS® (Ansys, Inc.) cyclic symmetry analysis. The code’s looping structure allows for largescale analyses, including many blade surface pressure files, modal displacements, and modal stress files for full annulus forced response analysis, including a modal summation method for multiple engine orders and modes. This code is applied to the R24 fan geometry for the Boundary Layer Ingesting Inlet/Distortion-Tolerant Fan (BLI2DTF) project, a propulsion system being developed to increase the fuel efficiency of future aircraft, to serve as validation of experimental data as well as external simulation results. This tool’s functional, modular form is intended to allow users to make modifications easily. Those modifications can include requests for information for any step in the analysis process, as well as adding various functions to compute additional information of interest. It is also written, given sufficient input information, as a general blade geometry forced response solver that is not necessarily specific to the R24 geometry but is used here for verification of code functionality and accuracy. Although forced response analysis tools are also available in commercially available code packages, the post-processing FRAAME code offers reliable, fast, and scalable forced response analysis and Goodman diagram generation for large cases utilizing, specifically, TURBO and ANSYS® results information in an effort to streamline forced response and high cycle fatigue analyses.

Aeromechanics↗
NASA NTRS2004

Toward Synthesis, Analysis, and Certification of Security Protocols

Implemented security protocols are basically pieces of software which are used to (a) authenticate the other communication partners, (b) establish a secure communication channel between them (using insecure communication media), and (c) transfer data between the communication partners in such a way that these data only available to the desired receiver, but not to anyone else. Such an implementation usually consists of the following components: the protocol-engine, which controls in which sequence the messages of the protocol are sent over the network, and which controls the assembly/disassembly and processing (e.g., decryption) of the data. the cryptographic routines to actually encrypt or decrypt the data (using given keys), and t,he interface to the operating system and to the application. For a correct working of such a security protocol, all of these components must work flawlessly. Many formal-methods based techniques for the analysis of a security protocols have been developed. They range from using specific logics (e.g.: BAN-logic [4], or higher order logics [12] to model checking [2] approaches. In each approach, the analysis tries to prove that no (or at least not a modeled intruder) can get access to secret data. Otherwise, a scenario illustrating the &tack may be produced. Despite the seeming simplicity of security protocols ("only" a few messages are sent between the protocol partners in order to ensure a secure communication), many flaws have been detected. Unfortunately, even a perfect protocol engine does not guarantee flawless working of a security protocol, as incidents show. Many break-ins and security vulnerabilities are caused by exploiting errors in the implementation of the protocol engine or the underlying operating system. Attacks using buffer-overflows are a very common class of such attacks. Errors in the implementation of exception or error handling can open up additional vulnerabilities. For example, on a website with a log-in screen: multiple tries with invalid passwords caused the expected error message (too many retries). but let the user nevertheless pass. Finally, security can be compromised by silly implementation bugs or design decisions. In a commercial VPN software, all calls to the encryption routines were incidentally replaced by stubs, probably during factory testing. The product worked nicely. and the error (an open VPN) would have gone undetected, if a team member had not inspected the low-level traffic out of curiosity. Also, the use secret proprietary encryption routines can backfire, because such algorithms often exhibit weaknesses which can be exploited easily (see e.g., DVD encoding). Summarizing, there is large number of possibilities to make errors which can compromise the security of a protocol. In today s world with short time-to-market and the use of security protocols in open and hostile networks for safety-critical applications (e.g., power or air-traffic control), such slips could lead to catastrophic situations. Thus, formal methods and automatic reasoning techniques should not be used just for the formal proof of absence of an attack, but they ought to be used to provide an end-to-end tool-supported framework for security software. With such an approach all required artifacts (code, documentation, test cases) , formal analyses, and reliable certification will be generated automatically, given a single, high level specification. By a combination of program synthesis, formal protocol analysis, certification; and proof-carrying code, this goal is within practical reach, since all the important technologies for such an approach actually exist and only need to be assembled in the right way.

Schumann, Johann↗
NASA NTRSDate not supplied

Impact of Latency and Reliability on Separation Assurance with Remotely Piloted Aircraft in Terminal Operations

Remotely Piloted Aircraft (RPA) for cargo operations in the national airspace system will impact safety due to, among other factors, the latency and reliability of command & control, and of communication. This paper investigates the safety impact with increasing mix of RPA amidst manned traffic in a generic arrival pattern with three merging flows. Latency was modelled as the response time between air traffic control's determination of a resolution and the RPAs' initiation of the maneuver. Reliability was modelled as a message drop probability. The experiment was repeated with two different aircraft types having different performance characteristics as representatives of RPA for conducting automated cargo operations. Overall response time above thirty seconds and message drop probability over twenty percent caused losses of separation. Specific results depended on the RPA aircraft type. The detailed impacts of latency and reliability with increasing mix of RPA traffic are provided. Applications of the approach for further studies at increasing levels of automation are also discussed.

Vishwanath Bulusu↗
NASA NTRS2022

Impact of Latency and Reliability on Separation Assurance with Remotely Piloted Aircraft in Terminal Operations

Remotely Piloted Aircraft (RPA) for cargo operations in the national airspace system will impact safety due to, among other factors, the latency and reliability of command & control, and of communication. This paper investigates the safety impact with increasing mix of RPA amidst manned traffic in a generic arrival pattern with three merging flows. Latency was modelled as the response time between air traffic control's determination of a resolution and the RPAs' initiation of the maneuver. Reliability was modelled as a message drop probability. The experiment was repeated with two different aircraft types having different performance characteristics as representatives of RPA for conducting automated cargo operations. Overall response time above thirty seconds and message drop probability over twenty percent caused losses of separation. Specific results depended on the RPA aircraft type. The detailed impacts of latency and reliability with increasing mix of RPA traffic are provided. Applications of the approach for further studies at increasing levels of automation are also discussed.

Vishwanath Bulusu↗
NASA NTRS1990

Reliability analysis in intelligent machines

Given an explicit task to be executed, an intelligent machine must be able to find the probability of success, or reliability, of alternative control and sensing strategies. By using concepts for information theory and reliability theory, new techniques for finding the reliability corresponding to alternative subsets of control and sensing strategies are proposed such that a desired set of specifications can be satisfied. The analysis is straightforward, provided that a set of Gaussian random state variables is available. An example problem illustrates the technique, and general reliability results are presented for visual servoing with a computed torque-control algorithm. Moreover, the example illustrates the principle of increasing precision with decreasing intelligence at the execution level of an intelligent machine.

Mcinroy, John E.↗
NASA NTRS1998

Composing, Analyzing and Validating Software Models

This research has been conducted at the Computational Sciences Division of the Information Sciences Directorate at Ames Research Center (Automated Software Engineering Grp). The principle work this summer has been to review and refine the agenda that were carried forward from last summer. Formal specifications provide good support for designing a functionally correct system, however they are weak at incorporating non-functional performance requirements (like reliability). Techniques which utilize stochastic Petri nets (SPNs) are good for evaluating the performance and reliability for a system, but they may be too abstract and cumbersome from the stand point of specifying and evaluating functional behavior. Therefore, one major objective of this research is to provide an integrated approach to assist the user in specifying both functionality (qualitative: mutual exclusion and synchronization) and performance requirements (quantitative: reliability and execution deadlines). In this way, the merits of a powerful modeling technique for performability analysis (using SPNs) can be combined with a well-defined formal specification language. In doing so, we can come closer to providing a formal approach to designing a functionally correct system that meets reliability and performance goals.

Sheldon, Frederick T.↗
NASA NTRS1982

JPL preferred parts list: Reliable electronic components

The JPL Preferred Parts List was prepared to provide a basis for selection of electronic parts for JPL spacecraft programs. Supporting tests for the listed parts were designed to comply with specific spacecraft environmental requirements. The list tabulates the electronic, magnetic, and electromechanical parts applicable to all JPL electronic equipment wherein reliability is a major concern. The parts listed are revelant to equipment supplied by subcontractors as well as fabricated at the laboratory.

Covey, R. E.↗
NASA NTRS2003

CCSDS File Delivery Protocol (CFDP): Why it's Useful and How it Works

Reliable delivery of data products is often required across space links. For example, a NASA mission will require reliable delivery of images produced by an on-board detector. Many missions have their own (unique) way of accomplishing this, requiring custom software. Many missions also require manual operations (e.g. the telemetry receiver software keeps track of what data is missing, and a person manually inputs the appropriate commands to request retransmissions). The Consultative Committee for Space Data Systems (CCSDS) developed the CCSDS File Delivery Protocol (CFDP) specifically for this situation. CFDP is an international standard communication protocol that provides reliable delivery of data products. It is designed for use across space links. It will work well if run over the widely used CCSDS Telemetry and Telecommand protocols. However, it can be run over any protocol, and will work well as long as the underlying protocol delivers a reasonable portion of the data. The CFDP receiver will autonomously determine what data is missing, and request retransmissions as needed. The CFDP sender will autonomously perform the requested transmissions. When the entire data product is delivered, the CFDP receiver will let the CFDP sender know that the transaction has completed successfully. The result is that custom software becomes standard, and manual operations become autonomous. This paper will consider various ways of achieving reliable file delivery, explain why CFDP is the optimal choice for use over space links, explain how the core protocol works, and give some guidance on how to best utilize CFDP within various mission scenarios. It will also touch on additional features of CFDP, as well as other uses for CFDP (e.g. the loading of on-board memory and tables).

Ray, Tim↗
NASA NTRS2005

Comparison of Monthly Mean Cloud Fraction and Cloud Optical depth Determined from Surface Cloud Radar, TOVS, AVHRR, and MODIS over Barrow, Alaska

A one year comparison is made of mean monthly values of cloud fraction and cloud optical depth over Barrow, Alaska (71 deg 19.378 min North, 156 deg 36.934 min West) between 35 GHz radar-based retrievals, the TOVS Pathfinder Path-P product, the AVHRR APP-X product, and a MODIS based cloud retrieval product from the CERES-Team. The data sets represent largely disparate spatial and temporal scales, however, in this paper, the focus is to provide a preliminary analysis of how the mean monthly values derived from these different data sets compare, and determine how they can best be used separately, and in combination to provide reliable estimates of long-term trends of changing cloud properties. The radar and satellite data sets described here incorporate Arctic specific modifications that account for cloud detection challenges specific to the Arctic environment. The year 2000 was chosen for this initial comparison because the cloud radar data was particularly continuous and reliable that year, and all of the satellite retrievals of interest were also available for the year 2000. Cloud fraction was chosen as a comparison variable as accurate detection of cloud is the primary product that is necessary for any other cloud property retrievals. Cloud optical depth was additionally selected as it is likely the single cloud property that is most closely correlated to cloud influences on surface radiation budgets.

Uttal, Taneil↗
NASA NTRS1976

Heat pipes for spacecraft temperature control: An assessment of the state-of-the-art

Spacecraft applications that require the efficient cooling of high-powered components, the precise temperature control of sensitive electronic and optical components, and the protection of cooled components from temporary, adverse environmental conditions are increasing. Heat pipes using gas, vapor, liquid, or voltage control to provide variable conductance or diode thermal behavior have been and are continuing to be developed to meet increasingly difficult requirements. The various control techniques are critically evaluated using characteristic features and properties, including heat transport capability, volume and mass requirements, complexity and ease of fabrication, reliability, and control characteristics. As a result, advantages and disadvantages of specific approaches are derived and discussed. Using four development levels, the state-of-the-art of the various heat pipe temperature control techniques is assessed.

Groll, M.↗
NASA NTRS1978

Numerical aerodynamic simulation facility. Preliminary study extension. Executive summary

An optimized functional design of key elements of the Numerical Aerodynamic Simulation Facility was investigated. The following tasks were performed and are discussed: (1) develop, optimize, and describe the functional description of the custom hardware; (2) delineate trade-off areas between performance, reliability, availability, serviceability, and programmability; (3) develop metrics and models for validation of the candidate system's performance; (4) conduct a functional simulation of the system design; (5) perform a reliability analysis of the system design; and (6) develop the software specifications to include a user level high level programming language, a correspondence between the programming language and instruction set, and outline the operating system requirements.

Source record↗
NASA NTRS1979

Solar power satellite system definition study, volume 4, phase 2

Results of an overall evaluation of the solar power satellite concept are reported. Specific topics covered include: solid state sandwich configuration; parametric development of reliability design; power distribution system for solid state solar power satellites; multibeam transmission; GEO base system configuration; suppression of the heavy lift launch vehicle trajectory; conceptual design of an offshore space center facility; solar power satellite development and operations scenario; and microwave power transmission technology, advancement, development, and facility requirements.

Source record↗