Sae Eia-649-2-2016

EIA-649 -2
TECHNICAL REPORT
Issued 201 6-04
Configuration Management Requirements for NASA Enterprises
RATIONALE
This companion standard to "SAE/EIA-649B Configuration Management Standard," is needed to provide a resource that
standardizes Configuration Management (CM) requirements specific to National Aeronautics and Space Administration
(NASA) agreements and design activities. This Standard provides a template of CM requirements and user guidance for
tailoring the requirements for each unique use case. This standard has been revised to incorporate content changes
proposed by the G33 Committee that were not included in the original release.
FOREWORD
SAE International publishes this companion standard to the NASA-endorsed SAE/EIA-649B for NASA to provide uniform
CM requirements for NASA enterprise agreements and activities. The Office of the Chief Engineer-NASA Headquarters,
the NASA Field Centers, including Component Facilities, and the SAE governing CM Council, approve this Standard for
use.
This document is used as a stand-alone reference, invoked by an agreement where the customer intends to be consistent
with the NASA-endorsed ANSI/EIA-649 principles, and may be used for all NASA enterprises in all phases of the
program/project/activity life cycle.
We also acknowledge the NASA CM Community of Practice, the NASA CM Standards Project Team, and the SAE G33
Committee for their support in developing this companion standard.
__________________________________________________________________________________________________________________________________________
SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engi neering sciences. The use of this report is
entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefrom, is the sole responsibility of the user.”
SAE reviews each technical report at least every five years at which time it may be revised, reaffirmed, stabilized, or cancelled. SAE invites your written comments and
suggestions.
Copyright © 201 6 SAE International
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior written permission of SAE.
TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) SAE values your input. To provide feedback
Tel: +1 724-776-4970 (outside USA) on this Technical Report, please visit
Fax: 724-776-0790 http://www.sae.org/technical/standards/EIA649-2
Email: CustomerService@sae.org
SAE WEB ADDRESS: http://www.sae.org
SAE INTERNATIONAL EIA-649  -2 Page 2 of 48
INTRODUCTION
This Standard provides a consistent and systematic set of requirements that are used for the management of
Configuration Items (CIs) delivered to, or produced by, the Agency that does the following:
a. Identifies the configuration of a product at various points throughout its life cycle;
b. Systematically controls changes to the configuration of the product;
c. Maintains the integrity and traceability of the configuration of the item throughout its life; and
d. Preserves the information for the product configuration.
The requirements support the planning and implementation of a Configuration Management (CM) system as described by
the functions and principles of SAE/EIA-649B. The requirements are grouped using the five functions:
(1 ) CM Planning;
(2) Configuration Identification (including interface management);
(3) Change Management (Configuration Control);
(4) Configuration Status Accounting (CSA) (including configuration traceability); and
(5) Configuration Verification and Audits.
Requirements are numbered and indicated by the word "shall." Explanatory or guidance text is indicated in italics
beginning in Section 4.
NOTE: For simplicity, when this document uses the term Configuration Item (CI), the requirement or guidance presumes
the inclusion of all computer software configuration items (CSCIs), unless otherwise specified. All CSCIs which are
selected by the Customer are subject to the same criteria as are hardware elements designated as CIs.
Applicable general NASA CM policy that contains parent requirements and definitions are captured in Table 1 .
Table 1 - NASA configuration management policy

Standard Number Standard Title
NPD 71 20.4D NASA Engineering and Program/Project Management Policy
NPR 71 20.5E NASA Space Flight Program and Project Management Requirements
NPR 71 20.8 NASA Research and Technology Program and Project Management Requirements
NPR 71 20.9 NASA Product Data and Life-Cycle Management (PDLM) for Flight Programs and
Projects
NPR 71 23.1 B NASA Systems Engineering Processes and Requirements
NPR 71 50.2B NASA Software Engineering Requirements

TABLE OF CONTENTS
1. SCOPE .......................................................................................................................................................... 4
1 .1 Responsibility of Customer and Suppliers..................................................................................................... 4
1 .1 .1 Responsibility of Customer............................................................................................................................ 4
1 .1 .2 Responsibility of Supplier .............................................................................................................................. 4
1 .2 Requirements Approach ............................................................................................................................... 4
1 .2.1 Tailoring ......................................................................................................................................................... 4
1 .2.2 Requirements Verb Usage ............................................................................................................................ 5
2. REFERENCES .............................................................................................................................................. 5
2.1 Applicable Documents .................................................................................................................................. 5
2.1 .1 SAE Publications ........................................................................................................................................... 5
2.1 .2 Other Documents .......................................................................................................................................... 5
2.2 Related Publications ...................................................................................................................................... 6
2.3 Definitions ...................................................................................................................................................... 6
2.4 Acronyms/Abbreviations .............................................................................................................................. 1 1
3. GENERAL CONFIGURATION MANAGEMENT REQUIREMENTS ........................................................... 1 2

3.1 Configuration Management Application ...................................................................................................... 1 2
3.1 .1 Supplier Configuration Management Planning ............................................................................................ 1 4
3.2 Configuration Identification .......................................................................................................................... 1 5
3.2.1 General Requirements ................................................................................................................................ 1 6
3.2.2 Configuration Item Selection ....................................................................................................................... 1 6
3.2.3 Configuration Baselines and their Configuration Information ...................................................................... 1 6
3.2.4 Configuration Identifiers .............................................................................................................................. 1 9
3.3 Configuration Change Management ........................................................................................................... 22
3.3.1 Configuration Control Boards ...................................................................................................................... 23
3.3.2 Preparation of Change and Variance Request ........................................................................................... 24
3.3.3 Major and Minor Changes ........................................................................................................................... 26
3.3.4 Change Request Supporting Data .............................................................................................................. 27
3.3.5 Software Change Control ............................................................................................................................ 27
3.3.6 As-Built Change Management .................................................................................................................... 27
3.3.7 As-Deployed Change Management ............................................................................................................ 28
3.3.8 Modification Kit and Instructions.................................................................................................................. 29
3.4 Configuration Status Accounting ................................................................................................................. 29
3.4.1 CSA Requirements ..................................................................................................................................... 29
3.5 Configuration Verification and Audits .......................................................................................................... 31
3.5.1 In-Process Configuration Management Audits ............................................................................................ 31
3.5.2 Common Audit Responsibilities .................................................................................................................. 32
3.5.3 Functional Configuration Audit .................................................................................................................... 35
3.5.4 Physical Configuration Audit ....................................................................................................................... 38
3.5.5 Post-Audit Action ......................................................................................................................................... 43
3.5.6 Configuration Audit Summary ..................................................................................................................... 43
3.6 Enabling General Requirements ................................................................................................................. 43
3.6.1 Engineering Release ................................................................................................................................... 43
3.6.2 Interface Management ................................................................................................................................ 45
3.6.3 Performance Measurement ........................................................................................................................ 47
4. NOTES ........................................................................................................................................................ 47
4.1 CM Related Data Management ................................................................................................................... 47
4.2 Revision Indicator ........................................................................................................................................ 48
1. SCOPE
This Standard applies to all products produced by NASA Headquarters and NASA Centers, including Component Facilities
and Technical and Service Support Centers. This Standard may also apply to the Jet Propulsion Laboratory and
suppliers/service providers to the extent specified in their agreements with NASA. This Standard may be cited in the CM
requirements of NASA Headquarters, NASA Centers, Programs, Projects, and Supplier agreements.
NOTE: The use of the term “a greement(s)” includes contracts and less formal items, such as task agreements.
This Standard is also applicable to NASA investment areas covered under NPR 71 20.5, NPR 71 20.7, and NPR 71 20.8.
This Standard may be further applied to other NASA investments at the discretion of NASA management.
This Standard applies throughout all phases of the program and project life cycle.
NOTE: While this Standard is released by SAE International, it is an endorsed standard for use by NASA.
1 .1 Responsibility of Customer and Suppliers
1 .1 .1 Responsibility of Customer
The Customer establishes and controls the product's functional and performance requirements, and has oversight and
agreement compliance responsibility during product development, deployment, operation, upgrade/ modification,
maintenance, and disposal. The Customer defines agreement CM terminology and unique CM application for
agreement(s) through tailoring of this Standard.
The Customer may cite the untailored requirements of this companion Standard, or create a set of tailored requirements
either of which may be included as part of internal agreements for NASA programs and projects.
1 .1 .2 Responsibility of Supplier
The Supplier is responsible for complying with the requirements contained in this Standard as tailored by the Customer. In
addition, the Supplier is responsible for ensuring that their sub-tier suppliers also comply with the tailored requirements,
when needed to assure that the overall CM system is efficient and interoperable.
1 .2 Requirements Approach
1 .2.1 Tailoring
The requirements in this Standard are included in agreements only to the extent specified for each unique agreement. The
Customer is responsible for tailoring the requirements from this Standard to develop and invoke a unique set of CM
requirements for each agreement or internal development activity. Factors that influence tailoring include the program's or
project’s life cycle phase, agreement type and structure, complexity, scope, intended use, risk -tolerance, and mission
criticality for the identified CIs. A specific tailoring guideline matrix is provided at the following location on the NASA
Engineering Network - SAE 649-2 Tailoring Matrix. This matrix, which is structured in accordance with NASA project
classifications, is provided as an aid to the Customer in tailoring these requirements.
The parent Standard to this companion Standard, ANSI/EIA-649, contains principles listed in this document that are
copyright-protected by SAE. The principles contained in this Standard are intended to be for reference only. Except as
permitted under the applicable laws of the user's country, neither the SAE/ANSI/EIA-649B principles nor any extract may
be reproduced, stored in a retrieval system, or transmitted in any form or by any means, whether electronic, photocopying,
recording, or otherwise, without prior written permission being secured; they are intended to be for reference only.
1 .2.2 Requirements Verb Usage
a. “Shall” is used to indicate a requirement that is binding, which must be implemented and its implementation verified in
the approach, planning, and implementation.
b. “Should” is used to indicate best practice or a goal that is desirable but not mandatory.
c. “May” is used to indicate permission.
d. “Will” is used to indicate a statement of fact or declaration of purpose on t he part of the Customer that is reflective of
decisions or realities that exist and are to be taken as a given and not open to debate or discussion.
e. “Is” or “Are” are used to indicate descriptive content.

2. REFERENCES
2.1 Applicable Documents
The following publications form a part of this document to the extent specified herein. The latest issue of SAE publications
shall apply. The applicable issue of other publications shall be the issue in effect on the date of the purchase order. In th e
event of conflict between the text of this document and references cited herein, the text of this document takes
precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption
has been obtained.
2.1 .1 SAE Publications
Available from SAE International, 400 Commonwealth Drive, Warrendale, PA 1 5096-0001 , Tel: 877-606-7323 (inside USA
and Canada) or +1 724-776-4970 (outside USA), www.sae.org.
SAE/EIA-649B Configuration Management Standard (referred to in this Standard as EIA-649)
2.1 .2 Other Documents
ANSI/EIA-836 Configuration Management - Data Exchange and Interoperability
ASME Y1 4.24 Types and Applications of Engineering Drawings
ASME Y1 4.1 00 Engineering Drawing and Related Information Practices
DD Form 250 (DOD) Material Inspection and Receiving Report
DD Form 1 1 49 Requisition and Invoice/Shipping Document (for Government to Government transfer)
DRD-STD-AD Functional Configuration/Physical Configuration Audit
DRD-STD-CR Change Request
DRD-STD-CMP Configuration Management Plan
DRD-STD-CMPA Configuration Management Process Audit
DRD-STD-CSA Configuration Status Accounting
DRD-STD-EDAL Engineering Drawing and Associated List
DRD-STD-MINC Modification Kit and Instructions

