Name:
ASD-STAN PREN 9116 PDF
Published Date:
05/13/2024
Status:
[ Active ]
Publisher:
Aerospace and Defence Industries Association of Europe - Standardization
General
The aviation, space, and defence 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 or manufacturing activity controls various aspects of the configuration and specifications related to the product. When a change to design or process is requested or required, the change is typically required to be evaluated against the impacts to the entire system.
Proposed changes to design data/information that the design activity identifies to be minor and have no effect on the product requirements or specifications, have the potential to be implemented and approved, where authorized to do so, but requires notification. Changes that affect customer mandated requirements or specifications shall be approved prior to implementation. In many cases, the design activity is not conducted by the DAH or design authority. The design activity may be several layers below the design approval. Irrespective of where the design activity is conducted in the supply chain, notification is required. The typical change notification flow is presented in Figure 1.
Submitting NOC data either electronically or conventionally on paper is subject to the terms and conditions of the customer’s contract. This also includes, where applicable, data access under the regulations of export control.
The process of exchanging, coordinating, and approving NOC data varies with the multiple relationships and agreements among all organizations concerned. An objective of this document is to provide the definition of a data set that can be integrated into any form of communication (e.g., electronic data interchange, submission of conventional paper forms). A sample form can be found in the Supply Chain Management Handbook (SCMH).
If all or part of this document is contractually invoked, design organizations and design holders (i.e., the organization responsible for the product end item design) that have responsibility for change management of products used on other higher-level designs shall use the information and processes defined in this document for submitting change notifications.
Application
This document defines the common NOC requirements for aviation, space, and defence organizations. The requirements that a design organization are to use when submitting a NOC to the customer for either change authorization or notification are included herein. A NOC informs the customer of physical or functional (e.g., design, material, software, maintenance) changes or any associated process changes to an established baseline configuration.
Retention of the NOC establishes a means of configuration control and captures the evolution of the part. This requirement is of utmost importance in commercial/civil aviation products where changes to type certificated products are mandated by regulations; however, these same concepts are also required in defence and space applications per contractual requirements.
Where there are changes to items which the organization does not have design input or is not permitted to make any changes to the design [e.g., build to print, Technical Standard Order (TSO) articles] then change requests are to be formally submitted to the customer and approved via the customer’s change request process.
This document is not applicable to commercial parts [off-the-shelf items not specifically designed for aviation, space, or defence products; aka Commercial off-the-Shelf (COTS)] for which changes in product definition is not affected or known. COTS items that are modified or altered are subject to the requirements herein. When this document is applied to an organization that distributes product, then this document is also a requirement to the organization from which the product is procured by the distribution organization.
Informative
In this document, the following terms are used:
— “shall” indicates a requirement;
— “should” indicates a recommendation;
— “may” indicates a permission; and
— “can” indicates a possibility or capability.
Words “example” or “e.g.” indicate suggestions given for guidance. Information marked “NOTE” is for guidance in understanding or clarifying the associated requirement.
| Edition : | P2 |
| File Size : | 1 file |
| Number of Pages : | 37 |
| Published : | 05/13/2024 |