Display:

Results

Viewing 1 to 30 of 1993
2017-08-29
Book
This is the electronic format of the Journal.
CURRENT
2017-02-21
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. This specification defines the following: a. General Description (3.1): An overview of the LTPB protocol. b. Physical Media Interface (3.2): This portion of the standard defines the physical interface to both optical and electrical bus media. c.
CURRENT
2017-02-21
Standard
AIR4066C
This SAE Aerospace Information Report (AIR) defines the materials, strength and finishes utilized in current linear hydraulic flight control actuators. To keep the information at a relevant minimum, only cylinders (barrels), glands and pistons are listed. Also identified are the reasons for the material selection and any pertinent comments. All data were collected from the respective suppliers.
2017-02-20
WIP Standard
AS5506/3
(1) The Behavior Annex document provides a standard sublanguage extension to allow behavior specifications to be attached to AADL components. The aim of the Behavior Annex is to refine the implicit behavior specifications that are specified by the core of the language. The Behavior Annex targets the following goals: • Describe the internal behavior of component implementations as a state transition system with guards and actions. However, the aim is not to replace software programming languages or to express complex subprogram computations. • Extend the default run-time execution semantics that is specified by the core of the standard, such as thread dispatch protocols. • Provide more precise subprogram calls synchronization protocols for client-server architectures.
CURRENT
2017-02-09
Standard
AIR4543C
This SAE Aerospace Information Report (AIR) contains Lessons Learned from aerospace actuation, control and fluid power systems technologies. The lessons were prepared by engineers from the aerospace industry and government services as part of SAE Committee A-6, Aerospace Fluid Power, Actuation, and Control Technologies, and were presented to the A-6 during meetings held from 1989 through 1999. The document is organized into five sections covering systems, actuation, hydromechanical components, electrical components and miscellaneous, each further divided into subsections. The lessons are presented in a concise format of Problem, Issue, Solution and Lesson Learned, often with accompanying descriptive diagrams and illustrations for clarity and understanding.
2017-01-27
WIP Standard
ARP4102/4A
This document recommends design criteria for the Flight Deck Alerting System. The FAS shall enhance safety of flight by providing early crew recognition of aircraft system or component status or malfunction as well as of crew operational error. The FAS, therefore, relates to aircraft configuration and flight phase as well as the aircraft systems. To fulfill this objective, the FAS must attract the attention of the crew, must state with clarity the nature and location of the problem, and must be highly reliable and thoroughly responsive to the operational requirements and environment. Wherever possible, it should provide guidance as to the corrective action.
2017-01-27
WIP Standard
ARP5628A
This document recommends criteria and requirements for a Final Approach Spacing System (FASS) for transport aircraft. This is an Aerospace Recommended Practice to support the development of a Final Approach Spacing System (FASS) for Approach Spacing for Instrument Approaches (ASIA) operations.
2017-01-26
Magazine
Open Standard Middleware Enables New HPEC Solutions Cooling Your Embedded System What Can Your Open Standard Architecture Handle? Evaluating Key Certification Aspects of Multicore Platforms for Safety Critical Avionics Applications Simulating and Analyzing Flow for an Air-to-Air Refueling System The Ins and Outs of Spaceflight Passive Components and Assemblies Development of High Quality 4H-SiC Thick Epitaxy for Reliable High Power Electronics Using Halogenated Precursors Silicon Based Mid-Infrared SiGeSn Heterostructure Emitters and Detectors Reconfigurable Electronics and Non-Volatile Memory Research Energy-Filtered Tunnel Transistor: A New Device Concept Toward Extremely Low Energy Consumption Electronics
2017-01-25
WIP Standard
ARP6283/1
Provide user information on best practice methods and processes for the in-service inspection, evaluation and cleaning of expanded beam fiber optic interconnect components, test equipment, and test leads based on the information provided in AIR6031. This document provides the user with a decision making tool to be able to determine if the fiber optic components are acceptable for operation with expanded beam fiber optic termini.
2017-01-19
WIP Standard
ARP6283/2
Provide user information on best practice methods and processes for the in-service inspection, evaluation and cleaning of expanded beam fiber optic interconnect components, test equipment, and test leads based on the information provided in AIR6031. This document provides the user with a decision making tool to be able to determine if the fiber optic components are acceptable for operation with multi-fiber fiber optic termini.
CURRENT
2017-01-18
Standard
AS5506C
This standard defines a language for describing both the software architecture and the execution platform architectures of performance-critical, embedded, real-time systems; the language is known as the SAE AADL. An AADL model describes a system as a hierarchy of components with their interfaces and their interconnections. Properties are associated to these constructions. AADL components fall into two major categories: those that represent the physical hardware and those representing the application software. The former is typified by processors, buses, memory, and devices, the latter by application software functions, data, threads, and processes. The model describes how these components interact and are integrated to form complete systems. It describes both functional interfaces and aspects critical for performance of individual components and assemblies of components. The changes to the runtime architecture are modeled as operational modes and mode transitions.
CURRENT
2017-01-12
Standard
AS5609A
This SAE Aerospace Standard (AS) defines the editorial format and policies necessary for the publication of Interface Control documents. The Common Interface Control Document Format Standard defines a common format for aircraft/store interface documents to foster increased interoperability. It is designed with the versatility to serve differing “ICD” philosophies and organizations. This aerospace standard defines the common technical data sections for the Common Interface Control Document Format down to the third header level for the majority of sub-sections. The Common Interface Control Document Format Aerospace Standard provides a structured document format in appendixes supported by example paragraphs, drawings, etc.
2016-12-21
WIP Standard
ARP6915
This Aerospace Recommended Practice (ARP) offers best practice regarding the implementation of IVHM systems taking into account Human Factors, both the vehicle crew and the maintenance staff. The document will include considerations regarding both military and civil fixed wing aircraft. Safety implications will also be addressed.
CURRENT
2016-12-20
Standard
AS6513
This document is the authoritative specification within the SAE Unmanned Systems (UxS) Control Segment (UCS) Architecture for establishing conformance requirements for UCS products. The UCS products addressed by this specification are UCS software components and UCS software configurations that provide one or more UCS services, and UCS systems that employ one or more UCS services. The conformance of UCS products is determined by assessing the conformance of the UCS product description to the UCS Architecture. The UCS product description includes test artifacts.
CURRENT
2016-12-20
Standard
AS6512
This document is the Architecture Description (AD) for the SAE Unmanned Systems (UxS) Control Segment (UCS) Architecture. This AD serves as the official designation of the UCS Architecture - SAE AS6512. The UCS Architecture is expressed by a library of SAE publications as referenced herein. The other publications in the UCS Architecture Library are: AS6513, AIR6514, AIR6515, AIR6516, AIR6517, AS6518, AIR6519, AIR6520, AIR6521, and AS6522.
CURRENT
2016-12-20
Standard
AS6518
This brief User Guide recaps the content of the AS6518 UCS Architectural Model described in detail in AS6512 UCS Architecture: Architecture Description. The purpose of the UCS Architecture Model is to provide the authoritative source for other models and products within the UCS Architecture as shown in the AS6512 UCS Architecture: Architecture Description.
CURRENT
2016-12-20
Standard
AS6522
The UCS technical governance comprises a set of policies, processes, and standard definitions to establish consistency and quality in the development of architecture artifacts and documents. It provides guidance for the use of adopted industry standards and modeling conventions in the use of Unified Modeling Language (UML) and Service Oriented Architecture Modeling Language (SoaML), including where the UCS Architecture deviates from normal UML conventions. This document identifies the defining policies, guidelines, and standards of technical governance in the following subjects: - Industry standards adopted by the AS-4UCS Technical Committee: These are the industry standards and specifications adopted by AS-4UCS in the generation and documentation of the architecture. - UCS Architecture Development: UCS specific policies on the development of the UCS Architecture. The AS-4UCS Technical Committee governance policies are intentionally minimal.
CURRENT
2016-12-20
Standard
AIR6521
This platform specific Interface Control Document (ICD) provides an example mapping to the Object Management Group’s (OMG) Data Distribution Service (DDS) infrastructure middleware. The mapping is based on the Unmanned Systems (UxS) Control Segment (UCS) Architecture: Model, AS6518. A series of non-normative implementation choices have been made that are specific to this ICD. These implementation choices may not be appropriate for different system implementations. The machine readable ICD and result of this mapping and implementation choices are provided with AIR6521. Use and understanding of this document assumes a working knowledge of the UCS Architecture, the model structure and its contents.
CURRENT
2016-12-20
Standard
AIR6520
Governance of the Unmanned Aircraft System (UAS) Control Segment (UCS) Architecture was transferred from the United States Office of the Secretary of Defense (OSD) to SAE International in April 2015. Consequently, a subset of the UCS Architecture Library Release 3.4(PR) has been published under SAE as the Unmanned Systems (UxS) Control Segment (UCS) Architecture, AS6512. This Version Description Document (VDD) describes the correspondence and differences between the two architecture libraries.
CURRENT
2016-12-20
Standard
AIR6519
The Use Case Trace (UCTRACE) is SAE publication AIR6519 of the Department of Defense Unmanned Control Segment (UCS) Architecture. This document is the SAE publication of the Department of Defense UAS Control Segment (UCS) Architecture: Use Case Trace (UCTRACE) Version 3.4(PR) approved for Distribution A public release 15.S-1859. This information is produced from a script run against the System Use Case Model contained in the UCS Architecture Model AS6518-MODEL.eap configuration item. The System Use Case Model includes, at its lowest level of elaboration, use cases Level 2/3 (L2/L3) that describe specific scenarios of message exchanges between Actors and internal system Participants via ServiceInterfaces. These message exchanges provide a way to create detailed traces that answer the question: “What UCS service interfaces must my components implement to satisfy functional requirements represented by a given Level 2/3 UCS use case?”
CURRENT
2016-12-20
Standard
AIR6517
This User Guide describes the content of the Rhapsody version of the UCS Architectural Model and how to use this model within the Rhapsody modeling tool environment. The purpose of the Rhapsody version of the UCS Architectural Interface Control Document (ICD) model is to provide a model for Rhapsody users, derived from the Enterprise Architect (EA) model (AIR6515). The AIR6515 EA Model, and by derivation, the AIR6517 Rhapsody Model, have been validated to contain the same content as the AS6518 model for: - all UCS ICD interfaces - all UCS ICD messages - all UCS ICD data directly or indirectly referenced by ICD messages and interfaces - the Domain Participant, Information, Service and Non Functional Properties Models
CURRENT
2016-12-20
Standard
AIR6516
This User Guide describes the content of the Rational Software Architect (RSA) version of the UCS Architectural Model and how to use this model within the RSA modeling tool environment. The purpose of the RSA version of the UCS Architectural Interface ICD model is to provide a model for Rational Software Architect (RSA) users, derived from the Enterprise Architect (EA) ICD model (AIR6515). The AIR6515 EA Model, and by derivation, the AIR6516 RSA Model, have been validated to contain the same content as the AS6518 model for: - all UCS ICD interfaces - all UCS ICD messages - all UCS ICD data directly or indirectly referenced by ICD messages and interfaces - the Domain Participant, Information, Service and Non Functional Properties Models
CURRENT
2016-12-20
Standard
AIR6515
This User Guide describes the content of the Enterprise Architect (EA) version of the UCS Architectural Model and how to use this model within the EA modeling tool environment. The purpose of the EA version of the UCS Architectural Interface Control Document (ICD) model is to provide a working model for Enterprise Architect tool users and to serve as the source model for the Rational Software Architect (RSA) and Rhapsody models (AIR6516 and AIR6517). The AIR6515 EA Model has been validated to contain the same content as the AS6518 model for: - all UCS ICD interfaces - all UCS ICD messages - all UCS ICD data directly or indirectly referenced by ICD messages and interfaces - the Domain Participant, Information, Service, and Non Functional Properties Models
CURRENT
2016-12-20
Standard
AIR6514
This interface control document (ICD) specifies all software services in the Unmanned Systems (UxS) Control Segment Architecture, including interfaces, messages, and data model.
2016-11-23
WIP Standard
AS407E
To specify minimum requirements for Fuel Flowmeters for use primarily in reciprocating engine powered civil transport aircraft, the operation of which may subject the instruments to the environmental conditions specified in Section 3.3. This Aeronautical Standard covers two basic types of instruments, or combinations thereof, intended for use in indicating fuel consumption of aircraft engines as follows: TYPE I - Measure rate of flow of fuel used. TYPE II - Totalize amount of fuel consumed or remaining.
CURRENT
2016-11-18
Standard
AIR6234
This Handbook is intended to provide useful information on the application of AS5716A. It is for use by System Program Offices, aircraft prime contractors, avionics and store system designers, system integrators and equipment manufacturers and users. This Handbook was prepared to provide users of the standard of the rationale and principles considered during the development of the standard. It is anticipated that the handbook will serve to assist developers in introducing new technology to achieve compliance with the standard and the underlying principles of the standard. It is intended that the Handbook be used alongside the standard, as it does not contain significant extracts of the standard.
CURRENT
2016-11-18
Standard
ARP6379
This document describes a process for use by ADHP integrators of EEE parts and sub-assemblies (items) that have been targeted for other applications. This document does not describe specific tests to be conducted, sample sizes to be used, nor results to be obtained; instead, it describes a process to define and accomplish application-specific qualification; that provides confidence to both the ADHP integrators, and the integrators’ customers, that the item will performs its function(s) reliably in the ADHP application.
2016-10-25
Technical Paper
2016-36-0377
Alain Giacobini Souza, Luiz Carlos Gadelha Souza
Abstract In designing of the Attitude Control System (ACS) is important take into account the influence of the structure’s flexibility, since they can interact with the satellite rigid motion, mainly, during translational and/or rotational maneuver, damaging the ACS pointing accuracy. In the linearization and reduction of the rigid-flexible satellite mathematic model, usually one loses some important information associated with the satellite true dynamical behavior. One way to recovery this information is include to the ACS design parametric and not parametric uncertainties of the system. The H infinity control method is able to take into account the parametric uncertainty in the control law design, so the controller becomes more robust. This paper presents the design of a robust controller using the H infinity control technique to control the attitude of a rigid-flexible satellite.
Viewing 1 to 30 of 1993

Filter