DRD-STD-SDT Specification and Drawing Tree
DRD-STD-VDD Version Description Document
DRD-STD-VR Variance Request
MIL-STD-1 30 Identification Marking of U.S. Military Property
MIL-STD-31 000 Technical Data Packages
NAS 3500 Technical Data Package: Composition, Communication, and Application
NID 1 600.55 Sensitive But Unclassified (SBU) Controlled Information
NPR 1 441 .1 Records Retention Schedules
NPR 71 20.5 Spaceflight Program and Project Management Requirements
NPR 71 20.7 Inform ation Technology and Institutional Infrastructure Program and Project Requirements
NPR 71 20.8 Research and Technology Program and Project Management Requirements
NPR 71 50.2 NASA Software Engineering Requirements
NPR 8735.1 Exchanging Parts, Materials, Software, and Safety Problem Data Utilizing the Government-Industry
Data Exchange Program (GIDEP)
2.2 Related Publications
None.
2.3 Definitions
Because this Standard has application across many diverse industries and governmental activities in which term inology
differs, common terminology is used as much as possible. The terms apply to whatever is common to any particular user
environment through the concepts inherent in their definitions. This section aids in understanding equivalency of terms by
defining the terms used within this Standard and addressing aliases (commonly used terms that convey the same or
similar meaning) and other closely related terms where known aliases exist. For purposes of this Standard, the definitions
contained in the parent standard SAE/EIA-649B, as well as the additional terms below apply.
When planning and documenting a CM system, a Customer may substitute aliases or any other term s familiar to their
environment for the terminology used within this Standard. There is also no intent to rigidly adhere to the terminology withi n
this Standard if, in specific instances, use of an alias provides clarity. However, the application of terminology to the
requirements contained herein should be carefully considered, since substitutions may affect the meaning or the clarity of
a particular requirement.
For additional definitions of other CM term s and product attributes, see ANSI/EIA-836. That standard logically extends the
CM principles of this Standard, establishes a common data exchange language for interoperability between enterprises,
and provides the relationships between defined terms and their properties.
Definitions of common words may be found in Webster’s New International Dictionary (unabridged). The following
definitions are unique to CM and are defined in the context of the CM environment. They are provided to prevent
misunderstanding of the intent and content of this Standard. The reader should also refer to Table 1 for additional
definitions peculiar to the NASA environment. If a definition conflict exists, the definitions used herein supersede those in
the other referenced documents, with regard to NASA CM.
ALLOCATED BASELINE (ABL): The approved requirements for a product, subsystem, or component. It describes
the functional, performance, interoperability, and interface requirements that are allocated from higher-level requirements,
and the verifications required to demonstrate achievement of those requirements, as established at a specific point in time
and documented in the allocated configuration inform ation (ACI).
NOTE: The ABL for each lower-level system element (hardware and software) is usually established and put
under configuration control at the system element Preliminary Design Review (PDR).
ALLOCATED CONFIGURATION INFORMATION: The information describing a CIs functional, perform ance, and
interoperability requirements that are allocated from those of a system or higher level CI; interface requirements with
interfacing CIs; and the verifications required to confirm the achievement of those specified requirements.
APPROVAL AUTHORITY: The organization or person, such as a Customer Configuration Control Board (CCB)
Chairperson, authorized to approve: (1 ) a baseline; (2) a configuration change to a product; (3) changes to product
definition inform ation, and other related documents; (4) release or cancellation of documents for use in a specific program;
and (5) results of audits.
AS-DESIGNED CONFIGURATION: The configuration of an item as documented by the design activity.
AS-BUILT CONFIGURATION: The configuration of an item as actually produced. It consists of the as-designed
configuration at the time of production as modified with approved engineering changes and variances.
NOTE: If the as-designed configuration consists of design alternatives, the as-built configuration reflects the actual
produced item. In addition, the as-built configuration may be referred to as the as-delivered configuration in some
cases. In other cases, the as-delivered and as-maintained configurations may be a further modification of the
as-built configuration. When this distinction exists, the exact definition of each has to be described in the CM Plan
(CMP), or equivalent planning document.
AS-DEPLOYED CONFIGURATION: The configuration of an item as currently in -service. It consists of the as-built
configuration, plus any approved changes, retrofits, or modifications implemented after the item is put into service; also
referred to as the as-maintained, as-supported, as-installed, or in-service configuration.
AUDIT: A systematic, independent and documented process for obtaining evidence and evaluating it objectively to
determine the extent to which pre-defined criteria are fulfilled. It is conducted by authorized individuals for the purpose of
assessing compliance with established design/performance requirements, commercial and appropriate government and
Agency standards, and functional, allocated, and product baselines, as appropriate.
BASELINE: A formally controlled and maintained set of data that serves as the basis for defining change. When used as a
verb, it is the act of initially establishing and approving a set of data.
CHANGE REQUEST (CR): Inform ation describing the justification to request a change submitted to a Configuration
Approval Authority for disposition (i.e., approval/disapproval/deferral). Information, by which a change is proposed,
described, justified, and submitted to the approver. Aliases - Engineering Change Proposal (ECP), Engineering Change
Request (ECR).
COMMERCIAL AND GOVERNMENT ENTITY (CAGE) CODE: A five-position alphanumeric code, listed in Cataloging
Handbook H4/H8, that provides a unique activity identifier to commercial and government activities that manufacture or
develop items or provide services or supplies for the Government or the Design Activity Identification.
COMPUTER SOFTWARE CONFIGURATION ITEM (CSCI): An aggregate of software that satisfies an end-use function
and is designated for purposes of specification, interfacing, qualification testing, CM, or other purposes. It is composed of
one or more software units which may consist of: (1 ) source code, object code, control code, control data, or a collection of
these items; (2) an aggregation of software, such as a computer program or database, that satisfies an end -use function
and is designated for specification, qualification testing, interfacing, CM or other purposes; or (3) an identifiable part of a
software product. It may also be interchangeably termed as a Software Configuration Item (SWCI).
CONFIGURATION: The functional and physical characteristics of existing or planned hardware, software, or a
combination thereof, as set forth in technical information and ultimately achieved in a product.
CONFIGURATION CONTROL: The systematic proposal, justification, evaluation, coordination, approval (or disapproval)
of proposed changes or requested variances and the implementation of all approved changes or variances in the
configuration of a CI after establishment of the configuration baseline(s) for the CI.
CONFIGURATION CONTROL BOARD (CCB): A chartered board composed of technical and administrative
representatives who recommend approval or disapproval of proposed engineering changes and variances to a CIs current
approved and baselined configuration information.
CONFIGURATION INFORMATION. The technical information that identifies and defines the ite m’s functional performance
and physical characteristics. The configuration information is developed, approved and maintained through three distinct
evolutionary and increasing levels of detail. The three levels of configuration information are the function al configuration
information, the allocated configuration information, and the product configuration information.
NOTE: Variant of EIA 649 "product configuration information" definition.
CONFIGURATION MANAGEMENT PLAN (CMP): The description, definition, and processes of how CM is accomplished
and how consistency between the product definition, the product’s configuration, and the CM information is achieved and
maintained throughout the applicable phases of the product’s life cycle or the duration of the agre ement. (Aliases -
Software Configuration Management Plan (SCMP), Configuration Management Planning.)
DESIGN ACTIVITY: An entity that has, or has had, responsibility for the design of an item.
DESIGN ACTIVITY IDENTIFICATION: The application of a unique identifier that distinguishes an activity or organization
from another activity or organization. Examples of activity identification include activity name, activity address, or CAGE
Code.
DETAIL SPECIFICATION: Specification information that states design requirements, such as materials to be used, how a
requirement is to be achieved, or how an item is to be fabricated or constructed.
NOTE: A specification that contains both performance and detail requirements is still considered a detail specification.
Both Agency enterprise specifications and program/project-unique specifications may be designated as a detail
specification.
EFFECTIVITY (within NASA): The identification of the number of products within a given set of products in production or
delivered status that are to be changed as a result of a CCB action to implement changes in a particular group of products
(CIs).
NOTE: An effectivity designation defines the range within a set of CIs or an event, such as a unique mission identification,
to which a particular configuration change applies. The range is expressed as serial numbers (S/Ns), or lot
numbers, or model designations. Events are usually expressed as alpha-numeric values defined by the program.
ENGINEERING CHANGE: A change to the current approved confi guration of a CI at any point in the item’s life cycle. Also
known as configuration change.
ENGINEERING CHANGE PRIORITY: The priority (emergency, urgent, routine) assigned to an engineering change to
indicate the urgency with which the change is to be reviewed, evaluated, and, if approved, ordered, and implemented.
ENGINEERING RELEASE: An action whereby configuration information or an item is officially made available for its
intended use.
FUNCTIONAL BASELINE (FBL): A description of the system’s performance (functional, interoperability, and
interface characteristics) and the verification required to demonstrate the achievement of those specified characteristics ,
as documented in the FCI.
FUNCTIONAL CONFIGURATION INFORMATION (FCI): The inform ation describin g the system's functional, performance,
interoperability, and interface requirements as well as the verifications required to demonstrate the achievement of those
specified requirements.
INTEROPERABILITY: The ability of the centers and Agency enterprises to exchange information with each other (joint
operations) or with an allied disparate systems (combined operations) to enable them to operate effectively together. This
also refers to the ability of their systems, equipment, and software to communicate and interoperate.
ITEM: A term used to denote any product, including systems, materials, parts, subassemblies, sets accessories, software
items, etc.
MANUFACTURING BUILD RECORDS: A collection of in-process quality assurance (QA) records from various parts and
assemblies. It includes all documentation essential in the manufacturing of the CI. This typically includes the following:
a. Build paper.
b. Inspection paper.
c. Manufacturing planning paper.
d. Manufacturing drawings (and/or computer-aided design (CAD) models).
e. Material Usage Agreements (MUA).
f. Material Identification Usage List (MIUL).
g. Material Review Board (MRB) dispositions.
h. Other documentation as applicable.
NON-DESIGN RELEASE PRODUCT A product available with little or no development effort required by the
customer. They include:
a. Products obtained from a domestic or foreign commercial marketplace.
b. Products already developed and in use by NASA activities and Government agencies.
c. Products already developed by foreign governments that can be supplied in accordance with mutual
cooperation agreements and Federal acquisition regulations.
PERFORMANCE SPECIFICATION: A specification that states requirements in terms of the required results with criteria
for verifying compliance but without stating the methods for achieving the required results. It defines the functional
requirements for the item, the environment in which it must operate, and interface and interchangeability characteristics.
NOTE: Both Agency specifications and program -unique specifications may be designated as performance
specification.
SAE INTERNATIONAL EIA-649  -2 Page 1 0 of 48
PRODUCT: The manufactured or constructed result of the application of configuration management processes, such as:
a. Hardware, e.g., engine mechanical part.
b. Software, e.g., computer program or model.
c. Processed materials, e.g., a lubricant.
d. Facilities, e.g., a laboratory or machine shop.
PRODUCT BASELINE (PBL): Describes the detailed design at a specific point in time for production,
fielding/deployment, and operations and support, as documented in the PCI.
PRODUCT CONFIGURATION INFORMATION (PCI): A CI’s detailed design information including all necessary physical
(form, fit, or function) characteristics and selected functional characteristics designated for production acceptance testing
and production test requirements. Initially, it includes build-to specifications for hardware (product, process, material
specifications, engineering drawings, 3D CAD models, and other related data) and software (software module design -
code-to specifications). The as-delivered and subsequent such baselines add product operational inform ation needed to
operate and maintain the product.
NOTE: Product configuration information is a subset of the EIA 649 product definition inform ation definition.
PROGRAMMABLE LOGIC DEVICE (PLD): Hardware integrated circuits that are programmable by the user. (Alias –
Firmware.)
REDLINING: Notation or marking on drawings, procedures, or work authorization documents to indicate changes to the
originally released documentation, where those changes are authorized to be implemented during design, fabrication,
production, and testing.
REPAIR: A procedure which reduces but does not completely eliminate a nonconformance from a CI and which has been
reviewed, concurred, and approved for use by the Customer. The purpose is to reduce the effect of the nonconformance.
It is distinguished from rework in that the characteristic upon completion still does not completely conform to the applicable
drawings, specifications, or agreement requirements. Unique configuration identification must be applied to completed
items.
REWORK: A procedure applied to a nonconformance that completely eliminates it and results in a product that conform s
completely to the drawings, specifications, or agreement requirements.
NOTE: The Supplier has to disclose that the rework occurred when outside the normal process to manufacture the part.
SERIAL NUMBER: A unique number identifying individual units within a series of like items. This number does not
establish the part number but tracks the number of items that were produced under the part number. These numbers
should be assigned to all functional and major assemblies requiring special tracking code. They are subject to software
CM to the extent applicable to the kind of software code (e.g., lower level software language versus net list data).
SOFTWARE: (1 ) All or part of the programs, procedures, rules, and associated information of an information processing
system; or (2) computer programs, procedures, and possibly associated information and data pertaining to the operation of
a computer system.
NOTE: The definition of software is independent of the media on which the software is stored or the device in which the
software executes (such as a PLD).
SOURCE CONTROL DRAWING: A drawing that provides an engineering description, qualification requirements, and
acceptance criteria for commercial items or sub-supplier-developed items procurable from a specialized segment of
industry that provide the perform ance, installation, interchangeability, or other characteristics required for critical
applications. The drawing provides a list of approved sources of supply and the sub- supplier’s item identification for the
item(s) that have been qualified and approved for use in the critical application(s).
NOTE: The source control drawing establishes the source control item identification.
SUB-SUPPLIER: Any organization providing services or goods to the Customer, including other government organizations
or a supplier.
TECHNICAL DATA: Product CI recorded (regardless of the form or method of recording) of a scientific or technical nature
(including software CI) relating to supplies procured by an agency. The term does not include computer software or data
incidental to contract administration, such as financial or management inform ation.
a. Technical data required to define and document an engineering design or product configuration (sufficient to allow
duplication of the original items) and used to support production, engineering, and logistics activities. This aspect of
the term is called product definition information.
b. Technical data that provides instructions for the installation, operation, maintenance, training, and support of a system
or equipment, and which can be formatted into a technical manual. This aspect of the term is called product
operational information.
c. Technical manuals normally include operation and maintenance instructions, parts lists or parts breakdown, and
related technical inform ation or procedures exclusive of administrative procedures. This data may be presented in any
form (e.g., hard copy, audio and visual displays, magnetic tape disks or other electronic devices). Technical orders
that meet the criteria of this definition may also be classified as technical manuals.
TECHNICAL DATA PACKAGE (TDP): A technical description of an item adequate for supporting an acquisition,
production, engineering, and logistics support (e.g., engineering data for provisioning, training, and technical manuals).
The description defines the required design configuration or performance requirements and procedures to ensure
adequacy of item performance. It consists of applicable technical data, such as models, drawings, associated lists,
specifications, standards, performance requirements, QA provisions (documented requirements, procedures, and criteria
necessary for demonstrating that products conform to design requirements), software inform ation, and packaging
details.
VERSION: A specific configuration of a product or document. (Version is generally applied to software.)
NOTE: Modifications to a version of software (resulting in a new version) require CM actions by the Supplier, the
Customer, or both.
2.4 Acronyms/Abbreviations
ABCD As Built Configuration Data

