Criteria

Text:
Content:
Display:

Results

Viewing 1 to 30 of 504
2016-09-14
WIP Standard
AS4074B
This standard specifies the characteristics of the SAE Linear Token Passing Bus (LTPB) Interface Unit. The LTPB provides a high reliability, high bandwidth, low latency serial interconnection network suitable for utilization in real time military and commercial applications. Multiple redundant data paths can be implemented to enhance reliability and survivability in those applications which require these attributes. The token passing and data exchange protocols are optimized to provide low latency and fast failure detection and correction. Physical configurations with bus lengths up to 1000 m can be accommodated.
2016-09-14
WIP Standard
AS15531A
This SAE Aerospace Standard (AS) contains requirements for a digital time division command/response multiplex data bus, for use in systems integration, that is functionally equivalent to MIL-STD-1553B with Notice 2. Even with the use of this document, differences may exist between multiplex data buses in different system applications due to particular application requirements and the options allowed in this document. The system designer must recognize this fact and design the multiplex bus controller (BC) hardware and software to accommodate such differences. These designer selected options must exist to allow the necessary flexibility in the design of specific multiplex systems in order to provide for the control mechanism, architectural redundancy, degradation concept, and traffic patterns peculiar to the specific application requirements.
2016-09-03
WIP Standard
J1390
Three levels of fan structural analysis are included in this practice: 1. Initial Structural Integrity 2. In-vehicle Testing 3. Durability Test Methods The Initial Structural Integrity section describes analytical and test methods used to predict potential resonance and, therefore, possible fatigue accumulation. The In-vehicle (or machine) section enumerates the general procedure used to conduct a fan strain gage test. Various considerations that may affect the outcome of strain gage data have been described for the user of this procedure to adapt/discard depending on the particular application. The Durability Test Methods section describes the detailed test procedures that may be used depending on type of fan, equipment availability, and end objective. Each of the previous levels builds upon information derived from the previous level. Engineering judgment is required as to the applicability of each level to a different vehicle environment or a new fan design.
CURRENT
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.
CURRENT
2016-08-04
Standard
J2869_201608
This report details continuing work examining the fatigue life durability of a US Army Trailer. This report describes, through example, a process to evaluate and reduce the experimental data needed for a Mechanical Systems Physics - of Failure analysis. In addition the report describes the process used to validate the computer simulation models.
CURRENT
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.
CURRENT
2016-06-28
Standard
J2830_201606
This recommended practice describes a process for testing the comprehension of static (i.e., fixed or non-dynamic) symbols for all ground vehicles, for both OEM and aftermarket products. With advancing display technology, it is now possible to display dynamic symbols (e.g., a spinning beach ball to show that a process is ongoing, or a diagram showing energy distribution in hybrid vehicles). Such graphics are outside of the scope of this recommended practice, though extensions of this process may be useful for testing them. However, several symbols which occupy the same space on a display may change state without movement (e.g. play/pause button); these are within the scope of this recommended practice. The process described in this recommended practice includes criteria that are used to identify how well the perceived meaning matches the intended meaning for a representative sample of drivers.
CURRENT
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.
CURRENT
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).
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
2016-06-16
Standard
EQB1
Scope is unavailable.
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
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.
CURRENT
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-07
WIP Standard
AIR6908
This document provides informational background, rationale, and data (both physical testing and computer simulations) used in defining the component test methods and acceptance criteria described in SAE Aerospace Recommended Practice (ARP) 6330. ARP 6330 defines multiple test methods uses to assess the effect of seat back mounted IFE monitor changes on head blunt trauma.
CURRENT
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.
CURRENT
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.
CURRENT
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).
CURRENT
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.
Viewing 1 to 30 of 504