Refine Your Search

Search Results

Viewing 1 to 13 of 13
Standard

Statistical Product Acceptance Requirements Using Process Control Methods

2005-10-27
HISTORICAL
ARP9013/3
ARP9013/3 recommended practice specifies a product acceptance system using process control methods. Its purpose is to assure conformance for specified characteristics. Use of process control techniques for product acceptance requires maintaining process stability and capability. A stable and capable process is the best assurance of conforming hardware for the customer. There can be lower inspection costs associated with a process control acceptance approach.
Standard

Statistical Product Acceptance Requirements

2005-10-27
HISTORICAL
ARP9013
This SAE Aerospace Recommended Practice (ARP) establishes the general requirements when implementing any of the statistical product acceptance methods as defined in ARP9013/1, ARP9013/2, ARP9013/3, and ARP9013/4. This recommended practice also establishes the minimum content required to be covered in an organization’s documented procedures that govern their application of statistical product acceptance methods. These general requirements and documented procedures apply the requirements of AS9100 plus requirements for retrievability, safety/critical characteristics, quality parameters, and that these parameters protect the customer. This recommended practice is to be used in conjunction with the variety of sampling strategies, statistical techniques, and process control methods of the ARP9013/1 through ARP9013/4 recommended practices as chosen by the organization.
Standard

Quality Management Systems – Requirements for Aviation, Space and Defense Organizations – Deliverable Software (Supplement to 9100)

2010-04-27
HISTORICAL
AS9115
The requirements of 9100 apply with the following clarification for software. This document supplements the 9100 standard requirements for deliverable software and contains quality management system requirements for organizations that design, develop, and/or produce deliverable software for the aviation, space, and defense industry. This includes, as required, support software that is used in the development and maintenance of deliverable software. The deliverable software may be stand-alone, embedded, or loadable into a target computer. Where the use of Hardware Description Language (HDL) or high order language is utilized as the design source of electronic hardware [e.g., Application Specific Integrated Circuit (ASIC), Programmable Logic Device (PLD)], the organization and customer shall agree on the extent of applicability of this supplement. NOTE 1: For airborne electronic hardware guidance, see RTCA/DO-254 or EUROCAE ED-80; and for product realization requirements, see 9100.
Standard

Quality Management Systems - Requirements for Aviation, Space, and Defense Organizations - Deliverable Software (Supplement to 9100:2016)

2017-02-01
CURRENT
AS9115A
The requirements of 9100 apply with the following clarification for software. This standard supplements the 9100 standard requirements for deliverable software and contains quality management system requirements for organizations that design, develop, and/or produce deliverable software and services for the aviation, space, and defense industry. This includes, as required, support software that is used in the development and maintenance of deliverable software and services. The deliverable software may be stand-alone, embedded, mobile application, or loadable into a target computer. This deliverable software may also be part of services (e.g., cloud environment, web hosted solutions or platforms).
Standard

Deliverable Aerospace Software Supplement for As9100a

2003-03-12
HISTORICAL
AS9006
The basic requirements of AS9100 apply with the following clarifications. This document supplements the requirements of AS9100:2001 for software. This supplement contains Quality System requirements for suppliers of products that contain deliverable embedded or loadable airborne, spaceborne or ground support software components that are part of an aircraft Type Design, weapon system, missile or spacecraft operational software and/or support software that is used in the development and maintenance of deliverable software. This includes the host operating system software including assemblers, compilers, linkers, loaders, editors, code generators, analyzers, ground simulators and trainers, flight test data reduction, etc., that directly support creation, test and maintenance of the deliverable software. Where COTS or non-developmental components are used, the customer shall define the applicability of this supplement.
Standard

Deliverable Aerospace Software Supplement for AS9100AQuality Management Systems - Aerospace - Requirements for Software (based on AS9100A)

2013-07-09
CURRENT
AS9006A
The basic requirements of AS9100A apply with the following clarifications. This document supplements the requirements of AS9100A for deliverable software. This supplement contains Quality System requirements for suppliers of products that contain deliverable embedded or loadable airborne, spaceborne or ground support software components that are part of an aircraft Type Design, weapon system, missile or spacecraft operational software and/or support software that is used in the development and maintenance of deliverable software. This includes the host operating system software including assemblers, compilers, linkers, loaders, editors, code generators, analyzers, ground simulators and trainers, flight test data reduction, etc., that directly support creation, test and maintenance of the deliverable software.
Standard