ABL Allocated Baseline
ACI Allocated Configuration Information
ADP Acceptance Data Package
ALERT Acute Launch Emergency Restraint Tip
ANSI American National Standards Institute
ATP Acceptance Test Procedure
CA Compliance Audit
CAD Computer Aided Design
CAGE Commercial and Government Entity
CCB Configuration Control Board
CDR Critical Design Review
CI Configuration Item
CM Configuration Management
CMO Configuration Management Office
CMP Configuration Management Plan
CMPA Configuration Management Process Audit
COQ Certification of Qualification
CR Change Request
CSA Configuration Status Accounting
CSCI Computer Software Configuration Item
DAI Design Activity Identification
DM Data Management
DRD Data Requirement Description
EEE Electrical, Electronic, Electromechanical
FBL Functional Baseline
FCA Functional Configuration Audit
FCI Functional Configuration Inform ation
FEC Field Engineering Change
FEMA Failure Mode Effects Analysis
FEO Floor Engineering Order
GIDEP Government-Industry Exchange Program
HR Hazard Report
ICD Interface Control Document
ICWG Interface Change Working Group
IMS Integrated Master Schedule
IPL Indentured Parts List
IRD Interface Requirements Document
MI Mod Kit Instructions
MIUL Material Identification Usage List
MRB Material Review Board
MUA Material Usage Agreement
NASA National Aeronautics and Space Administration
ODA Original Design Activity
OEM Original Equipment Manufacturer
PCA Physical Configuration Audit
PCB Product Configuration Baseline
PBL Product Baseline
PCI Product Configuration Inform ation
PDLM Product Data and Lifecycle Management
PDR Preliminary Design Review
PIN Part or Identifying Number
PLD Programmable Logic Device
QA Quality Assurance
RID Review Item Discrepancy
SBU Sensitive but Unclassified
SCANS Suspect Condition Action Notices
SCMP Software Configuration Management Plan
SRS Software Requirements Specification
S/N Serial Number
SOW Statement of Work
SUM Software User Manual
SW Software
SWCI Software Configuration Item
TBD To Be Determined
TDP Technical Data Package
UII Unique Item Identifier
VCR Verification Compliance Report
VDD Version Description Document
VR Variance Request
3. GENERAL CONFIGURATION MANAGEMENT REQUIREMENTS
3.1 Configuration Management Application
ANSI/EIA-649 Principle CM-1 : Configuration Management implementation requires a balanced and continuous application
of CM functions and their underlying principles throughout the product life cycle.
ANSI/EIA-649 Principle CMP-1 : The foundation for CM planning, which delineates the specific CM application methods
and their levels of emphasis, is an understanding of the context and environment of the product to which the CM process is
to be applied.
The Supplier shall plan for and apply a defined, systematic approach for CM covering the life-cycle phases as required by
this Standard, tailored appropriately for the applicable CI(s), their scope and complexity, and the organizational
environment in which the CM processes are to be perform ed.
(1 ) The fol lowing CM functions shall be incorporated into and applied consistently across the Supplier’s CM organization,
as required, to implement a comprehensive CM system throughout all life cycle phases:
a. Configuration Identification (3.2)
b. Configuration Change Management (3.3)
c. Configuration Status Accounting (3.4)
d. Configuration Verification and Audits (3.5)
(2) The Supplier’s internal CM system shall be tailored appropriately to the Customer’s requirements and the identified CIs
based on consideration of the following factors:
a. The complexity and nature of the product or the selected CIs.
b. The information and resource needs of the applicable life cycle phases.
c. The relevant organizations that may be involved, within and outside of the Supplier’s own organization, including
any enabling support organizations (e.g., Logistics, QA, Sustaining Engineering).
d. The interfaces between organizations and activities involved in the Supplier’s CM system.
e. The responsible authority assigned to verify impleme ntation of the Supplier’s CM system.
f. Change Control Boards and other groups, within and external to the Supplier’s organization, assigned
dispositioning responsibilities and authority over the product’s configuration.
(3) The Supplier shall comply with the CM requirements contained in this Standard as tailored by the applicable
agreement requirements.
(4) The Supplier shall require all relevant sub-tier suppliers to comply with the same CM requirements that are being
imposed on the Supplier, and which are suitably tailored to their assigned CM role and responsibilities.
(5) The Supplier shall comply with and support the Customer’s requests to audit the Supplier’s implemented CM system
as required to verify conform ance with agreement requirements.
3.1 .1 Supplier Configuration Management Planning
ANSI/EIA-649 Principle CMP-2: CM Planning documents how the organization will implement CM throughout the
applicable phases of the product life cycle to provide consistency among the product requirements, product confi guration
information, and the product.
ANSI/EIA-649 Principle CMP-3: To implement planned CM functions, resources are identified and applied and
responsibilities to perform CM activities are assigned.
ANSI/EIA-649 Principle CMP-4: CM Procedures document how each CM function is implemented to accomplish the
intent of the CM planning.
ANSI/EIA-649 Principle CMP-5: CM training assures that individuals understand their responsibility, authority,
accountability and the procedures for performing specified CM tasks.
ANSI/EIA-649 Principle CMP-6: Periodic assessment of the effectiveness of CM procedures and tools and of compliance
with the Configuration Management plan maintains the health of the CM process.
ANSI/EIA-649 Principle CMP-7: Performing configuration management includes responsibility for the configuration
management perform ance of subcontractors and suppliers.
ANSI/EIA-649 Principle CMP-8: Inform ation processes, including collection and processing, controlling status, providing
interoperability and exchange and long term preservation, are essential elements of effective CM planning and
management.
NOTE: The Customer may cite DRD-STD-CMP for specifying the delivery of CM data product(s) that derives from
meeting the requirements of this section.
Supplier CM planning identifies how the Supplier will implement CM to provide consistency among the product
requirements, product configuration information, and the product throughout the applicable phases of the project life cycle.
The CMP, or equivalent planning document, being developed reflects the Supplier’s planned application of the CM
principles and practices to the Customer’s identified product context and environment.
3.1 .1 .1 CM Plan
The Supplier shall develop a CMP, or equivalent planning document, that defines how the CM functions will be
implemented in accordance with CM planning principles described in SAE/EIA- 649B, the Supplier’s documented
organizational policies and procedures, the Statement of Work (SOW), and the requirements contained in the appli cable
agreement.
3.1 .1 .2 General Requirements
(1 ) The Supplier shall conduct CM planning as required and develop a CMP, or equivalent planning document, for the
product in accordance with the requirements defined in this Standard, as tailored by the agreement.
(2) The Supplier shall develop a CMP, or equivalent planning document, that is appropriately tailored for the scope,
magnitude, and complexity of the selected CI(s) and for the organizational environment in which the CM processes are
to be applied.
(3) The Su pplier’s CMP, or equivalent planning document, shall describe the processes, methods, forms, and procedures
to be used for management of the functional, allocated, and physical characteristics of the CIs and for executing each
of the functions described in 3.6, Enabling General Requirements.
(4) The Supplier shall submit a completed CMP, or equivalent planning document, and subsequent changes thereto to the
Customer for review and approval within the timeframe(s) stated in the agreement.
(5) The CMP shall be maintained in a current status throughout the life of the agreement and resubmitted for approval
when required in accordance with agreement requirements.
3.2 Configuration Identification
ANSI/EIA-649 Principle CI-1 : Configuration identification is the basis from which the configuration of products are defined
and verified; products and their product configuration information are labeled; changes are managed; and traceability is
maintained throughout the product’s life cycle.
ANSI/EIA-649 Principle CI-2: Product configuration information serves as the basis for development, production,
operation and maintenance/support of the product.
ANSI/EIA-649 Principle CI-3: Enterprise identifiers designating the responsible designer, manufacturer, or preparer
provide uniqueness to the identifiers of products and product configuration information.
ANSI/EIA-649 Principle CI-4: Product identifiers are assigned so that one product can be distinguished from other
products; one configuration of a product can be distinguished from another; the source of a product can be determined;
and the correct corresponding product information can be retrieved.
ANSI/EIA-649 Principle CI-5: Individual units of a product are assigned a unique product unit identifier when there is a
need to distinguish one unit of the product from another.
ANSI/EIA-649 Principle CI-6: When a product is modified, it retains its original product unit identifier, even though its part
identifying number is altered to reflect a new configuration.
ANSI/EIA-649 Principle CI-7: A series of like units of a product is assigned a unique product group identifier when it is
unnecessary or impractical to identify individual units, but necessary to correlate units to a process, date, event, or test.
ANSI/EIA-649 Principle CI-8: All documents reflecting product performance, functional, or physical requirements and
other product information are uniquely identified so that they can be correctly associated with the applicable configuration
of the product.
ANSI/EIA-649 Principle CI-9: A product structure, determined from product configuration information, represents the
composition, relationships and quantities of a product and its components.
ANSI/EIA-649 Principle CI-1 0: Products and product components that receive special CM attention because of their
requirements, functionality, or product relationships are referred to as configuration items.
ANSI/EIA-649 Principle CI-1 1 : A baseline is established by agreeing to the definition of the attributes of a product at a
point in time and identifies a known configuration to which changes are addressed.
ANSI/EIA-649 Principle CI-1 2: The configuration of any product, or any document, plus the approved changes, is the
current baseline.
NOTE: The Customer may cite DRD-STD-SDT, DRD-STD-EDAL, and DRD-STD-VDD for specifying the delivery of CM
data product(s) that derives from meeting the requirements of this section.
Configuration identification provides the basis from which the configuration of products is defined and verified; products
and their product configuration information are labeled; changes are managed; and traceability is maintained.
Configuration identification is an iterative process conducted throughout the product life cycle. Activities associated with
the configuration identification function typically include the selection of CIs and documents; the assignment and
application of unique identifiers to a product, its components, and associated configuration information; and the
maintenance, release, and preservation of this inform ation, and the interrelationships which exist among the product
configuration inform ation and baseline elements as revisions occur.
The purpose of the configuration identification function is to incrementally establish and maintain a definitive basi s for
configuration control and status accounting for each CI and its associated configuration information as the product evolves
throughout all applicable life cycle phases.
The top-level product requirements defined by the Customer in a requirements docu ment(s) and/or in perform ance and
interface specifications for acquisitions, are utilized by the development organization (e.g., in -house project, supplier, sub-
supplier) to create internal design release baselines. When approved by the Customer, these design release baselines
become the formal configuration baselines that are maintained and controlled throughout the product/system life cycle.
3.2.1 General Requirements
(1 ) The Supplier shall implement and execute configuration identification activities in accordance with defined
organizational policies and procedures and the requirements of this Standard, as tailored in the agreement.
(2) The configuration Identification procedures and forms referenced in the Supplier’s CMP, or equivalent planning
document, shall be made available to the Customer, upon request.
3.2.2 Configuration Item Selection
(1 ) The Supplier shall select and submit candidate CIs and CSCIs to the Customer for review and final selection
concurrence.
(2) The Supplier shall identify as a CI any item that satisfies a system end-use function and requires separate CM,
because the item either meets or impacts one or more of the following criteria:
a. The item is critical to the functioning or performance of the product or its failure would have significant
perform ance or operational impact.
b. The item’s failure might result in serious injury, loss of life, or loss of primary product capability.
c. The item either incorporates or relies on technology that is considered to be complex, high -risk, high-cost, or
critical to achieving the Customer’s performance, operational, or supportability goals.
d. The item requires integrated logistics or other specialized support (e.g., maintenance or special test equipment).
e. The item has been designated for separate procurement by the Customer.
f. The item requires the application of specific or unique designations, versions, and/or numbering and naming
schemes.
g. The item interfaces with other systems and/or Customer or sub-tier supplier furnished items or is susceptible to
change.
NOTE: The final selection of CIs is made by the Customer, unless otherwise specified in the agreement requirements.
(3) The Supplier shall describe and graphically depict the structure and hierarchy of each candidate CI in a manner that
illustrates the interrelationships of its component parts and associated configuration inform ation.
a. The candidate CIs and these graphical illustrations shall be submitted as a part of the Supplier’s CMP, or
equivalent planning document.
NOTE: Acceptable methods for depicting this hierarchical structure include, but are not limited to, specification trees,
product structure diagrams, functional block diagrams, and system architecture models.
(4) The Supplier shall determine the appropriate configuration control and approval authority for each CI and the
requirements for submitting the CIs and their referenced information for review and approval.
3.2.3 Configuration Baselines and their Configuration Information
CM normally employs three types of formal configuration baselines: Functional, allocated, and product. These provide for
the progressive definition of the requirements and design information describing the various CIs designated for a product.
The Supplier also establishes and maintains an internal development baseline known as the Design Release Baseline to
control the developing product design as it evolves from the ABL into the build- to PBL. The Supplier’s initial Design
Release Baseline and the designated authorities that are authorized to approve changes to this baseline are submitted to
the Customer for review and approval.
The configuration identification is developed and maintained in three separate evolutions, as follows: First, development of
the FBL; second, the ABL; and third, the PBL. These provide for the progressive definition and documentation of the
requirements and design information describing the various hardware and CSCIs designated for a product.
Upon Customer approval and Supplier implementation of the configuration information, each of the formal baselines will be
established in successive order. At any time, the current or real- time configuration identification or “baseline” will be
composed of the last Customer-approved baseline, plus all subsequent approved changes.
(1 ) The Supplier shall recommend to the Customer the types and formats of configuration inform ation that are required to
define each CI’s performance, functional and physical attributes; and internal and external interfaces.
NOTE: Typically, this recommendation is included wi thin or submitted with the Supplier’s initial CMP, or equivalent
planning document.
(2) The Supplier shall:
a. Generate the configuration information that defines the configuration baselines being established by the Customer,
as tailored in the agreement.
b. Establish and maintain each succeeding baseline, so that it is traceable to, and is a detailed extension of, its
predecessor(s).
c. Reflect accurate product definition information in all applicable testing, manufacturing, operational,
troubleshooting, and sustainment inform ation.
d. Uniquely identify and place each item of configuration and its related technical information under configuration
control within established CM repositories or libraries in accordance with agreement requirements.
3.2.3.1 Functional Configuration Information
The FCI generally is documented in the form of a system specification and referenced information (e.g., Interface
Requirements Specifications) that describe a product’s performance requirements (functional, interoperability, and
interface characteristics).
Unless otherwise stipulated in the agreement, the FBL is developed and controlled by the Customer.
NOTE: In certain situations, the Supplier may be responsible for creating all or a portion of the configuration information
require d for defining the product’s FBL. When responsibility for developing the functional configuration baseline is
assigned to the Supplier, the requirements that follow should be included in the agreement.
The Supplier shall generate the information required for the FBL for each CI by:
(1 ) Describing the CI’s functional, performance, interoperability, and interface requirements.

(2) Describing the verifications required to demonstrate achievement of those requirements.
(3) Identifying the configuration inform ation for key lower-level CIs and selected items that are to be integrated or
interfaced with the CI.
(4) Describing any specialized software, if any, and the operating environment that was used to author the above
requirements.
(5) Describing any design constraints.

