Criteria

Text:
Sector:
Content:
Display:

Results

Viewing 1 to 30 of 349
2016-08-29
Standard
AIR1412C
This document lists those guidelines recognized as being essential for consideration by the designer who is preparing to select an elastomer as part of an aerospace design.
2016-08-01
Standard
ARP4868C
The SAE Aerospace Standard document AS681 is the parent document of this SAE Aerospace Recommended Practice (ARP). AS681 applies to Engine programs written to conform to this document. This ARP specifies a set of functions and their expected behaviors that constitute a function based Application Program Interface (API) for gas turbine engine customer programs. The functions specified in this API are delivered by the Supplier as part of the Engine model. This document defines generic language independent functions and specific appendices for implementations in C and Fortran. The function based API specified in this ARP represents an alternative to the Fortran COMMON block structure, as specified in AS4191, historically used to communicate with an engine program. The customer may request emulation of the AS4191 interface if desired.
2016-06-17
Standard
RB9
This Reliability Bulletin is provided as a guide for engineering and managment personnel concerned with Failure Mode and Effect Analyses (FMEA). In Addition, it provides information concerning technical and functional relationship of Failure Mode and Effect Analyses to associated disciplines, as for example, Maintainability, Safety, and System Effectiveness Analyses. This Bulletin covers requirements, concepts, interface, procedures and reports of FMEA. This Bulletin should contribute to greater utilization of FMEA results and to the understanding and appreciation of the purpose of FMEA on the part of engineering and management personnel.
2016-06-17
Standard
RB4A
A guide for the use by companies contracting for design of electronic products with the Department of Defense (DOD) and other government agencies. This Bulletin present concepts and techniques for quantifying electronic equipment reliability. The techniques are responsive to the requirements of various branches of the Department of Defense and are also useful with regard to other Government agencies (e.g., NASA).
2016-06-16
Standard
EIAEDIF1
The increase in the number of silicon foundries and CAD/CAE system and workstation companies, and the problem of movement of data among in-house design systems has made a standard interchange format for electronic design data essential. The benefits of the general adoption of a standard interchange format are important and far reaching. The customer receives a much wider variety of feasible choices, and free competition in both CAEYCAD system/tool businesses and foundry businesses is enhanced. The electronic circuit designer and customer of CAE/CAD system and foundry service can expect compatibility among these products. The designer can choose equipment and services best suited for a particular task with a minimum of overhead. Foundries can work with customers regardless of the CAE/CAD equipment that the customer is using.
2016-06-16
Standard
EIAEDIF2
This volume is the second in a series of monographs which will make the standard (ANSUEIA 548-1988) easier to understand. It is intended to be used as a companion to the EDIF Reference Manual Version 2.0.0, which is also published by the EL4 (ISBN 0-7908-0000-4). This volume gives an introduction to the concept of connectivity in the format. Concepts are explained in a general way; constructs, such as net, appear in italics throughout this volume. Whenever more detail is desired about a topic the italicized constructs should be consulted in the EDIF Reference Manual. The EDIF Reference Manual contains the official definition of the format and should always be taken as the authoritative source of information. Further application guides will be provided in later volumes of this series.
2016-06-16
Standard
EIAEDIFAG1
This document offers some conventions for the use of EDIF in transfer applications involving schematic designs. It discusses the use of EDIF 2 0 0 constructs that apply to the SCHEMATIC view. This document does not attempt to cover the use of EDIF for the transfer of all design aspects, It is intended to be a starting point for implementing EDIF schematic translators. It is not an EDIF user manual. It is not an amendment to the EDIF 2 O O Recommended Standard ANSIIEIA-548, which contains the official definition of the format and should always be taken as the authoritative source of EDIF information. This document assumes you are familiar with schematic capture systems but not familiar with EDIF. You will need to refer to EIA-548 for detailed definitions of some of the constructs discussed below.
2016-06-16
Standard
EQB4
This report on quantification of Essentiality (W) and Utilization (U) terms extends the scope of the basic expression for system effectiveness (Es = ADC) to include the additional "W" and "U" paramenters needed for the quantification of multi-functioned and multi-missioned systems. Methods and procedures for applying these terms to system effectiveness quantification are discussed and simple examples to demonstrate the principles of usage are included. The need to look at the system being quantified in terms of its level in the mission/function hierarchical tree is explained. The relationships between system elements (hardware, software, and personnel) and performance functions are discussed and illustrated with examples. Two methods for applying the "W"'and "U" weight factors, LOGIC AND (weak link model) and LOGIC OR (degraded operational modes model) are described and examples are shown for these cases.
2016-06-16
Standard
EQB3
The Electronic Industries Association (EIA) G-47 Effectiveness QuantificationCommittee has a basic task to quantify system effectiveness. Since the support parameters underly any prime parameter quantification, the topic of support system analysis is a fundamental one to this basic committee task. The charts contained in this bulletin were developed and used for presentations to aircraft support engineering groups, to comunicate the logic and scope of system analysis applied to support system optimization.
2016-06-16
Standard
EQB2
Program Managers have considered the subject of effectiveness quantification from three diverse points of view. The first viewpoint, in conjunction with the system effectiveness analyst, is to quantify everything and to consider everything quantifiable into a figure of merit. The result is a numerical decision aid that usually has some undesirable attributes such as oversimplification, non-sensitivity to critical parameters, hidden calculations, and difficulty in exercise of the model. This technique is characterized by mathematical models, computer programs, and attempted optimizations. The second viewpoint, in conjunction with the controller, is to consider the effectiveness as specified and concentrate on cost reduction, This has a danger of formulating all technical problems in terms of cost or economic considerations. This technique is characterized by closely controlled work packages.
2016-06-16
Standard
EQB1
Scope is unavailable.
2016-06-16
Standard
EIAIS632
This standard defines a total system approach for the development of systems. The standard requires: establishing and implementing a structured, disciplined. and documented systems engineering effort incorporating the systems engineering process; multidisciplinary teamwork; and the simultaneous development of the products and processes needed to satisfy user needs. The systems engineering process is defined generically to facilitate broad application. This standard defines the requirements for technical reviews. The tasks in this standard provide a methodology for evaluating progress in achieving system objectives. This standard provides a comprehensive, structured, and disciplined approach for all life-cycle phases, including new system product and process developments, upgrades, modifications, and engineering efforts conducted to resolve problems in fielded systems.
2016-06-16
Standard
EIAIS731_1
The purposeo f this Interim Standard is to support the development and improvement of systems engineering capability. The scope of this standard includesa ll activities that associate with or enable systems engineering. Systems engineering is an inter-disciplinary approach and means to enable the realization of successful systems. In this context, systems engineering is not limited to what either Systems Engineering organizations or Systems Engineers do. Rather it is the interaction of many people, processes, and organizations resulting in the accomplishment of the required activities.
2016-06-16
Standard
EIAIS731_2
This document describes the Appraisal Method (AM ) for the Systems Engineering Capability Model (SECM). An appraisal compares an organization's Systems Engineering capabilities against the Specific Practices of the Focus Areas and the Generic Characteristics defined in EIA/731, Part 1.
2016-06-16
Standard
EIACALS
This report documents the findings of an industry study panel convened by the Electronic Industries Association(EIA) under the auspices of the Computer-aided Acquisition and Logistics Support (CALS) Industry Steering Committee to determine the best utilization of product data description standards for electronic configuration items in the near term. Appendix A contains a brief outline of the CALS Program. The study group's objective was to determine the most advantageous mix of existing standards for application in specifying digital delivery of product data items in support of weapon system development and support contracts. The evaluation was accomplished by means of a product data requirements matrix in which types of data required by the government throughout the development process were mapped against the applicability of the various standards. A delphi approach, in which users of all of the standards participated, was used to determine applicability.
2016-06-15
Standard
EIAIS109
The CDIF Family of Standards is primarily designed to be used as a description of a mechanism for transferring information between CASE tools. It facilitates a successful transfer when the authors of the importing and exporting tools have nothing in common except an agreement to conform to CDIF. The language that is defined for the Transfer Format also has applicability as a general language for ImportExport from repositories. The CDIF Integrated Meta-model defined for CASE also has applicability as the basis of standard definitions for use in repositories.
2016-06-15
Standard
EIAIS110
This document is intended to be used by anyone wishing to understand and/or use CDIF. This dticument provides a definition of an encoding for CDIF transfers. -those evaluating CDIF -those who wish to understand the principles and concepts of a CDIF transfer -those developing importers and exporters.
2016-06-15
Standard
EIAIS111
This document is intended to be used by anyone wishing to understand and/or use CDIF. This document provides a definition of a single subject area of the CDIF integrated Meta-model. It is suitable for: -those evaluating CDIF -those who wish to understand the principles and concepts of a CDIF transfer -those developing importers and exporters.
2016-06-15
Standard
EIAIS106
This standard will assist the vendors and users of CASE tools in developing mechanisms for interchanging information between CASE tools. This standard specifies an element of a family of related standards. When used together, these standards specify a mechanism for transfemng information between CASE tools. This standard, EIAIIS-IO6 CDIF - CASE Data Interchange Format - Overview, describes the architecture of the CDIF Family of Standards and provides an overview to all the current standards that form the CDIF Family of Standards.
2016-06-15
Standard
EIAIS108
This standard defines how CDIF supports multiple exchange Syntaxes and Encoding, and describes how CDIF meta-models are concretely represented during a transfer. EIAIZS-IO9 CDIF - Trartsfer- Format - Syntax SYNTAX.1 and EIAIIS-II0 CDIF - Transfer Format - Encoding ENCODING.1 define one specific CDIF Syntax and Encoding.
2016-06-15
Standard
EIAIS107
This standard will assist the vendors and users of CASE tools in developing mechanisms for interchanging information between CASE tools. This standard specifies an element of a family of related standards. When used together, these standards specify a mechanism for transferring information between CASE tools.
2016-06-06
Standard
AS681K
This SAE Aerospace Standard (AS) provides the method for presentation of gas turbine engine steady state and transient performance calculated using computer programs. It also provides for the presentation of parametric gas turbine data including performance, weight, and dimensions computed by computer programs. This standard is intended to facilitate calculations by the program user without unduly restricting the method of calculation used by the program supplier. This standard is applicable to, but not limited to the following program types: data reduction, steady-state, transient, preliminary design, study, specification, status, and parametric programs.
2016-05-31
Standard
CRB1
Expert systems are a wave of the information processing future. As time goes on they will become more and more part of the mainstream. However, a necessary prerequisite to moving them into widespread use is to reduce the methodologies for expert system development closer to the more generally accepted software engineering techniques. This report offers a step towards that goal. It describes an alternative software life cycle model for expert system development. Since the field of Artificial Intelligence is so broad, this report limits the software to be considered. Systems that would be of the greatest interest to DoD over the next 5 to 7 years would be expert systems that have the following attributes: - may reason with uncertainty - are not necessarily rule-based - are non-learning systems. For these systems, a developmental cycle is articulated, and each phase of the cycle described.
2016-05-31
Standard
CRB2
This paper originated with a software quality panel workshop at the EIA Computer Resources Workshop. The panel group initially focused on requirements for nondeliverable software. It was felt that the requirements for deliverable software were well covered by Department of Defense standards but non-deliverable software issues were not adequately covered. After much discussion, including attempts to define nondeliverable by examples of software types, a surprising unanimous conclusion was reached by the participants. That is: the states of "deliverable" and "non-deliverable" had no bearing on the quality of the software, and thereby also had no bearing on the quality assurance requirements that should be applied for that software. Rather, the only rational application of quality assurance was primarily dependent on the impact that the software had, or could have, on the end product (¡.e. the ultimate mission).
2016-05-31
Standard
EDIB1B
This userguide contains a description of the Unit Production Cost Tracking Model for use in design tradeoffs and control and reporting tasks of a Design-to-Cost program. This model is designed to compare two Cost Breakdown Structures (CBS) to show elemental and summary cost differences. The two Cost Breakdown Structures may represent design alternatives, or a target allocation and the current design approach for comparison.
2016-05-24
Standard
AIR4762A
This Aerospace Information Report (AIR) describes conditions under which freezing (frozen) brakes can occur and describes operating procedures which have been used to prevent or lessen the severity or probability of brake freezing. This document also identifies design features that some manufacturers implement to minimize the occurrence of freezing brakes. This document is not an Aerospace Recommended Practice (ARP) and therefore does not make recommendations based on a consensus of the industry. However, part of this document’s purpose is to describe the design and operational practices that some are using to minimize the risk of frozen brakes. NOTE: The following information is based upon experience gained across a wide-range of aircraft types and operational profiles, and should NOT take precedence over Aircraft Flight Manual or Flight Operations Procedures.
2016-05-17
WIP Standard
JA6268
This Aerospace Recommended Practice (ARP) was created to help industry deal with existing barriers to the successful implementation of Integrated Vehicle Health Management (IVHM) technology in the aerospace and automotive sectors. That is,given the common barriers that exist, this ARP can be applied not only to aerospace but also to the automotive, commercial and military vehicle sectors. Original Equipment Manufacturers (OEMs) in all of these sectors are heavily dependant upon a large number of component suppliers in order to design and build their products. The advent of IVHM technology has accentuated the need for improved coordination and communication between the OEM and its suppliers –to ensure that suppliers design health ready capabilities into their particular components.
2016-05-17
WIP Standard
AIR6245
This document is applicable to military aircraft where stakeholders are seeking guidance on the development and approval of Structural Health Monitoring (SHM) technologies and on the integration of these technologies into encompassing maintenance and operational support systems. The document will refer to those guidelines prepared under SAE ARP6461 that are relevant and applicable to military applications.
2016-05-04
WIP Standard
AIR5120A
This document has been declared "CANCELLED" by the E32 committee as of April 2016 and has been superseded by ARP5120. By this action, this document will remain listed in the Numerical Section of the Aerospace Standards Index noting that it is superseded by ARP5120. Cancelled specifications are available from SAE.
2016-04-22
WIP Standard
ARP6904
In order to realize the benefits of Integrated Vehicle Health Management (IVHM) within the aerospace and defense industry there is a need to address five critical elements of data interoperability within and across the aircraft maintenance ecosystem, namely • Approach • Trust • Context • Value • Security In Integrated Vehicle Health Management (IVHM) data interoperability is the ability of different authorized components, systems, IT, software, applications and organizations to securely communicate, exchange data, interpret data, use the information and derive consistent insight from the data that has been exchanged to derive value.
Viewing 1 to 30 of 349

Filter

  • Aerospace
    349
  • Standard
    349