Data Matrix Quality Requirements for Parts Marking

2005-02-16
HISTORICAL
AS9132A
This SAE Aerospace Standard (AS) defines uniform Quality and Technical requirements relative to metallic parts marking performed in using "Data Matrix symbology" used within the aerospace industry. The ISO/IEC 16022 specifies general requirements (data character encodation, error correction rules, decoding algorithm, etc.). In addition to ISO/IEC 16022 specification, part identification with such symbology is subject to the following requirements to ensure electronic reading of the symbol. The marking processes covered by this standard are as follows: Dot Peening Laser Electro-Chemical Etching Further marking processes will be included if required. This standard does not specify information to be encoded. Unless specified otherwise in the contractual business relationship, the company responsible for the design of the part shall determine the location of the Data Matrix Marking. Symbol position should allow optimum illumination from all sides for readability.
Standard

Aerospace Series – Notice of Change (NOC) Requirements

2015-03-12
CURRENT
AS9016A
The aviation, space, and defense industries rely on the development and manufacture of complex products comprised of multiple systems, subsystems, and components each designed by individual designers (design activities) at various levels within the supply chain. Each design activity controls various aspects of the configuration and specifications related to the product. When a change to design information is requested or required, the change has to be evaluated against the impacts to the higher-level system. Proposed changes to design information that the design activity identifies to be minor and have no effect on their product requirements or specifications have the potential to be concurrently implemented and approved, where authorized to do so. Changes that affect customer mandated requirements or specifications must be approved prior to implementation.
Standard

Aerospace Series – Notice of Change (NOC) Requirements

2009-06-11
HISTORICAL
AS9016
The aviation, space, and defense industries rely on the development and manufacture of complex products comprised of multiple systems, subsystems, and components each designed by individual designers (design activities) at various levels within the supply chain. Each design activity controls various aspects of the configuration and specifications related to the product. When a change to design information is requested or required, the change has to be evaluated against the impacts to the higher-level system. Proposed changes to design information that the design activity identifies to be minor and have no effect on their product requirements or specifications have the potential to be concurrently implemented and approved, where authorized to do so. Changes that affect customer mandated requirements or specifications must be approved prior to implementation.
Standard

Aerospace Guidance for Non-Deliverable Software

2019-03-05
WIP
ARP9005B
General: This document contains recommended practices for the effective control of non-deliverable software. It addresses practices for control during the development, production, release maintenance, and retirement of non-deliverable software, as well as for software procured from outside manufacturers and incorporated in the production, evaluation, test, acceptance or calibration of processes. For the purposes of this document, the terms software and non-deliverable software are considered synonymous. Application: The guidelines in this ARP apply to non-deliverable software that: - directly relates to design, manufacture, inspection, test or calibration of a deliverable product, and - directly affects the configuration, conformity or quality of a deliverable product.
Standard

Aerospace Guidance for Non-Deliverable Software

2005-06-06
HISTORICAL
ARP9005
This document contains recommended practices for the effective control of non-deliverable software. It addresses practices for control during the development, production, release maintenance, and retirement of non-deliverable software, as well as for software procured from outside manufacturers and incorporated in the production, evaluation, test, acceptance or calibration of processes. For the purposes of this document, the terms software and non-deliverable software are considered synonymous.
Standard

Aerospace Guidance for Non-Deliverable Software

2016-06-27
CURRENT
ARP9005A
This document contains recommended practices for the effective control of non-deliverable software. It addresses practices for control during the development, production, release maintenance, and retirement of non-deliverable software, as well as for software procured from outside manufacturers and incorporated in the production, evaluation, test, acceptance or calibration of processes. For the purposes of this document, the terms software and non-deliverable software are considered synonymous.
Standard

A Process Standard for the Storage, Retrieval and Use of Three-Dimensional Type Design Data

2003-09-04
HISTORICAL
ARP9034
This document describes requirements for standardized processes (and associated technologies) that ensure type design data are retrievable and usable for the life of a type certificate (50+ years). These processes are primarily concerned with, but not limited to, digital type design data retained in three-dimensional representations and associated data that is required for complete product definition, such as tolerances, specification call-outs, product structure and configuration control data, etc. This process standard includes process requirements for managing the evolution of technologies required to ensure the availability of the data for the life of the product. This data must be available to meet regulatory, legal, contractual and business requirements. This process standard is not intended to incorporate every company specific requirement and does not dictate specific organizational structures within a company.
X