3.2.3.2 Allocated Configuration Information
NOTE: The ACI defines the requirements allocated from the FCI or from a higher-level CI to lower-level CIs. The ACI for
each CI is captured in the form of a product requirements specification, and other referenced information (e.g.,
Interface Requirements Specifications, Interface Control Documents (ICDs), and hardware/software requirements
specifications for lower-level CIs).
The Supplier shall generate the information required for the ABL for each CI by:
(1 ) Describing its functional, performance, interoperability, and interface requirements that are allocated from a product or
system requirement or are allocated from a higher-level CI to a lower-level configuration item.
(2) Describing the QA provisions and verifications required to demonstrate achievement of the allocated functional
requirements.
(3) Describing specialized software, if any, and the operating environment that was used to author the inform ation
described in the above requirements.
(4) Describing any additional design constraints.
3.2.3.3 Product Configuration Information
The PCI prescribes all necessary physical characteristics of a CI, the selected functional characteristics designated for
production acceptance testing, and the production acceptance tests. The Customer typically specifies the required detail
content and format for the delivery of the PCI in the contract/agreement.
The Supplier shall generate the information required for the PBL for each CI by:
(1 ) Describing the CI’s detailed design, including the necessary physical characteristics (form and fit) of the CI and the
verifications demonstrating required perform ance.
(2) Describing the selected functional characteristics designated for production, acceptance testing, and the production
test requirements.
(3) Identifying and documenting either the provisions and specifications for or the design of any special follow-on items or
activities required for the acquisition, development, installation, operation, maintenance and logistical support phases
of the product/system life cycle.
(4) Including any QA provisions required to accept delivery of the CI (i.e., first article or acceptance inspection).
(5) Including any unique process specifications that are required to manufacture, operate, maintain, or calibrate CIs
contained in the design.
(6) Describing the specialized software, if any, and the operating environment that was used to author the detailed design.
(7) Including technical data that provides instructions for the installation, operation, maintenance, training , and support of
a product and any associated installation, operation, and maintenance equipment.
3.2.3.4 Supplier-Developed Configuration Items (Supplier Design Release Baseline)
(1 ) The Supplier shall implement and control the evolving Design Release configuration for each CI and its associated
configuration information, and the repositories and libraries containing the Design Release configuration items.
(2) Preparation, identification, review, and release of specifications, engineering models, and drawings shall be in
accordance with the process defined within the Supplier’s approved CMP, or equivalent planning document, and all
applicable agreement requirements.
(3) The Supplier shall describe all problems and track changes to the software and information comprising the Design
Release configuration and to non-design release products being maintained under internal configuration control in
accordance with the corrective action process defined in the Supplier’s approved CMP, or equivalent planning
document.
3.2.3.5 Privately Developed Configuration Items
(1 ) The Supplier shall document the PBL of a privately-developed CI by including the applicable design disclosure and/or
form, fit, and function inform ation, and any QA provisions required to accept delivery of the item.
NOTE: Typically, the Customer acquires privately developed items as production or “off-the- shelf” items.
(2) The CI shall be re-identified as a Customer-modified CI, and thereafter documented and controlled in accordance with
applicable agreement requirement s, if modification of the privately developed CI is required to satisfy the Customer’s
requirements.
3.2.3.6 Approval and Release of the Baseline Configuration Information
(1 ) The Supplier shall generate the required configuration inform ation, models, drawings, and related engineering data
needed for each of the configuration baselines being established by the Customer.
(2) The Supplier shall submit the proposed configuration baseline inform ation to the identified approval authority for review
and approval in accordance with the processes defined in the Supplier’s approved CMP. Upon Customer approval, the
applicable baseline will be formally established and authorized for release by the Supplier for implementation.
3.2.3.7 Maintenance of Configuration Information
(1 ) Once the Custo mer has established a formal baseline for each CI, the Supplier shall manage and update each CI’s
baseline in accordance with the Configuration Change Management process defined in 3.3 of this Standard.
(2) The Supplier shall incorporate any approved changes to the baseline in accordance with the defined configuration
change and release processes along with the timeframe requirements specified in the applicable agreement.
(3) Any new revision to the configuration inform ation shall provide traceability by detailin g conditions before and after the
change is incorporated. The change, when approved, shall serve as the revision authority.
3.2.4 Configuration Identifiers
3.2.4.1 General Requirements
(1 ) The Supplier shall assign, as required, unique identifiers and naming schemes to each hardware and software CI, its
components, and associated configuration inform ation, to include revision and version numbers where appropriate or
required.
(2) The Supplier shall obtain Customer approval of the type designation and naming scheme (nomenclatu re) being
proposed for each CI that the Customer has designated to the Supplier for configuration control.
3.2.4.2 Design Activity Identification (DAI)
(1 ) Suppliers and manufacturers shall identify their Original Design Activity (ODA) by a unique DAI such as a government-
assigned CAGE code, or an equivalent unique identifier, approved by the Customer.
(2) The DAI (CAGE code) shall be affixed to all CIs, the associated subordinate traceable parts and assemblies, their
packaging, the associated configuration information, and any data products, including software media, as required by
the applicable agreement and MIL-STD-1 30, as applicable.
(3) The Supplier shall retain the ODA’s assigned DAI (CAGE code) to ensure that traceability of design ownership is
maintained when design responsibility for the CI changes or when the design of other entities (e.g., Customer, other
suppliers, sub-tier suppliers, sub-suppliers) is incorporated into the current design activity.
3.2.4.3 Document Identifiers
(1 ) If any changes are made to the Supplier’s specified numbering and identification systems, the Customer shall be
notified in writing with a description and breakdown of the new systems.
(2) The Supplier shall assign and apply a unique, non-repetitive document identifier to all documents including, but not
limited to, specifications, requirements, engineering drawings, model-based designs, associated lists, ancillary
documents, ICDs, other technical information, and to all subsequent revisions of these documents.
a. A unique document identifier, in conjunction with the ODA’s assigned DAI (CAGE code), shall be used to uniquely
identify each document and to m aintain traceability when design ownership is transferred.
3.2.4.4 Product Identification
The Supplier shall assign unique identifiers to all CIs, their sets, groups, units, assemblies, sub-assemblies, parts, or other
items by marking as described in the sections that follow.
3.2.4.5 Part or Identifying Number (PIN)
(1 ) The Supplier shall assign a discrete PIN number to each CI and its subordinate parts and assemblies in accordance
with ASME Y1 4.1 00.
(2) The PIN shall be the same as or based on the controlling drawing number and, in conjunction with the DAI, shall
uniquely identify a part or item from all dissimilar products or CIs.
(3) The Supplier shall assign a new PIN whenever a non-interchangeable condition (e.g., change impacting form, fit,
function, or condition) occurs which necessitates the assignment of a new PIN in accordance with ASME Y1 4.1 00.
(4) Unique item identifiers(UIIs) shall include the ODA’s assigned PIN and DAI (CAGE Code) and other information as
deemed necessary or required by the Customer in accordance with ASME Y1 4.1 00, ASME Y1 4.24, and MIL-STD-1 30,
as applicable.
NOTE: This requirement does not apply to Electrical, Electronic and Electromechanical (EEE) parts, such as
microcircuits, transistors, relays, capacitors, etc., because of the risk of doing irreparable damage. This
requirement applies only to physical parts; it does not apply to electronic information (documents or source code).
3.2.4.6 Type, Model, or Series Identifiers
(1 ) The Supplier shall apply a unique type, model, or series designator when required to uniquely identify a family of like
units of a CI that individually satisfy a functional requirement or by the Customer to designate an incremental design by
using model numbers.
(2) Product configuration inform ation for an approved model or series system elements, subsystems, components, and
parts shall be physically separated from previous versions to prevent lower-level changes from automatically being
incorporated into new versions that are under development.
(3) For CAD document objects, unique identification shall be able to associate parts and assemblies into unique models.
When CAD is utilized, the Supplier shall define a CAD product structure that meets the requirements of all relevant
parties.
3.2.4.7 Serial and Lot Identifiers
(1 ) The Supplier shall assign serial and lot, or batch identifiers, as required, for proper identification and control of CIs,
critical components, parts, and other groups of items when there is a need to do one or more of the following:
a. Distinguish one unit of a product from another.
b. Identify the source of a product.
c. Uniquely identify a group of items produced under similar conditions from all other groups/lots.
(2) Use of Serial Identifiers - The Supplier shall assign S/Ns to all completed units of a CI and to critical parts and
components when traceability is required or when identified by the Customer for serialization and marking.
a. When serialization is required, S/Ns shall be permanently assigned in sequential, non-duplicating order for a
particular part.
b. The S/N shall not be changed even though the component, assembly, or part has been identified by a new part
number.
c. Once assigned, S/Ns shall not be reused.
d. The S/N shall be applied to the part in accordance with ASME Y1 4.1 00 amd MIL-STD-1 30, as applicable, and be
recorded on all appropriate manufacturing and configuration accounting records.
e. The Supplier shall record and maintain S/Ns assigned by sub-tier suppliers and applicable sub-suppliers.
f. In addition, the Supplier shall develop and maintain a utilization list that cross-references the item, component, or
part lot number to the next higher assembly to ensure traceability of serial and lot numbers incorporated into next
higher assemblies.
(3) Use of Lot Numbers - The Supplier shall assign lot numbers to non-serialized items when a need exists to correlate:
a. Items that have been fabricated from a particular batch of material.
b. Items that have undergone a particular process.
c. Items that have been manufactured or tested in a group with each item in the group having an identical history.
3.2.4.8 Identifying Revisions to the Product Configuration (Rolling the Part Number)
The Supplier shall assign a new product identifier (PIN) to reflect revision to the configuration when a product or item is
changed, updated, or when one of the following occurs:
(1 ) The new or updated product is no longer interchangeable functionally or physically with the product it replaces.
(2) The new product requires new or revised procedures or requirements for testing, maintenance, repair, training,
operating procedures, equipment, or software.
(3) The product is an altered item as defined in ASME Y1 4.24M, or the updated product has different restrictions (e.g.,
application, safety, etc.).
ANSI/EIA-649 Principle CCM-1 : Changes to a product are accomplished using a systematic, measurable change
process.
ANSI/EIA-649 Principle CCM-2: Justifying the need for a change provides the rationale to commit resources required to
document, process and, if approved, implement the change.
ANSI/EIA-649 Principle CCM-3: A unique change identifier enables tracking of the request for change and the status of
implementation and verification of the approved change.
ANSI/EIA-649 Principle CCM-4: Classification of a requested change determines the appropriate level of review and the
applicable change approval authority.
ANSI/EIA-649 Principle CCM-5: As the primary vehicle for referencing and managing a change, the request for change
document must be clear and comprehensive from technical, cost and scheduling perspectives.
ANSI/EIA-649 Principle CCM-6: In evaluating whether a requested change should be approved for implementation and
incorporation in a product and its configuration information, all potential impacts including technical, operational, support,
schedule and cost should be considered.
ANSI/EIA-649 Principle CCM-7: Change approval decisions are made by an appropriate authority who can commit
resources to implement the change. The decision-maker must be aware of all impacts and cost factors.
ANSI/EIA-649 Principle CCM-8: An approved change is implemented in accordance with documented direction approved
by the appropriate level of authority.
ANSI/EIA-649 Principle CCM-9: If it is necessary to temporarily depart from specified baseline requirements, a request
for variance should be identified, classified, documented, coordinated, evaluated and dispositioned.
3.3 Configuration Change Management
NOTE: The Customer may cite DRD-STD-CR, DRD-STD-VR, and DRD-STD-MINC, Mod Kit Instructions (MIs), and
Installation Notification for specifying the delivery of CM data product(s) that derives from meeting
the requirements of this section.
Configuration Change Management is used to form ally manage changes to authorized configuration baselines for each CI
and to manage variances from requirements or design during the product life cycle. The purpose of the change
management function is to establish, maintain, and apply a systematic process for proposing, justifying, evaluating,
coordinating, and dispositioning proposed changes; and for efficient processing of configuration changes and variances so
that complete, accurate, and timely changes are made to the configuration baseline(s) and unnecessary changes are
avoided. Change Management begins with establishing the FBL for the system -level CI and continues to regulate all
changes to the subsequent ABL and PBLs. The Configuration Change Management process ensures effective control of
all CIs/CSCIs and the approved configuration information.
(1 ) The Supplier shall apply configuration control to each CI, its components, and associated configuration inform ation
throughout the product life cycle in accordance with the requirements of this Standard, as tailored in the agreem ent.
(2) The Supplier shall establish and implement procedures for documenting, coordinating, evaluating, dispositioning,
recording, and reporting requested changes and variances to baseline CIs. When the Supplier’s internal
change/variance forms are to be used, the forms are to be submitted to the Customer for review and approval as part
of the Supplier CMP.
NOTE: The information necessary for requesting a change is described in DRD-STD-CR.
(3) The Supplier shall describe the functions and membership of their configuration board(s), or equivalent, and identify
the authority(ies) authorized to approve or reject changes.
NOTE: The Supplier’s configuration board may be a CCB (e.g., Customer CCB, Supplier CCB, or Joint CCB), an
engineering review board, an individual, or other relevant group.
(4) The procedures established to disposition a request for change not requiring a configuration board shall be defined in
the Supplier’s CMP.
(5) The Supplier shall maintain the traceability of each proposed change, the rationale for the change, and authorization of
the proposed change.
(6) The Supplier shall apply configuration control to the configuration inform ation by serving as the controlling authority for
each CI prior to the time that it becomes a baseline.
NOTE: The Supplier typically limits the initiation of changes to those that meet one or more of the following criteria:
a. Correct safety, design, or performance deficiencies.
b. Satisfy a change in operational or support requirements.
c. Affects overall cost savings or cost increase.
d. Prevent or control program/project schedule slippage.
e. Implement design improvements.
f. Implement performance requirements changes.
(7) The Supplier shall ensure that all proposed changes are properly processed through the Suppliers’ CM system and
that proper engineering and management approvals are obtained before submission to the Customer.
3.3.1 Configuration Control Boards
Supplier Configuration Control Board:
NOTE: For large or complex development efforts, the Supplier’s implementation of the CCB function could include a
hierarchy of one or more internal CCBs. For small projects, limited-scope agreements, or in-house efforts, the
Customer may approve an equivalent committee, group, or individual as the authoritative change control entity.
(1 ) The Supplier shall establish a CCB(s) for control of the internal configuration identification information and to
review, evaluate, and approve proposed CRs and variance requests (VRs) for submission to the Customer.
General Requirements:
(2) The Supplier shall:
a. Describe the functions, membership, responsibility, scope of authority, and the applicable approval/disapproval
authorities for each CCB(s).
NOTE: If a formal CCB is not required, the Supplier shall describe the internal processes and procedures to be applied for
configuration control of the configuration baselines.
a. Describe the charters, operational procedures, and the period of effectivity for each CCB, or equivalent.
b. Describe the process for coordinating and interfacing with other CCBs and higher authorities.
c. Define the milestones and schedules for establishing the CCB(s) and for conducting the CCB meetings.
d. Support multi-level hardware and software CCBs and joint Customer –Supplier CCBs.
(3) The Supplier’s CCB shall:

