Search Results

ARP4754B Clarification Notice to address typographical errors and clarify portions of the document to facilitate usage of the newly released ARP4754B.

This SAE Aerospace Information Report (AIR) describes the Architecture Framework for Unmanned Systems (AFUS). AFUS comprises a Conceptual View, a Capabilities View, and an Interoperability View. The Conceptual View provides definitions and background for key terms and concepts used in the unmanned systems domain. The Capabilities View uses terms and concepts from the Conceptual View to describe capabilities of unmanned systems and of other entities in the unmanned systems domain. The Interoperability View provides guidance on how to design and develop systems in a way that supports interoperability.

Applicable to SAE Level 3, 4, 5 ADS-equipped vehicle value chain (development, manufacture, operation, and decommission). Inclusions: Any development, manufacture, and deployment of ADS technology such as On-road personal- or fleet-owned and operated passenger motor vehicles, Transportation as a Service (TaaS), Mobility as a Service, taxi, delivery, shuttle vehicles, trucks, and buses, and enabling or supporting services. Exclusions: Off-road or closed course applications (e.g. mining, on airport, industrial equipment).

This technical information report (IR) presents a methodology to evaluate battery pack liquid leak tightness attributes to be used in a production line to satisfy the functional requirement for IPX7, water ingress requirement, and no sustainable coolant leakage for coolant circuits. The Equivalent Channel Method is used as a suggested production leak tightness requirement for a given battery pack design that will correlate and assure that the battery pack meets or exceeds its functional requirement. Obtaining the specific geometry of the Equivalent Channel (EC) for a given battery pack is done analytically and empirically in consideration of the product design limitations. This document is a precursor to J3277-1, which will present the practices to qualify that product leak tightness is equal or better than the maximum allowed EC for that product using applicable and commercially available leak test technologies.

This document describes guidelines, methods, and tools used to perform the ongoing safety assessment process for transport airplanes in commercial service (hereafter, termed “airplane”). The process described herein is intended to support an overall safety management program. It is associated with showing compliance with the regulations, and also with assuring a company that it meets its own internal standards. The methods identify a systematic means, but not the only means, to assess ongoing safety.While economic decision-making is an integral part of the safety management process, this document addresses only the ongoing safety assessment process. To put it succinctly, this document addresses the “Is it safe?” part of safety management; it does not address the “How much does it cost?” part of the safety management.This document also does not address any specific organizational structures for accomplishing the safety assessment process.

This document describes a process that may be used to perform the ongoing safety assessment for (1) GAR aircraft and components (hereafter, aircraft), and (2) commercial operators of GAR aircraft. The process described herein is intended to support an overall safety management program. It is to help a company establish and meet its own internal standards. The process described herein identifies a systematic means, but not the only means, to assess continuing airworthiness.Ongoing safety management is an activity dedicated to assuring that risk is identified and properly eliminated or controlled. The safety management process includes both safety assessment and economic decision-making. While economic decision-making (factors related to scheduling, parts, and cost) is an integral part of the safety management process, this document addresses only the ongoing safety assessment process.

This document is intended to supplement the SAE J1939 documents by offering the SAE J1939 information in a form that can be sorted and search for easier use.

Generate guidance and example(s) regarding Airworthiness Security inputs to the Aircraft/System Development Processes in ARP 4754B sections 4.2 thru 4.6, and section 6. Also, clarify any essential output(s) from the Aircraft/System Development Processes that the Airworthiness Security Process DO-326A requires as input(s).

This SAE Battery Identification and Cross Contamination Prevention document is intended to provide information that may be applicable to all types of Rechargeable Energy Storage System (RESS) devices. It is important to develop a system that can facilitate sorting by chemistry. The recycler is interested in the chemistry of the RESS. This is true for the recyclers of Lead Acid, Lithium Ion, Nickel Cadmium etc. Thus recyclers of RESS will receive RESS from automotive, commercial, and industrial applications. These RESS have the potential to be contaminated with a RESS of an incompatible chemistry. It is recognized that mitigation methods to reduce or eliminate the introduction of incompatible chemistries into a given recycling stream would also benefit safety and the environment.

