Criteria

Text:
Content:
Display:

Results

Viewing 1 to 30 of 252
2017-06-19
WIP Standard
J2931/6
This SAE Information Report J2931/6 establishes the requirements for physical and data link layer communications between Plug-in Electric Vehicles (PEV) and the Electric Vehicle Supply Equipment (EVSE).
2017-06-19
WIP Standard
J2847/6
This SAE Recommended Practice SAE J2847-6 establishes requirements and specifications for communications messages between wirelessly charged electric vehicles and the wireless charger. Where relevant, this document notes, but does not formally specify, interactions between the vehicle and vehicle operator. This is the 1st version of this document and captures the initial objectives of the SAE task force. The intent of step 1 is to record as much information on “what we think works” and publish. The effort continues however, to step 2 that allows public review for additional comments and viewpoints, while the task force also continues additional testing and early implementation. Results of step 2 effort will then be incorporated into updates of this document and lead to a republished version. The next revision will address the harmonization between SAE J2847-6 and ISO/IEC 15118-7 to ensure interoperability.
2017-05-23
WIP Standard
AS5680B
This interface standard applies to fuzes used in airborne weapons that use a 3-in fuze well. It defines: - Physical envelope of the fuze well at the interface with the fuze. - Load bearing surfaces of the fuze well. - Physical envelope of the fuze and its connector. - Mechanical features (e.g., clocking feature). - Connector type, size, location and orientation. - Retaining ring and its mechanical features (e.g., thread, tool interface). - Physical envelope of the retaining ring at the interface with the fuze. - Physical space available for installation tools. - Torque that the installation tool shall be capable of providing. This standard does not address: - Materials used or their properties. - Protective finish. - Physical environment of the weapon. - Explosive interface or features (e.g., insensitive munitions (IM) mitigation). - Charging tube. - Torque on the retaining ring or loads on the load bearing surfaces.
2017-05-23
WIP Standard
AS4270A
This document establishes techniques for validating that a mission store comples with the interface requirements delineated in MIL-STD-1760.
2017-05-23
WIP Standard
AIR6027A
The information presented in this AIR is intended to provide designers of armed unmanned systems with guidelines that may be applied to ensure safe integration and operation of weapons on unmanned platforms. The guidelines have been developed from experiences gained in the design and operation of weapons on manned aircraft that have been accepted by relevant safety authorities in the USA and Europe and proven effective over many years. Whilst the guidelines have been developed from experience with aircraft operations, the concepts are considered equally applicable to non-aircraft systems, such as those used on the surface or undersea environments.
2017-05-23
WIP Standard
AS47642B
This document establishes techniques for validating that an Aircraft Station Interface (ASI) complies with the interface requirements delineated in MIL-STD-1760C. For validation of aircraft designed to MIL-STD-1760A Notice 2 AS4764 Issued 1995-04 applies. For validation of aircraft designed to MIL-STD-1760B Notice 3 AS47641 Issued 1999-08 applies.
2017-05-23
WIP Standard
AS4764A
This document establishes techniques for validating that an aircraft station complies with the interface requirements delineated in MIL-STD-1760.
2017-05-22
WIP Standard
J1939DA
This document is intended to supplement the J1939 documents by offering the J1939 information in a form that can be sorted and search for easier use. The J1939 Digital Annex, introduced in August 2013, offers key J1939 technical data in an Electronic Spreadsheet that can be easily searched, sorted, and adapted to other formats. J1939DA contains all of the SPNs (parameters), PGNs (messages), and other J1939 data previously published in the SAE J1939 top level document. J1939DA also contains all of the SLOTs, Manufacturer ID Codes, NAME Functions, and Preferred Addresses previously published in the SAE J1939 top level and the J1939-71 document. J1939DA contains the complete technical details for all of the SPNs and PGNs previously published in the SAE J1939-71 document. It also includes the supporting descriptions and figures previously published in the SAE J1939-71 document.
CURRENT
2017-05-12
Standard
J1939/73_201705
SAE J1939-73 Diagnostics Application Layer defines the SAE J1939 messages to accomplish diagnostic services and identifies the diagnostic connector to be used for the vehicle service tool interface. Diagnostic messages (DMs) provide the utility needed when the vehicle is being repaired. Diagnostic messages are also used during vehicle operation by the networked electronic control modules to allow them to report diagnostic information and self-compensate as appropriate, based on information received. Diagnostic messages include services such as periodically broadcasting active diagnostic trouble codes, identifying operator diagnostic lamp status, reading or clearing diagnostic trouble codes, reading or writing control module memory, providing a security function, stopping/starting message broadcasts, reporting diagnostic readiness, monitoring engine parametric data, etc.
CURRENT
2017-04-27
Standard
J1939DA_201704
This document is intended to supplement the J1939 documents by offering the J1939 information in a form that can be sorted and search for easier use. The J1939 Digital Annex, introduced in August 2013, offers key J1939 technical data in an Electronic Spreadsheet that can be easily searched, sorted, and adapted to other formats. J1939DA contains all of the SPNs (parameters), PGNs (messages), and other J1939 data previously published in the SAE J1939 top level document. J1939DA also contains all of the SLOTs, Manufacturer ID Codes, NAME Functions, and Preferred Addresses previously published in the SAE J1939 top level and the J1939-71 document. J1939DA contains the complete technical details for all of the SPNs and PGNs previously published in the SAE J1939-71 document. It also includes the supporting descriptions and figures previously published in the SAE J1939-71 document.
CURRENT
2017-03-21
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.
CURRENT
2017-03-21
Standard
J2945/9_201703
This document provides recommendations of safety message minimum performance requirements between a Vulnerable Road User (VRU) and a vehicle. It addresses the transmission of Personal Safety Messages (PSM) from road user devices carried by pedestrians, bicycle riders and public safety personnel, to provide driver and vehicle system awareness and potentially offer safety alerts to VRUs. This document includes the recommendation of standards profiles, function descriptions and minimum performance requirements for transmitting the SAE J2735-defined PSM [1] over a Dedicated Short Range Communications (DSRC) Wireless communication link as defined in the Institute of Electrical and Electronics Engineers (IEEE) 1609 and the IEEE 802.11 Standards [[1]]-[5]].
2017-03-17
WIP Standard
AIR6388
The information presented in this AIR is intended to provide information about current remote identification methods and practical considerations for remotely identifying UAS. Depending on rigor and adherence requirements, Aerospace Standard (AS) and Aerospace Recommended Practice (ARP) documents may be developed. For example, ARPs may provide methods to remotely identify UAS using existing hardware technologies typically available to most consumers. ARPs may also specify the information exchange and message format between unmanned aerial systems and remote interrogation instruments. An AS, however, may highlight the wireless frequency band, message type, message encoding bits, and message contents.
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: General Description (3.1): An overview of the LTPB protocol. Physical Media Interface (3.2): This portion of the standard defines the physical interface to both optical and electrical bus media.
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.
HISTORICAL
2017-02-09
Standard
J1939DA_201702
This document is intended to supplement the J1939 documents by offering the J1939 information in a form that can be sorted and search for easier use. The J1939 Digital Annex, introduced in August 2013, offers key J1939 technical data in an Electronic Spreadsheet that can be easily searched, sorted, and adapted to other formats. J1939DA contains all of the SPNs (parameters), PGNs (messages), and other J1939 data previously published in the SAE J1939 top level document. J1939DA also contains all of the SLOTs, Manufacturer ID Codes, NAME Functions, and Preferred Addresses previously published in the SAE J1939 top level and the J1939-71 document. J1939DA contains the complete technical details for all of the SPNs and PGNs previously published in the SAE J1939-71 document. It also includes the supporting descriptions and figures previously published in the SAE J1939-71 document.
CURRENT
2017-01-18
Standard
AS5506C
AADL specifications may be processed manually or by tools for analysis and generation. This section documents additional requirements and permissions for determining compliance. Providers of processing method implementations must document a list of those capabilities they support and those they do not support. NOTE: Notes emphasize consequences of the rules described in the (sub)clause or elsewhere. This material is informative.
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.
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
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
AIR6514
This interface control document (ICD) specifies all software services in the Unmanned Systems (UxS) Control Segment Architecture, including interfaces, messages, and data model.
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
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
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
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
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
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-11-21
Standard
J2284/1_201611
This SAE Recommended Practice will define the Physical Layer and portions of the Data Link Layer of the Open Systems Interconnection model (ISO 7498) for a 125 kbps High Speed CAN (HSC) protocol implementation. Both ECU and media design requirements for networks will be specified. Requirements will primarily address the CAN physical layer implementation. Requirements will focus on a minimum standard level of performance from the High Speed CAN (HSC) implementation. All ECUs and media shall be designed to meet certain component level requirements in order to ensure the HSC implementation system level performance at 125 kbps. The minimum performance level shall be specified by system level performance requirements or characteristics described in detail in Section 5 of this document. This document is designed such that if the Electronic Control Unit requirements defined in Section 6 are met, then the system level attributes should be obtainable.
Viewing 1 to 30 of 252