a. Verify that each proposed change has been properly documented and classified in accordance with the criteria
specified in the agreement.
b. Assess the total impact (i.e., technical, schedule, cost) of a proposed change in all functional areas.
c. Determine which changes require either higher-level or Customer approval.
d. Coordinate and evaluate each proposed change with all affected parties prior to submitting for Customer review
and approval.
e. Authorize the approved change to be implemented in the required documentation/media.
f. Authorize the form al release of the changed documentation/media.
g. Maintain status logs of all CCB transactions.
3.3.2 Preparation of Change and Variance Request
There are two basic types of changes — CR and VR. A CR is a request to change an approved configuration baseli ne. A
VR is a request to depart from a requirement or a design of the current approved configuration information for a limited
number of items or period of time and does not involve a change to the configuration baseline. The VR may also be a
request to accept an item that departs from a specified set of requirements but still meets the function.
3.3.2.1 Change Requests
Change to an Approved Baseline - The CR is a request to actually change the approved configuration baseline. The
customer or the Supplier may submit it.
(1 ) The Supplier shall assess and describe the need, benefit, feasibility, and cost effectiveness of changes before
submitting a CR.
(2) The Supplier shall document each CR separately using the customer-approved closed-loop systematic process.
(3) The Supplier shall uniquely identify each CR and revisions thereto.
(4) The Supplier shall identify, assess, and coordinate all affected technical and programmatic data and activities for
impacts of each CR.
(5) The Supplier shall document and assess potential risks associated with the proposed change.
(6) The Supplier shall document the impacts and potential risks for disapproving a CR.
(7) The Supplier shall submit CRs to the appropriate approval authority for disposition.
(8) The Supplier shall assign a change advocate who will be responsible for integrating and presenting the CR to the CCB
with all descriptive, evaluation, and supporting data.
(9) The Supplier shall verify accurate and complete incorporation of all approved changes into the affected baseline(s).
(1 0) CRs shall be prep ared using the Supplier’s organizational guidelines in the applicable organizational processes and
contain the technical information defined in the organizational processes.
(1 1 ) The Supplier shall notify all affected users of approved changes.
(1 2) CRs shall be prepared using the organizational guidelines in the applicable organizational processes and contain the
technical information defined in the organizational processes.
(1 3) When the configuration of critical subsystem hardware and software differs from released eng ineering, digital imagery
shall be used to document the nonconformance, including affected S/Ns, part numbers (PINs), time of day, and an
image number. A completed VR, including the digital imagery, is then processed using Customer/Supplier CM
procedures.
3.3.2.2 Variance Request
Planned departure from an approved baseline – The VR is a request for temporary (limited number of items or period of
time) departure from current approved configuration information but does not change a configuration baseline (the form er
deviation).
Existing departure from a requirement and/or from design – The VR may also request retroactively the acceptance of an
item that departs from a specified requirement or design but is still functional (the former waiver).
NOTE: A "variance" is also known as a "deviation/waiver" (see definitions in EIA 649 document).
(1 ) The Supplier shall assess and describe the need, benefit, feasibility, and cost effectiveness of variances before
submitting a VR.
(2) The Supplier shall document each VR separately using the customer-approved closed-loop systematic process.
(3) The Supplier shall uniquely identify each VR and revisions thereto.
(4) The Supplier shall identify, assess, and coordinate all affected technical and programmatic data and activities for
impacts of each VR.
(5) The Supplier shall document and assess potential risks associated with the proposed variance.
(6) The Supplier shall document impacts and potential risks for each disapproved VR.
(7) Unless otherwise specified in the agreement, requests for critical or major VRs shall be approved or disapproved
within 1 5 business days of receipt by NASA.
(8) The Supplier shall define/document variances and submit the variances to the Customer for approval.
(9) The Supplier shall account for all approved variances.
(1 0) The Supplier shall notify all users of approved variances.