This SAE Recommended Practice provides definitions, taxonomy, and characteristics for DA metrics used to quantify the driving performance of ADS-operated vehicles. Here, the primary focus is on the safety-related driving performance, which is considered to be related to completion of the dynamic driving task (DDT) . Driving performance is a subset of overall operational performance of ADS-operated vehicles. Thus, assessments of cybersecurity, maintenance, interactions with passengers, etc., while important, are out of scope for this document. Note that the DA metrics do not specify the actions and/or maneuvers to be executed by the subject vehicle. A literature review of DA metrics that have been proposed and, in some cases, used in previous studies was conducted. From this literature review, a set of DA metrics has been created with example usage. Evidence of prior research indicating that a metric has a relationship with safety outcome(s) is included where applicable.

This SAE Recommended Practice provides guidance for test facilities in identifying potential hazards, and safety risks, along with requirements and recommendations related specifically to testing of automated driving systems (ADS) and ADS-operated vehicles. Herein after, for the purposes of this document, utilization of the term “test facilities” implies those conducting testing of ADS or ADS-operated vehicles, unless otherwise noted. References made to safety within this recommended practice apply only to test method safety and driving safety on and during testing at an ADS test facility and do not apply to vehicle design or safety performance. Safety practices for on-road testing, operation, and related deployment are not covered within this document.

This AIR provides a detailed example of the aircraft and systems development for a function of a hypothetical S18 aircraft. In order to present a clear picture, an aircraft function was broken down into a single system. A function was chosen which had sufficient complexity to allow use of all the methodologies, yet was simple enough to present a clear picture of the flow through the process. This function/system was analyzed using the methods and tools described in ARP4754A/ED-79A. The aircraft level function is “Decelerate Aircraft On Ground” and the system is the braking system. The interaction of the braking system functions with the aircraft are identified with the relative importance based on implied aircraft interactions and system availabilities at the aircraft level. This example does not include validation and verification of the aircraft level hazards and interactions with the braking system.

This Technical Governance is part of the SAE UCS Architecture Library and is primarily concerned with the UCS Architecture Model (AS6518) starting at Revision A and its user extensions. Users of the Model may extend it in accordance with AS6513 to meet the needs of their UCS Products. UCS Products include software components, software configurations and systems that provide or consume UCS services. For further information, refer to AS6513 Revision A or later. Technical Governance is part of the UCS Architecture Framework. This framework governs the UCS views expressed as Packages and Diagrams in the UCS Architecture Model.

This SAE Recommended Practice covers the requirements for ethernet physical layer (PHY) qualification (and as applicable to other high-speed networks [i.e., Audio Bus, LVDS, Ser-Des, etc.]). Requirements stated in this document provide a minimum standard level of performance for the PHY in the IC to which all compatible ethernet communications PHY shall be designed. When the communications chipset is an ethernet switch with an integrated automotive PHY (xBASE-T1), then the testing shall include performance for all switch PHY ports as well as each controller interface. No other features in the IC are tested or qualified as part of this SAE Recommended Practice. This assures robust serial data communication among all connected devices regardless of supplier. The goal of SAE J2962-3 is to commonize approval processes of ethernet PHYs across OEMs. The intended audience includes, but is not limited to, ethernet PHY suppliers, component release engineers, and vehicle system engineers.

This document covers the requirements for transceiver qualification. Requirements stated in this document will provide a minimum standard level of performance for the CAN transceiver in the IC to which all compatible transceivers shall be designed. No other features in the IC are tested or qualified as part of this recommended practice. This will assure robust serial data communication among all connected devices, regardless of supplier. The goal of SAE J2962-2 is to commonize approval processes of CAN transceivers across OEMs. The intended audience includes, but is not limited to, CAN transceiver suppliers, component release engineers, and vehicle system engineers.

This document covers the requirements for transceiver qualification. Requirements stated in this document will provide a minimum standard level of performance for the LIN transceiver block in the IC to which all compatible transceivers shall be designed. No other features in the IC are tested or qualified as part of this recommended practice. This will assure robust serial data communication among all connected devices regardless of supplier. The goal of SAE J2962-1 is to commonize approval processes of LIN transceivers across OEMs. The intended audience includes, but is not limited to, LIN transceiver suppliers, component release engineers, and vehicle system engineers.

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

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

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.