(1 1 ) When the configuration of critical subsystems differs from released engineering, and there is insufficient time to write
the description of the VR, then close-out digital imagery shall be used to document the nonconformance with
inform ation to provide the S/Ns, PINs, time of day, and image number.
(1 2) The close-out digital imagery (photographs) submitted with a completed VR shall be processed within the CM
procedures defined herein.
3.3.2.3 Restrictions on Variance Requests
(1 ) The Supplier shall not request variances that affect service operation, logistics interoperability, or maintenance (e.g.,
spare parts, operation, or maintenance procedures, or compatibility with trainers and test sets) unless unusual
circumstances exist.
NOTE: The effectivity of the VR normally does not include the entire remaining number of deliverable units on the
agreement.
(1 ) If it is necessary for a Supplier to generate a planned VR for the same situation with the same item multiple times
(“recurring”), the Supplier shall assess whether the departure should be permanently incorporated as a change in the
configuration information and should initiate a CR. The Supplier submits the assessment to the Customer for review
with the recurring VR.
3.3.3 Major and Minor Changes
The Customer is the approval authority for all major changes for the CI once the baseline has been approved. Changes
that are not minor changes (as described below) are considered major changes. Minor changes do not affect fit, form, or
function of the product, nor do they cause programmatic impacts related to cost, schedule, or risks. They are limited to
administrative or information clarifications and corrections. Minor changes are con sidered insignificant changes and do not
require customer approval. (The Supplier shall refer to EIA 649, Section 5.3.1 .3, Table 4. However, if the Supplier using
these change classification criteria cannot determ ine the classification of a given change, then the Supplier will submit the
change to the Customer for a classification decision.
General Requirements
(1 ) The Supplier shall formally document and control changes to their internal Design Release Baseline and to the FBL,
ABL, or PBL prior to Customer approval.
(2) The Supplier shall classify each CR as a major change or minor change.
(3) The Supplier shall submit major changes to the Customer for disposition.
(4) The Supplier shall submit to the Customer for final decision any classification disagreements arising between the
Supplier and the Customer’s designated representative.
(5) The Supplier shall assign a CR priority of emergency, urgent, or routine (as defined in Section 2.3), which determines
the change management schedule to each proposed major change.
3.3.3.1 Submitting Major Change Requests
(1 ) The Supplier shall submit all major changes to the approval authority for disposition.
(2) The Supplier shall not implement a major change without specific direction from the agreement authority.
3.3.3.2 Submitting Minor Change Requests
(1 ) T he Supplier shall process, disposition, and implement minor changes within the Supplier’s CM system.
(2) Concurrent with internal processing, the Supplier shall submit copies of all minor changes to the responsible customer
CCB, or its designated representative, for concurrence with the classification.
(3) In the case of notification of non-concurrence with the classification, the Supplier shall resubmit the minor change as a
major change.
3.3.4 Change Request Supporting Data
Each submitted CR requires a complete analysis of all programmatic and technical impacts if the change is implemented
or not implemented. Supporting data should describe effects on design, development, production, and sustainment of the
product, safety, and cost and schedule impacts. This data is necessary for a complete decision package that is used to
evaluate and justify disposition of a proposed change.
(1 ) The Supplier shall establish processes for traceability and evaluation of proposed changes that affect both
configuration and non-configuration baselines and information.
(2) The Supplier processes shall allow for comprehensive and traceable evaluations from affected organizations.
(3) For each CR and VR, the Supplier shall provide all supporting data necessary to fully assess the decision, the
configuration change, and its impacts.
(4) The Supplier shall present all dissenting opinions and non-concurring change evaluations to the CCB prior to the final
decision on a change.
(5) A record of all dissenting opinions shall be retained.
3.3.5 Software Change Control
For software, the customer controls the CSCI requirements (design specifications) and release to include all associated
software documentation (i.e., Version Description Document (VDD), manuals, guides) and products (i.e., code, databases,
PLDs). The suppliers have the responsibility to establish hardware and software integrated control authorities (control
boards) to ensure the evaluation of all changes affecting the software within an integrated CI/CSCI product structure. Both
hardware and software deliverables are released using the same baseline definitions and functions described in this
Standard.
(1 ) The Supplier shall prepare a VDD as specified in the agreement DRD-STD-VDD.
(2) The Supplier shall comply with NPR 71 50.2B, Section 4.1 .
3.3.6 As-Built Change Management
Floor Engineering Order and Redline (FEO/Redline) changes are the expedited means for proposing emergency or urgent
engineering changes in the manufacturing, testing, assembly, integration (as-built) environments on CIs/CSCIs for which
the Customer retains design responsibility. They are submitted in accordance with agreement requirements and
instructions.
(1 ) Where the ability to allow quick reaction changes to the manufacturing, testing, assembly, integration (as-built)
environments is required, the Supplier shall define and release an FEO/Redline process prior to use; and document it
in the CMP, or equivalent planning document.
(2) The FEO/Redline process shall include roles, responsibilities, authorities, and procedures.
(3) FEOs/Redlines shall be:
a. Approved prior to implementation.
b. Initialed and dated by the authorized engineer and QA representative, at a minimum.
c. Be clearly identifiable and legible.
d. Traceable to its released CI/CSCI configuration.
e. Communicated to the affected design/manufacturing and operating parties.
f. Evaluated for incorporation into the approved configuration.
(4) No Supplier FEOs/Redlines created on government-issued documentation will be accepted without prior authorization
from the Customer.
(5) Before the FEO/Redline submittal, the Supplier shall obtain a unique identifier for each FEO/Redline.
(6) After approval of FEO/Redlines by the Customer authorizing implementation of the change, the Supplier shall submit a
CR incorporating the change into the released PCI within an agreed-upon time period.
NOTES:
1 . A copy of the approved FEO/Redlines is incorporated into the Acceptance Data Package (ADP).
2. FEOs/Redlines should not compromise clarity.
3.3.7 As-Deployed Change Management
Field Engineering Changes (FECs) that may also include redlines (FEC/Redline) are the expedited means for proposing
emergency or urgent engineering changes in operating environments (as-deployed) on CIs/CSCIs for which the Customer
retains design responsibility and shall be submitted in accordance with agreement requirements and instructions.
(1 ) Where the ability to allow quick reaction changes to the operating environments is required, the Supplier shall define
and release an FEC/Redline process prior to use and document it in the CMP or equivalent.
(2) The FEC/Redline process shall include roles, responsibilities, authorities, and procedures.
(3) FECs/Redlines shall be:
a. Approved prior to implementation.
b. Initialed and dated by an authorized engineer and QA representative, at a minimum.
c. Be clearly identifiable and legible.
d. Traceable to the released CI/CSCI configuration.
e. Communicated to the affected design/manufacturing and operating parties.
f. Evaluated for incorporation into the approved configuration.
(4) No FECs/Redlines created on government-issued documentation will be implemented before the Customer authorizes
the change.
(5) Before the FEC submittal, the Supplier shall obtain a unique identifier for each FEC/Redline.
(6) After approval of FEC/Redlines by the Customer authorizing implementation of the change, the Supplier shall submi t a
CR incorporating the change into the released PCI within an agreed-upon time period .
NOTES:
1 . A copy of the approved FEC/Redlines is incorporated into the ADP.
2. FEOs/Redlines should not compromise clarity.
3.3.8 Modification Kit and Instructions
(1 ) Modi fication of a CI at a user’s site shall be implemented using a released modification kit (mod kit), except for FECs
originated and processed at the user’s site.
(2) The Supplier shall submit the proposed mod kit content through the CR process.
(3) The mod kit information shall include the modification instructions, installation notification requirements, and
validation/testing requirements.
(4) The mod kit shall be in accordance with any agreement requirements and instructions.
3.4 Configuration Status Accounting
ANSI/EIA-649 Principle CSA-1 : Configuration Status Accounting (CSA) provides an accurate, timely information base
concerning a product and its product configuration information throughout the product life cycle.
ANSI/EIA-649 Principle CSA-2: Information about the product and the product configuration information are captured as
CM tasks are perform ed; reporting is accessible to support program/project activities as needed.
ANSI/EIA-649 Principle CSA-3: Metrics derived from configuration status accounting information are used to evaluate
and improve CM process effectiveness.
NOTE: The Customer may cite DRD STD-CSA for specifying the delivery of CM data product(s) that derives from meeting
the requirements of this section.
CSA provides an accurate, timely information base concerning a product and its configuration information throughout the
product life cycle. Configuration inform ation content evolves and is captured over the product life cycle as tasks occur. Thi s
function provides a status of configuration baselines, and changes to those baselines. It form alizes the recording and
reporting of accurate and timely product configuration inform ation, which is captured as it is created over the product life
cycle.
CSA is a by-product of all the other CM processes and ensures that configuration inform ation is systematically recorded,
safeguarded, validated, and disseminated.
NOTE: The Supplier may use any inform ation technology tools or systems desired to meet CSA functional process
requirements described herein.
3.4.1 CSA Requirements
(1 ) The Supplier shall establish and maintain a CSA function that identifies configuration information, configuration
baselines, provides accounting of all changes to those baselines and provides the status of in -process changes
throughout the CI/CSCI life cycle.
(2) The Supplier shall establish an engineering release function in conjunction with the CSA system, which has the
capabilities identified in 3.6.1 .2.
(3) The Supplier shall integrate data between the CSA function and engineering release function, as applicable, to enable
complete accounting of CI/CSCI configuration information and baselines.
NOTE: Though not required, electronic integration between the CSA and engineering release functions is recommended.
(1 ) The Supplier shall provide configuration accounting reports for the CSA and engineering release functions as required
by the Customer/program/project. These reports provide the Customer/program/project with insight into current and
historical baselines, approved and pending configuration changes and variances, as well as metrics identifying trends
and potential issues within the CM system.
(2) The Supplier shall analyze the CSA data to identify perform ance metrics including adverse trends.
NOTE: Suggested performance metrics may include, but are not limited to, those described in 3.6.5.
(1 ) The Supplier shall implement a CSA function that has the following capabilities:
a. Capture and maintain accounting data that defines the currently approved configuration information for each
CI/CSCI and effectivity.
b. Capture and maintain accounting data that defines the historical configuration information throughout the CI/CSCI
life cycle.
c. Account the configuration information, including authorized but unreleased changes, that defines the FBLs, ABLs,
and PBLs.
d. Identify hierarchy among CIs.
e. Report the status of both proposed and approved configuration changes and variances to all CIs.
f. Record, track, and report implementation status and engineering release of configuration information for approved
configuration changes.
g. For variances, where the disposition includes corrective actions to prevent recurrence of the variance, provide
integration between the CSA and corrective action tracking function by recording the corrective action tracking
numbers.
h. Record and report the results of configuration audits to include the status and final disposition of identified
discrepancies.
i. Provide performance metrics that measure the execution of the Supplier’s CM process and functions.
j. When configuration management responsibility is transferred from another supplier or sub-supplier, record and
report all product data, including PINs and S/Ns, and provide clear traceability from these components to their
respective next higher assemblies.
k. Track the incorporation of all authorized retrofit changes and mod kits into the affected units.
3.5 Configuration Verification and Audits
ANSI/EIA-649 Principle CVA-1 : Verifying a product’s compliance with the physical, functional and interface requirements
in approved product definition inform ation validates the effective basis for managing product configuration.
ANSI/EIA-649 Principle CVA-2: Each change must be verified to ensure consistency is maintained between the product,
its configuration information and related support assets such as test equipment and spare parts.
ANSI/EIA-649 Principle CVA-3: Configuration audits are a summation of the configuration verification process, where
necessary to establish baselines at key points in the product life cycle.
NOTE: The Customer may cite DRD-STD-AD and DRD-STD-CMPA, for specifying the delivery of CM data product(s) that
derives from meeting the requirements of this section.
The audits verify that CIs have been properly identified, approved, released, and controlled throughout the program/project
life cycle.
The audits further verify that the product during development or modification has achieved specified requirements and the
design is accurately and completely documented in configuration baseline information. Verifying the information
determines t hat it is adequate for its intended purposes and accurately reflects a design compliant with the product’s
functional and physical requirements. NASA utilizes CM process audits and Functional and Physical Configuration Audits
(FCAs/PCAs) to achieve these goals.
Certification of successful FCA and PCA ensures the design meets perform ance requirements (FCA) and the build is
accurate (PCA).
The Supplier shall verify that the respective roles and responsibilities for Customer and Supplier organizations in the
conduct of all configuration audits are in accordance with the requirements of this Standard.
3.5.1 In-Process Configuration Management Audits
Periodic process auditing of the product CM information during the program or project life cycle (typically just after the
allocated and initial product baselines are set) minimizes enterprise baseline issues, such as unexpected schedule and
cost impacts, unauthorized changes, and inaccurate configuration information/records. The CM process audit
requirements that follow are used to verify that planning, design, implementation, and sustainment of CM processes
effectively meet the objectives of the agreed-to CM approach. Because the parent endorsed SAE/EIA 649B CM Standard
contains all the basic CM principles, those principles can be used as criteria to evaluate the effectiveness of implemented
CM processes.
In circumstances where portions of a given CM function are not necessary, CM planning that provides a rational basis for
application of appropriate CM practices, should be used to tailor the audit and evaluation criteria.
(1 ) Configuration process audits shall be performed to verify that CM processes are in place and maintain traceability and
consistency between the CIs/CSCIs and its product configuration inform ation for both suppliers and select sub-tier
suppliers.
NOTE: Typically, a “select” set of configuration information is audited against the approved planning and audit criteria to
verify consistency of configuration information. This process can be performed incremental ly or as part of an
independently planned audit activity. Audits can be conducted by the organization responsible for the product
development or production, by the Customer, or by a designated third party.
(1 ) Configuration process audits shall be perform ed to assure an efficiently tailored CM system is implemented and that
the configuration baselines have been set at the appropriate time in the product life cycle.
NOTE: Typically, CM process audits are performed to verify the FBL, ABL and the initial Product Configuration Baseline
(PCB) have been set as an outcome of the appropriate technical reviews.
(1 ) The Supplier shall conduct CM process audits using the principles of SAE/EIA-649B and the approved tailored
SAE/EIA-649-2 requirements of this Standard as the audit criteria.
NOTE: Each planned audit also considers the expected level of process maturity relative to the product life cycle phase
for when the audit is conducted.
(1 ) The Supplier shall provide timely access to all the configuration information needed in support of audit planning and
activities.
(2) The Supplier shall capture configuration process audit planning, results, and action closures as part of the CM
activities and information.
NOTE: Process audit planning is captured as part of general CM planning or as part of a process audit plan; results are
typically characterized as risks and actions and are reviewed for closure at FCA.
3.5.2 Common Audit Responsibilities
3.5.2.1 Supplier FCA/PCA Responsibilities
(1 ) The Supplier shall:
a. Conduct the FCAs and PCAs for designated CIs to verify the system allocated and product configuration
baselines.
b. Support and participate in the FCAs and PCAs for related CIs, as identified by the Customer. Provide personnel
from each engineering, CM, and QA organization to be available for discussion in their respective areas.
c. Conduct incremental, lower-level CI audits leading up to the system level audits.
d. Establish the schedule for audits to be conducted at Supplier or sub-supplier facilities including the agenda for
each configuration audit in consonance with the Integrated Master Schedule (IMS) and obtain Customer approval.
NOTE: This is accomplished sufficiently in advance of each audit to allow adequate preparation for the meeting by both
the Supplier and the Government.
e. Verify that each configuration audit schedule is compatible with the availability of the necessary information and
agreement articles. The information includes the following:
1. System engineering data.
2. Released engineering information.
3. Test results.
4. Trade study results.
5. Producibility analysis results.
6. Risk analysis results.
7. Product specifications.
8. Quality control records.
9. Manuals.
1 0. Drawings
1 1 . Reports.
1 2. Hardware.
1 3. ICD.
1 4. VDD for software or a PLD that contains software that runs executable code.
1 5. Current listing of all variances (i.e., deviations/waivers) against the CI, either requested of or approved by the
Government.
f. Verify an FCA/PCA plan is in place that clearly states the purpose and objectives of the review. The plan indicates
all data required to perform the review.
1 . The data required for an FCA/PCA is identified in DRD-STD-AD.
2. The plan defines criteria for a successful audit and provides form al certification thereto.
3. The plan defines a means of recording and tracking open actions.
g. Verify sub-suppliers participate in planning and conducting configuration audits and that the audit plan identifies
their requirements and responsibilities.
h. Verify the implementation of engineering changes and variance corrective actions to confirm consistency is
maintained between the product as-built configuration and its product as-designed configuration information.
i. Designate a single representative (e.g., audit chairperson) responsible for each audit. The representative has full
decision-making capability and commitment authority.
1. For external suppliers, the Supplier provides the audit chairperson, and NASA provides a co-chairperson
for the audit.
2. When NASA is the Supplier, the program/project manager (or delegate) acts as the audit chairperson.
j. Provide a current listing of all NASA CRs and variances against the CI either requested or approved.
k. Verify that the participating Supplier and sub-supplier personnel are prepared to discuss the technical details of the
presented materiel.
l. Maintain daily audit minutes (not to be confused with the official Audit Minutes Package), as appropriate that
summarize conclusions and actions from side meetings and main meetings.
1. The minutes of each daily session should be available for review by both the Supplier and government
personnel at the beginning of the next day's session.
m. Document significant questions and answers, action items, conclusions, and recommended courses of action
resulting from each audit.
n. Provide and maintain a method or process for recording, processing, tracking, and reporting the status of all action
items emanating from an audit.
1. Record all discrepancies identified during the audit as FCA/PCA action items. Each audit action item is to
include action plan steps to closure, appropriate actionees (both the Government and/or Supplier, as
appropriate) and suspense dates for each step.
2. Participate in the resolution of audit action items identified during the FCA/PCA. Process each action item
until it is closed out or a suitable residual task has been established and which will lead to the close out of
the discrepancy/action item. This includes identification of responsible closure activities (with associated
suspense dates).
o. Generate an official Audit Minutes Package that contains audit action items, completed FCA/PCA certification
sheets, any daily audit minutes, and any record of other findings, conclusions, and recommendations, as
applicable.
1. The official Audit Minutes Package should be available for review by the Government prior to the
departure/disbanding of the audit team.
2. Approve and publish the official Audit Minutes Package at the end of the audit review.
NOTE: The audit actions items are to be worked to closure after the Audit Minute Package is approved. The audit is to be
formally closed after all the action items are closed.
p. Presents the results of the periodic CM process audits.
1. When audits are conducted in increments, the Supplier shall support a final audit to ensure that all
requirements of the FBL, ABL, and PBL have been satisfied.
2. The Supplier shall complete all audit entry and exit criteria prior to completion or close-out of the audit.
3.5.2.2 Government Participation
(1 ) The Government:
a. Reviews any daily minutes and ensures that they reflect all significant government inputs.
b. Provides formal acknowledgment to the Supplier of the accomplishment and results of each configuration audit
after receipt of the official Audit Minutes Package.
1. Official acknowledgment by the Government of the accomplishment of the audit should not be interpreted
as approval of statements made in the “daily minutes” or the official “Audit Minutes Package” or of matters
discussed at the audit and does not relieve the Supplier from requirements that are part of agreements.
c. Evaluates the results of each configuration audit in accordance with the following identifiers:
1. Approval: to indicate that the audit was satisfactorily completed.
2. Contingent Approval: to indicate that the audit is not considered accomplished until the satisfactory
completion of resultant action items.
3. Disapproval: to indicate that the audit was seriously inadequate.
3.5.2.3 Process Control Audits for FCA/PCA
(1 ) The supplier CM Office (CMO) shall implement management processes in the following areas to support successful
FCA/PCA activities:
a. Ensure Supplier management controls and Supplier management review of all data submitted to verify and show
compliance with baseline requirements and prompt corrective action to resolve any non -conform ances, or design,
or as built deficiencies.
b. Ensure the recording and retention of all information involved in the evaluation and submittal of verification data to
NASA for approval.
c. Ensure definition of the appropriate roles for Supplier CMO, systems engineering, and quality organizations in the
conduct of the FCA/PCA and comparison of the as-designed to the as-built and resolution of non-conform ances.
(1 ) The Supplier shall perform the following process control audits during the FCA/PCA:
a. Verify an engineering release and change control system is in place during the CI/CSCI development.
b. Verify Change Authority and review appropriate change inform ation (i.e., CRs, FEOs, etc.) (This should be
perform ed on a sampling basis per Note below*.)
c. Review any agreement requirement for the engineering release and change control system. (This should be
perform ed on a sampling basis per Note below*.)
d. Review CMP and implemented CM processes. (This should be performed on a sampling basis per Note below*.)
e. Verify there are published and controlled drawing procedures.
f. Verify there are documented procedures for control of “redline” changes when used.
g. Verify all findings/action items have been closed, if CM Compliance Audit has been conducted.
* NOTE: Audit Sampling – FCA and PCA data reviews may include “sampling” where a minimum of 30 percent of the
data items is provided. In many instances, a much higher sampling rate is possible depending on the length of
the audit and the complexity of the item(s) being reviewed. If deficiencies are identified, data sampling is
expanded until there is assurance that audit objectives can be met.
a. Audit the software library (or similar internal support activity) to ensure that it accurately identifies, controls, and
tracks changes to the software and inform ation.
b. Audit the Supplier's engineering release and change control system against the requirements in of this Standard to
ascertain that the system is adequate to properly control the processing and formal release of engineering
changes.
c. The Supplier's system should meet the information and capabilities’ requirements of this Standard, as a minimum.
The Supplier's formats, systems, and procedures may be used.
d. Audit status of the current Original Equipment Manufacturer (OEM)/Supplier QA systems.
3.5.3 Functional Configuration Audit
The objective of the FCA is to verify the CI’s and system’s perfo rmance against its approved functional and allocated
configuration information. The software CI (or CSCI) FCA ensures that all requirements have a related verification method
(test step), and the test, as performed by test engineers, passes successfully.
(1 ) The Supplier shall conduct the FCA to verify that the CI meets its perform ance requirements as documented in its
approved configuration information.
(2) Subject to prior government approval, the FCA for complex items may be conducted in increments. When FCAs are
conducted in increments, the Supplier shall conduct a final system -level FCA to ensure the system FBL has been
satisfied.
(3) The CSCI FCA shall be completed prior to closing out the CSCI -related trouble report(s).
(4) Each FCA non-compliance shall be documented as FCA action items and provided to the Customer for appropriate
action.
(5) The Supplier shall use test data from the verification of the CI (prototype or preproduction article) for the FCA.
NOTE: If a prototype or preproduction article is not produced, the test data should be that collected from the test of the
first production article.
(6) A list of the Supplier's internal configuration information of the hardware CI shall be reviewed to ensure that the
Supplier has documented the physical configuration of the hardware CI for which the test data are verified.
(7) An audit of formal test plans, specifications, and procedures shall be made by the Supplier and compared against the
official test data.
a. The results should be checked for completeness and accuracy. Verify that any exceptions are recorded.
b. Interface requirements and the testing of these requirements should be reviewed.
The Supplier shall not audit the CI without prior Customer approval of the FBL and ABL of the CI or system involved.
3.5.3.1 Supplier FCA Responsibilities
3.5.3.1 .1 FCA Review Data for CIs/CSCIs
(1 ) The Supplier shall provide the following inform ation to the Customer prior to the audit date:
a. An FCA checklist (typically part of the FCA plan) that includes the following:
1. Review of the Supplier-provided FCA data items listed herein.
2. Specific FCA review activities listed herein.
3. A list of tasks to be accomplished at the FCA for the CI (typically part of the FCA plan).
4. A list of FCA data items to be audited for each CI (specifications, documents, etc.) (typically part of the
FCA plan).
b. The data provided at FCA shall be previously approved.
c. The data provided at FCA will be reviewed for completeness (no TBDs).
d. A general discussion of the entire CI test effort delineating problem areas and accomplishments.
(2) The Supplier shall provide the following information and data necessary to support the FCA. These data items are
reviewed at the FCA to verify they are approved and complete (no TBDs for specifications):
a. Verification Compliance Report (VCR) that identifies and provides traceability for all requirements; includes a cross
reference to the following:
1. Test plans.
2. Test procedures.
3. Test programs with automatic/automated test equipment (when applicable).
4. Test reports.
5. Rresults of demonstrations, inspections, and analyses for each requirement.
6. Any known deficiencies supported by applicable deficiency report numbers.
b. The as-designed configuration information for the CI being audited.
c. All approved CRs.
d. An account of the CRs incorporated and tested as well as proposed.

e. All approved drawing FEOs.
f. Product specifications.
g. Test plans, descriptions, procedures, recorded results, and analyses for the CI.
h. Analyses or simulations for those requirements that cannot be completely verified through the use of testing.
i. Complete MIUL.
j. Complete list of MUAs.
k. Complete list of qualification test deficiencies.
l. Variances (deviations/waivers) provided when criteria not met or explanation and action item expressed.
m. A list of variances (deviations/waivers) provided at FCA for each CI/CSCI (either requested of, or approved by, the
Government).
n. Drawings and parts list.
o. Certification of Qualifications (COQs).
p. Hazard Reports (HRs).
q. Failure Mode Effects Analyses (FMEAs).
r. Open technical issues and action items including, but not limited to, the following:
1. ICDs and ICD open issues.
2. Qualification open issues.
3. HR open issues.
4. FMEAs open issues.
Government-Industry Exchange Program (GIDEP) alerts, NASA Acute Launch Emergency Restraint Tips
(ALERTS) or Suspect Condition Action Notices (SCANS).
s. Requirements traceability and test matrix.
3.5.3.1 .2 Additional FCA Review Data for CSCIs
(1 ) For CSCIs, the Supplier shall provide the following approved information and data necessary to support the FCA:
a. Database characteristics, storage allocation data, and timing and sequencing characteristics for compliance with
specified requirements.
b. Software Requirements Specification (SRS), user’s manuals, and VDDs.

NOTE: These CSCI documents comprise or describe the contents or the use of the software product for format and
completeness.
a. Software verification data.
b. Software Traceability Report shows traceability from requirements documents through coding and actual software
performance.
c. Records that reflect the changes made to the design release configuration for the CSCI.
d. Listing of all versions of software or PLDs that contains software that runs executable code for the CSCIs that are
in the software library.
e. Findings of all internal CM and software QA audits of the CSCI, including PLDs that contain software that runs
executable code.
3.5.3.1 .3 FCA Review Activities for CIs/CSCIs
(1 ) The Supplier shall provide Critical Design Review (CDR) minutes. The Customer examines to verify that all findings
have been incorporated and completed and that all action items and Review Item Discrepancies (RIDs) have been
closed.
(2) The Supplier shall verify that all external or internal interface issues have been resolved. If not resolved, the issues are
to be individually identified (with action plans and completion dates).
3.5.3.1 .4 Additional FCA Review Activities for CSCIs
For PLDs that contain software that runs executable code, the Supplier shall verify control of both the hardware and
software components has been identified.
3.5.4 Physical Configuration Audit
The purpose of the PCA is to provide assurance to the Customer that the product as-designed configuration information
(including CAD models, drawings, and software source code) accurately reflects the validated product as-built (for CI) or
as-coded (for CSCI) configuration, and the information is a com plete and accurate representation of the intended design.
The PBL is established following completion of the PCA.
NOTE: After the establishment of a PBL, all subsequent changes are processed by formal engineering change action.
The PCA for a CI/CSCI should not be started unless the FCA for the CI/CSCI has already been accomplished, or the FCA
may be accomplished concurrent with the PCA.
The Supplier and the Customer conducts a PCA to examine the as-built configuration of a validated CI, comparing results
against its design information plus any approved changes (i.e., as-built matches as-designed configuration).
The PCA also determines that the acceptance testing requirements are adequate for acceptance of CI production units by
QA activities.
The PCA for software is completed prior to perform ing a software build and is witnessed by QA. This would include
verifying all software updates have been applied, as listed on the problem reports for this build.
Each PCA non-compliance identified by the PCA audit team during the audit is documented as form al PCA action items.
The PCA chairperson evaluates action items for appropriate follow-up closure activities.
a. Conduct a final system -level PCA to ensure the system PBL is correct when PCAs are conducted in increments.
b. Use test data from the validation of the CI for the PCA.
c. Invite the Customer to witness the required inspections, tests, and audits if any portions of the inspections, tests,
or audits need to be re-accomplished.
3.5.4.1 Supplier PCA Responsibilities
The PCA shall include an audit of the approved/released engineering information and quality control records to make sure
the as-built or as-coded configuration is reflected by this as-designed configuration information.
3.5.4.1 .1 PCA Review Data for CIs/CSCIs
(1 ) The Supplier shall provide the following approved inform ation and data to the Customer prior to the audit date:
a. Data describing the CI/CSCI configuration, to include:
1. A list delineating both approved and outstanding changes against the CI/CSCI.
2. Complete shortage list.
3. Acceptance test procedures (ATPs) and associated test results from those procedures and from the
successful FCA.
4. As-run test procedures, when applicable, include any test discrepancy reports).
5. Operating and support manuals, i ncluding operator’s manuals, maintenance manuals, illustrated parts
breakdown, programmer’s manuals, diagnostic manuals, etc.
NOTE: Formal verification or acceptance of these manuals should be withheld until system testing to
ensure that the procedural contents are correct.
6. Proposed Material Inspection and Receiving Report, DD Form 250 (for transfer from external Supplier to
NASA).
7. Requisition and Invoice/Shipping Document, DD Form 1 1 49 (for Government-to-Government transfer).
8. Copy of verification closure (objective evidence) for verification items verified by inspection method.
9. FCA official Audit Minutes Package for recorded FCA action items for each CI/CSCI.
1 0. Analyses or simulations for those requirements that cannot be completely validated through the use of
testing.
1 1 . Identification of all changes made during test.
1 2. Identification of any approved changes not completed.
b. Identification of CIs/CSCIs to be audited by:
1. Nomenclature.
2. Specification identification number.
3. CI identifiers.
4. Serial numbers.
5. Drawing and part numbers.
6. DAIs.
7. Where applicable, document revision levels shall be included.

(2) The Supplier shall provide the following approved information and data necessary to support the PCA for each
CI/CSCI.
a. Data defining the as-designed configuration.
1. Complete product drawings/associated lists package (3D model type, cut-away drawings, and/or Model
Based Definitions).
b. Data defining the associated as-built configuration.
1. Complete Manufacturing Build Records.
NOTE: The Manufacturing Build Records are a collection of in-process QA records from various parts
and assemblies.
2. As-Built Configuration Data (ABCD)
NOTE: The As-Built Configuration Data is the top-down list of traceability information for a CI obtained
from the original Manufacturing Build Records.
c. All approved NASA Directives.
d. Drawing trees.
e. Indentured Parts List (IPL).
f. Product drawings and parts list.
g. Lists of all outstanding FEOs that have been incorporated into the CI and are awaiting incorporation into
information.
h. Confirmation on the completion of the inspection and test of sub-supplier equipment end items at point of
manufacture. A government representative should have witnessed inspection and tests.
i. GIDEP alerts, NASA ALERTS, or SCANS.
3.5.4.1 .2 Additional PCA Review Data for CSCIs
(1 ) For CSCIs, the Supplier shall provide the following approved inform ation and data to the Customer prior to the audit
date:
a. Data describing the item configuration for CSCIs, to include:
1. Product specification.
2. Software VDD.
3. Interface Design Document for software.
4. Software manuals, as applicable, including, but not limited to, the following:
i. Software User’s Manual (SUM).

ii. Software Programmer’s Manual.
iii. Computer Systems Diagnostic Manual.
iv. Computer Systems Operator’s Manual.

b. Results of all prior reviews including, but not limited to, the FCA Review.
1. Code certifications (software including PLDs) (if any).
3.5.4.1 .3 PCA Review Activities for CIs/CSCIs
(1 ) The Supplier shall perform the following review activities during PCA:
a. Identify any difference between the following two physical configurations:
1. The PCA qualification unit configuration.
2. CI unit selected for the verification.
b. Verify that the CIs as-built hardware matches its as-designed configuration. Ensure any differences are reconciled
and documented.
NOTE: The CIs as-built configuration is seen in the ABCD.
NOTE: The ABCD is the top-down list of traceability information for a CI obtained from the original Manufacturing
Build Records.
NOTE: The CIs as-designed configuration is seen in the latest approved Drawings.
Specifically, verify that the ABCD accurately reflects the as-designed configuration as seen in the design
details contained in the drawings (and/or CAD presentations).
1. The audit team reviews a sampling (per Note 1 below*) of drawings (and/or CAD presentations) and
associated ABCD for each item of hardware (identified by the Government PCA co-chairperson). The
team reviews the accuracy to the drawings, and verifies that the ABCD includes the authorized changes
reflected in the sampled engineering drawings (and/or CAD presentations). This may be performed using
the actual drawings or models, the system’s CSA database, or other approved data sources, as
applicable.
2. At a minimum, the following checks should be made for the selected sampled drawings:
i. Drawing Number - Drawing number identified on ABCD should match the latest drawing (and/or CAD
presentation).
ii. List of Materials - List of materials in the ABCD should match materials identified on the drawing
(and/or CAD presentations).
iii. CI Identification - Nomenclature descriptions, part numbers, and serial number markings called out
on the drawing (and/or CAD presentation) should be identified on the ABCD.
* NOTE 1 : Audit Sampling – PCA data reviews may include “sampling” where a minimum of
approximately 30 percent of the data items are provided. In many instances, a much
higher sampling rate is possible depending on the length of the audit and the complexity
of the item(s) being reviewed. If deficiencies are identified, data sampling is expanded
until there is assurance that audit objectives can be met.
c. Perform the following additional inspections, as a minimum, for the selected sampled drawings (per Audit
Sampling Note 1 above) (3D model type or cut-away drawings and/or CAD presentation):
1. Drawing Changes - Drawings (and/or CAD presentations) should be reviewed to ascertain that all
approved changes have been incorporated into the CI.
2. Release Records - Release records should be checked to verify all drawings (and/or CAD presentations)
reviewed are identified.
3. More than Five Drawing FEOs - The number of any drawings (and/or CAD presentations) containing more
than five outstanding changes attached to the drawing should be recorded.
4. Major Assembly Drawing Continuity - The drawings (and/or CAD presentations) of a major assembly/black
box of the hardware CI should be checked for continuity from top drawing down to piece-part drawing.
5. Government Approvals - Verify that approvals by the Government are present where required.
d. Verify NASA GIDEP alerts, ALERTS, or SCANS have been applied to prevent use of prohibited parts as indicated
below:
1. Verify that any prohibited parts (per NASA GIDEP alerts, ALERTS, or SCANS) are NOT actually installed.
NOTE: GIDEP alerts are per NPR 8735.1 .
e. Verify CI acceptance test data/results and ATPs comply with product specifications.
1. The PCA team should determine any acceptance tests to be accomplished again and reserves the right to
have representatives of the Government witness all or any portion of the required audits, inspections, or
tests.
f. Verify that the released variances (deviations/waivers) reflect the configuration of the as-built and tested CIs.
g. Verify that the released MRB actions reflect the configuration of the as-built and tested CIs.
h. Verify the ADP meets the criteria of NAS 3500 and MIL-STD-31 000.
i. Compare the following two data items to verify delivery of currently configured spares/repair parts:
1. Records of the configuration baselines (FBL, ABL), including the interim releases of spares/repair parts
provisioned prior to PCA.
2. Supplier’s engineerin g release system and change control procedures.

3.5.4.1 .4 Additional PCA Review Activities for CSCIs
(1 ) For CSCIs, the Supplier shall perform the following review activities during PCA:
a. Verify that the software (including any PLDs that contain software that runs executable code) CSCI items
production as-coded configuration matches the as-designed configuration. This may be accomplished by
examination of software release and build records. Also, verify that any identified differences between the as-
coded and as-designed configurations for the CSCI are reconciled and documented.
b. Demonstrate, using deliverable or government-owned support software (SW), that each CSCI can be regenerated.
The regenerated CSCI should be compared to the actual CSCI delivery media to verify they are identical.
c. Verify that the software VDD reflects actual as-coded build of software.
d. For PLDs that contain software that runs executable code, verify control of both the hardware and software
components has been identified.
e. If Code certifications (software, including PLDs) are available, verify they have been reviewed.
3.5.5 Post-Audit Action
The Supplier shall complete post-audit actions as assigned/directed including, but not limited to, those indicated in the
FCA and PCA subsections that follow.
3.5.5.1 Functional Configuration Audit
(1 ) After the FCA is completed, the Supplier shall:
a. Publish copies of the official FCA Audit Minutes Package.
b. Accomplish residual FCA tasks for which they were identified as the responsible activity.
3.5.5.2 Physical Configuration Audit
(1 ) The Customer will notify the Supplier in writing of the following:
a. Acceptance or rejection of the PCA.
b. PCA status and discrepancies to be corrected.
c. Rejection of the PCA and requirements for re-accomplishment.
(1 ) After the PCA is completed, the Supplier shall:
a. Publish and distribute copies of the official PCA Audit Minutes Package.
b. Accomplish residual PCA tasks that were identified as the responsible activity.
3.5.6 Configuration Audit Summary
a. Prepare the official Audit Minutes Package consisting of the applicable FCA and/or PCA action items.
b. Prepare a detailed configuration audit summary report after successful verification of the completed/closed FCA
and/or PCA action items has been conducted.
c. Provide the completed configuration audit summary report to the Customer.
3.6 Enabling General Requirements
The requirements in this section apply across multiple functional areas of CM and are considered part of the approach,
planning, and implementation for multiple functional area s of the Supplier’s CM system.
3.6.1 Engineering Release
Engineering release is an action whereby configuration information is officially made available for its intended use.
Engineering release is used to form ally release configuration information to all stakeholders involved with requirements,
design, manufacturing, quality, logistics, and management. It provides a single source for authenticated information.
3.6.1 .1 Engineering Release Requirements for Configuration Information
(1 ) The Supplier shall establish an engineering release function to authorize the use of configuration inform ation
associated with an approved configuration.
(2) The Supplier shall use the engineering release function to issue initial and subsequent changes to the configuration
inform ation for a CS/CSCI.
(3) The Supplier shall maintain current and historical engineering release information for all CI/CSCI, including
superseded configurations.
(4) The Supplier shall release only configuration information for which the Supplier has the design activity or when release
responsibility has been assigned by the task.
(5) The Supplier shall ensure that there is only one authorized source for each item of released configuration information
at any point in the item’s life cycle (i.e., release authority for each data item is assigned to one release function until
official transfer of release authority to another release function).
(6) The Supplier shall maintain engineering release data that identifies the following for each release of configuration
inform ation:
a. The type of item released (e.g., document, drawing, parts list, database, CAD model)
b. Unique identifier of released item (e.g., document number, drawing number, part number).
c. Name or title of released item.
d. Revision of released item (if applicable).
e. CR number related to the release (if applicable).
f. Authorization for release (e.g., CR number that includes authorization, minutes, control board directive number).
g. Whether the release is an initial release or change release.
h. For a change release, the type of change (major or minor).
i. The CI/CSCI affected.
j. The configuration baseline (i.e., functional, allocated, product) that the configuration inform ation affects.
k. Date of release.
3.6.1 .2 Additional Engineering Release Requirements for Product Configuration Information
For PCI, the Supplier shall provide an engineering release function with the following additional capabilities:
a. Capture as-designed configuration CI/CSCI attributes.
b. Provide the as-designed configuration in a format that can be compared with as-built units configuration.
c. Interrelate with the Supplier’s internal system of controls to ensure that all engineering changes have been
incorporated in production items as specified.
d. Produce the following release information and relationships:
1. The composition of any PINs at any level in terms of subordinate PINs.
2. All next higher or next assembly PINs in which the part is used.
3. The related product configuration information that defines each part, including revision levels.
4. The composition of any software CSCI in term s of its components, units, and subordinate item numbers.
5. The CI number and effectivity on which any subordinate part is used.
6. The identification numbers of all engineering changes that have been partially or completely released for any part
number or CI/CSCI number and effectivity/version number.
7. The hardware CI numbers or software CSCI and version numbers that constitute the effectivity of any engineering
change (by identifier).
8. The Supplier’s requirements identifier (e.g., specification num ber,

sub-supplier item control drawing number,
source control drawing number) and the associated supplier or sub-supplier PINs assigned in response to those
requirements.
ANSI/EIA-649 Principle CI-1 3: Interfaces between products are managed by mutually agreeing to defined common
product attributes, making them part of the product configuration baselines for each product and applying a process to
maintain interface integrity.
3.6.2 Interface Management
The interface management process is conducted to ensure adequate interface definition and compliance among the
elements, as well as with other systems with which the system or system elements have to interoperate. The interface
management control process ensures that all internal and external interface requirement changes are properly
documented in accordance with the CMP, or equivalent planning document, and are communicated to all affected CIs.
The interface management process requires that interfaces be identified in a life-cycle sequence to allow for timely
evolution of the design. Interfaces are form ally controlled and are included in the FBL and the Functional ABL inform ation,
as applicable.
(1 ) General Requirements
The Supplier shall prepare, or support, preparation of all internal and external interface information required to identify the
physical, functional, and procedural parameters that are to be controlled between interfacing elements.
a. The Supplier shall incorporate all required interface information into the FBL, ABL, and PBL.
b. Prior to the PBL being established, the Supplier shall be responsible for defining and controlling all interfaces for
which the Supplier and sub-tier suppliers have design activity responsibility.
c. The Supplier shall be responsible for technical coordination with the other parties involved in the identified
interfaces.
d. The Supplier shall communicate any design, operational, and procedural differences identified among the
interfacing parties to the Customer or to the decision authority delegated responsibility for resolution.
e. The Supplier shall maintain configuration control of all interface requirements defined in baseline specifications.
(2) Interface Information
Typically, interface information consists of Interface Requirements Documents (IRDs) and ICDs. The Customer may
specify other interface documents as needed to fit unique design solutions for a particular program or project.
a. Interface Requirements Documents
The IRD defines interface requirements to be controlled between programs, projects, systems, or CIs.
1. The Supplier shall comply with and develop IRDs as specified in the agreement requirements.
2. The Supplier’s IRDs shall define interface requirements to be controlled between programs, projects,
products systems, or CIs
3. All specifications for the defined interfacing elements shall reference and identify the current and
applicable IRDs.
b. Interface Control Documents
ICDs are the design solutions to the IRDs; and as such, are considered to be part of the FBLs and/or ABLs to the
extent that they are referenced in and supplement the perform ance specifications that constitute the applicable
baselines.
1. The Supplier shall prepare and support, as applicable, the preparation of the ICDs required to identify the
physical, functional, and procedural parameters that are to be controlled between interfacing elements.
2. ICDs shall record quantified design interfaces between all participating suppliers, sub-tier suppliers, the
Customer, and other relevant third parties.
(3) Interface Change Control
a. Following the establishment of an IRD/ICD baseline, any changes affecting the approved IRD/ICD baselines shall
be submitted in accordance with the defined organizational change process for implementing a major (Class 1 )
change. (See Section 3.3).
b. Prior to submitting a change to the applicable approval authority, the Supplier shall coordinate the proposed
interface document changes with all affected parties of the interface in accordance with the defined organizational
change processes.
c. Proposed interface changes initiated by other parties to the interface shall be acknowledged and dispositioned by
the Supplier in accordance with the as-defined and implemented interface change processes.
d. If consensus on the approval of a proposed change cannot be achieved among all affected parties, the proposed
change shall be submitted to the applicable decision authority for disposition.
(4) Revision of IRDs and ICDs
a. Revision of any interface document shall require the total re-issuance and submission of the affected document
for approval using a formal CR (See Section 3.3 for additional details regarding CR submissions).
b. The revised interface document shall be submitted for evaluation and approval in the same manner prescribed for
the document’s original submittal.
(5) Interface Control Working Group
a. The Supplier shall establish and comply with agreements established with all affected sub-tier suppliers to govern
the execution of the interface control process.
b. Interface Control Working Group.
1. When required, the use of an Interface Control Working Grou p (ICWG, or equivalent, will be documented
in accordance with the applicable agreement requirements.
2. Each interfacing supplier shall support and provide a representative to the ICWG, or equivalent entity
assigned responsibility for all interface actions and agreements.
c. The Supplier’s ICWG representative shall be empowered to:

1. Commit the Supplier to specific ICWG interface actions and agreements.
2. Provide assigned and agreed-to draft interface control information at a specified period prior to the ICWG
meeting where this information is to be discussed.
3. Update, release, control, and re-release interface control information reflecting the ICWG decisions.
4. Distribute copies of all released interface control information to other ICWG participants.
3.6.3 Performance Measurement
The Supplier shall apply perform ance measures for managing, controlling, and assessing the performance of the
Supplier’s internal CM processes, and sub -tier supplier and sub-suppliers assigned CM responsibilities which include, but
are not limited to, the following:
(1 ) Measuring and assessing the performance and compliance to the CMP by the Supplier and relevant sub-tier suppliers
and sub-suppliers.
(2) Integrating and controlling resulting changes and corrective actions to the Supplier’s processes, and to those of the
relevant sub-tier suppliers and sub-suppliers;
(3) Assessing and reporting on the performance of the Supplier’s processes, and to those of the relevant sub -tier
suppliers and sub-suppliers.
4. NOTES
4.1 CM Related Data Management (DM)
CM planning and implementation includes the methods and procedures for identifying, managing, processing, delivering,
controlling, and archiving the CM-related technical data that result from associated DM activities for data handling,
processing, storage, integrity, transfer, security, and maintenance during the agreement performance period. Suppliers
and customers typically consider the following DM principles when developing their CM planning and implementation:
(1 ) The Supplier complies with all applicable DM policy, such as SAE GEIA-859 and ANSI/EIA-836, to ensure applicable
data rights, distribution, and access limitations, security classifications, and other constraints related to configuration
inform ation are properly applied, implemented, and comm unicated in accordance with public law, regulations, and
customer requirements.
(2) The Supplier defines the methods, processes, and tools to be implemented to ensure all CM -related configuration
inform ation produced by or acquired from applicable sources is appropriately identified, controlled, complete, accurate,
accessible, and available for sharing or exchange.
(3) The Supplier defines the DM tool(s) to be used for all applicable product configuration inform ation from identified
sources at a level comm ensurate with customer requirements.
(4) The Supplier defines and communicates any requirements to be imposed on the Customer, sub-suppliers, or relevant
third-part participants, regarding DM processes and policy, such as security and integrity of sensiti ve data per the
requirements of NID 1 600.55.
(5) The Supplier ensures that configuration information is accompanied by instructions for its use, so that it may be
efficiently translated and exchanged from one computer system, tool, or process to another.
(6) The Supplier defines the methods used to ensure the product configuration information will be accessible and
transferrable between the Customer, the Supplier, and other data stakeholders.
(7) The Supplier defines the methods, processes, and tools to be implemented to ensure capabilities for data backup and
recovery of the data per customer requirements.
(8) The Supplier describes the methods, tools, and inform ation technologies that will be used for storing and archiving
data and will identify all CM data that will be considered records per the requirements of NPR 1 441 .1 E.
4.2 Revision Indicator
A change bar (l) located in the left margin is for the convenience of the user in locating areas where technical revisions, n ot
editorial changes, have been made to the previous issue of this document. An (R) symbol to the left of the document title
indicates a complete revision of the document, including technical revisions. Change bars and (R) are not used in original
publications nor in documents that contain editorial changes only.
PREPARED BY SAE COMMITTEE G-33, CONFIGURATION MANAGEMENT

Sae Eia-649-2-2016

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sae Eia-649-2-2016

Uploaded by

Copyright:

Available Formats

EIA-649 -2

Configuration Management Requirements for NASA Enterprises

b. Systematically controls changes to the configuration of the product;

d. Preserves the information for the product configuration.

(2) Configuration Identification (including interface management);

(3) Change Management (Configuration Control);

(4) Configuration Status Accounting (CSA) (including configuration traceability); and

(5) Configuration Verification and Audits.

Table 1 - NASA configuration management policy

NPD 71 20.4D NASA Engineering and Program/Project Management Policy

NPR 71 23.1 B NASA Systems Engineering Processes and Requirements

NPR 71 50.2B NASA Software Engineering Requirements

3. GENERAL CONFIGURATION MANAGEMENT REQUIREMENTS ........................................................... 1 2

1 .1 Responsibility of Customer and Suppliers

1 .2.2 Requirements Verb Usage

e. “Is” or “Are” are used to indicate descriptive content.

2.1 Applicable Documents

2.1 .1 SAE Publications

SAE/EIA-649B Configuration Management Standard (referred to in this Standard as EIA-649)

2.1 .2 Other Documents

ANSI/EIA-836 Configuration Management - Data Exchange and Interoperability

ASME Y1 4.24 Types and Applications of Engineering Drawings

ASME Y1 4.1 00 Engineering Drawing and Related Information Practices

DD Form 250 (DOD) Material Inspection and Receiving Report

DD Form 1 1 49 Requisition and Invoice/Shipping Document (for Government to Government transfer)

DRD-STD-AD Functional Configuration/Physical Configuration Audit

DRD-STD-CR Change Request

DRD-STD-CMP Configuration Management Plan

DRD-STD-CMPA Configuration Management Process Audit

DRD-STD-CSA Configuration Status Accounting

DRD-STD-EDAL Engineering Drawing and Associated List

DRD-STD-MINC Modification Kit and Instructions

DRD-STD-SDT Specification and Drawing Tree

DRD-STD-VDD Version Description Document

DRD-STD-VR Variance Request

MIL-STD-1 30 Identification Marking of U.S. Military Property

MIL-STD-31 000 Technical Data Packages

NAS 3500 Technical Data Package: Composition, Communication, and Application

NID 1 600.55 Sensitive But Unclassified (SBU) Controlled Information

NPR 1 441 .1 Records Retention Schedules

NPR 71 20.5 Spaceflight Program and Project Management Requirements

NPR 71 50.2 NASA Software Engineering Requirements

2.2 Related Publications

AS-DESIGNED CONFIGURATION: The configuration of an item as documented by the design activity.

NOTE: Variant of EIA 649 "product configuration information" definition.

c. Manufacturing planning paper.

d. Manufacturing drawings (and/or computer-aided design (CAD) models).

e. Material Usage Agreements (MUA).

f. Material Identification Usage List (MIUL).

g. Material Review Board (MRB) dispositions.

h. Other documentation as applicable.

a. Products obtained from a domestic or foreign commercial marketplace.

a. Hardware, e.g., engine mechanical part.

b. Software, e.g., computer program or model.

c. Processed materials, e.g., a lubricant.

d. Facilities, e.g., a laboratory or machine shop.

VERSION: A specific configuration of a product or document. (Version is generally applied to software.)

ABCD As Built Configuration Data

3. GENERAL CONFIGURATION MANAGEMENT REQUIREMENTS

3.1 Configuration Management Application

a. Configuration Identification (3.2)

b. Configuration Change Management (3.3)

c. Configuration Status Accounting (3.4)