EIA-649-1

TECHNICAL REPORT
Issued 2014-11

Configuration Management Requirements For Defense Contracts

RATIONALE

This is a defense unique standard to the non-government standard, “ANSI/EIA-649B Configuration Management Standard,”
that generates, manages and is controlled by the non-government standard body with Defense membership to provide
requirements specific for Defense contracts. This standard is for placing tailored Configuration Management requirements
on Defense contracts.

FOREWORD

This document defines requirements for a Defense enterprise implementation of the American National Standards
Institute/Electronics Industry Association, ANSI/EIA-649 in an Acquirer/Supplier contractual relationship. The requirements
are intended to be tailored by the Acquirer and cited in contracts or similar agreements with Suppliers to establish
requirements for Configuration Management tasks consistent with ANSI/EIA-649 and each of its functions and principles.
Unless otherwise indicated, the requirements described herein apply to both hardware and software systems. It is the
responsibility of the Acquirer to determine the specific needs for their respective programs and ensure that their contracts
or agreements sufficiently communicate those requirements. This standard also applies when other types of agreements
exist, such as agreements between government organizations who play the roles of acquirer and supplier.

Finally, this document is intended to be used as a stand-alone reference, invoked on a contract where the acquirer intends
to be consistent with ANSI/EIA-649 Principles, and may be used for Department of Defense (DoD) programs in all phases
of the acquisition life cycle.

__________________________________________________________________________________________________________________________________________
SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering 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 © 2014 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_1
Copyright SAE International
Provided by IHS under license with SAE Email: CustomerService@sae.org Licensee=Defense Contract Mgmt Agency/5935922100
SAEorWEB
No reproduction ADDRESS:
networking permitted without license from IHS http://www.sae.org Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 2 of 46
TABLE OF CONTENTS

1. SCOPE .......................................................................................................................................................... 3
1.1 Responsibility of Acquiring and Supplying Activities ..................................................................................... 3
1.1.1 Responsibility of Acquirer.............................................................................................................................. 3
1.1.2 Responsibility of Supplier .............................................................................................................................. 3
1.1.3 Applicability ................................................................................................................................................... 3
1.2 Tailoring Requirements ................................................................................................................................. 4

2. REFERENCES.............................................................................................................................................. 4
2.1 Applicable Documents .................................................................................................................................. 4
2.2 Related Publications ..................................................................................................................................... 5
2.3 Definitions ..................................................................................................................................................... 5
2.4 Acronyms/Abbreviations ............................................................................................................................. 13

3. CONFIGURATION MANAGEMENT REQUIREMENTS ............................................................................. 15

3.1 Planning and Management ......................................................................................................................... 15
3.1.1 Monitoring Configuration Management Performance ................................................................................. 16
3.1.2 Supplier’s Configuration Management Plan................................................................................................ 16
3.1.3 Technical Reviews ...................................................................................................................................... 17
3.1.4 Product Configuration Documentation Processes ...................................................................................... 17
3.2 Configuration Identification ......................................................................................................................... 17
3.2.1 Configuration Item Selection ....................................................................................................................... 19
3.2.2 Configuration Baselines Types ................................................................................................................... 20
3.2.3 Engineering Release System ...................................................................................................................... 21
3.2.4 Configuration Identifiers .............................................................................................................................. 21
3.2.5 Interface Management ................................................................................................................................ 22
3.3 Configuration Change Management ........................................................................................................... 23
3.3.1 Engineering Change Proposal (ECP) ......................................................................................................... 24
3.3.2 Requests for Variance (RFV) ...................................................................................................................... 27
3.3.3 Specification Change Notice (SCN) ............................................................................................................ 28
3.3.4 Notices of Revision (NORs) ........................................................................................................................ 28
3.4 Configuration Status Accounting (CSA) ...................................................................................................... 28
3.4.1 Supplier CSA System.................................................................................................................................. 28
3.4.2 CSA Analysis Requirements ....................................................................................................................... 30
3.5 Configuration Verification and Audits .......................................................................................................... 30
3.5.1 Common Supplier Audit Responsibilities .................................................................................................... 30
3.5.2 Functional Configuration Audit (FCA) ......................................................................................................... 31
3.5.3 Physical Configuration Audit (PCA) ............................................................................................................ 32
3.5.4 Post-Audit Action ......................................................................................................................................... 34
3.5.5 Configuration Audit Summary ..................................................................................................................... 34

4. NOTES ........................................................................................................................................................ 40

ANNEX A TAILORING WORKSHEET......................................................................................................................... 41

Table 1 Cross reference for principles from ANSI/EIA-649 ..................................................................................... 35

Table 2 Data Item Descriptions (DIDs) and DD Forms ............................................................................................ 39
Table 3 Additional Associated DIDs ......................................................................................................................... 40
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 3 of 46
INTRODUCTION

The planning and execution of Configuration Management (CM) is an essential part of the product development and life
cycle management process. It provides control of all configuration documentation, physical parts and software representing
or comprising the product. Configuration Management’s overarching goal is to establish and maintain consistency of a
product's functional and physical attributes with its requirements, design and operational information throughout its life cycle.
To achieve this purpose, CM provides:

a. Management and planning of CM tasks;

b. Identification of the functional requirements and physical attributes of each product;

c. Documentation of these attributes;

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
d. Verification that the configuration of the product design meets its requirements and matches its documentation; and

e. Management and control of changes to each product and its documentation.

1. SCOPE

This document applies to hardware and software and provides CM requirements to be placed on contracts after being
tailored by the Acquirer. The requirements have been organized by the following five CM functions:

a. Configuration Planning and Management

b. Configuration Identification

c. Configuration Change Management

d. Configuration Status Accounting

e. Configuration Verification and Audit

1.1 Responsibility of Acquiring and Supplying Activities

1.1.1 Responsibility of Acquirer

The Acquirer establishes and controls the product’s functional requirements, performance requirements and has, at least,
oversight and contract compliance responsibility during product development, fielding, operation, upgrade/modification,
maintenance and disposal. The Acquirer defines the contractual CM terms and conditions for the contract(s) it issues
through tailoring of this document.

1.1.2 Responsibility of Supplier

Supplier is responsible for complying with the requirements cited in this publication, as tailored by the Acquirer. In addition,
the Supplier is responsible for ensuring that their sub-suppliers also conduct CM in such a manner that these requirements
are achieved.

1.1.3 Applicability

This document applies to all Acquirers and their Suppliers, whether the Supplier is a commercial enterprise or another
government activity, tasked with CM responsibilities. Configuration Management is implemented on products throughout
the product life cycle or as specified in the contract.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 4 of 46
1.2 Tailoring Requirements

This document is applicable only to the extent specified in the tasking directive or contract. The Acquirer tailors the
requirements from this CM document to make them applicable to a specific program. Factors that influence the tailoring
include: the program's life cycle phase, contract type/structure, complexity, size, intended use, mission criticality, and
logistics support requirements of the affected configuration items (CIs). The ANSI/EIA-649 principles listed in this document
are copyright-protected by SAE. Except as permitted under the applicable laws of the user's country, neither the ANSI/EIA-
649 principles nor any extract may be reproduced, stored in a retrieval system or transmitted in any form or by any means,
electronic, photocopying, recording or otherwise, without prior written permission being secured; they are intended to be for
reference only. However, the requirements in this document are listed in Annex A may be used and quoted in contracts.
Annex A is provided as a tool to aid the Acquirer in tailoring these requirements for use on specific contracts.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
2. REFERENCES

2.1 Applicable Documents

NOTE: Source documents referenced herein.

ANSI/EIA-649-B Configuration Management Standard

ASME Y14.35 Revision of Engineering Drawings

ASME Y14.100 Engineering Drawing and Related Documentation Practices

DAG Defense Acquisition Guidebook

DFARS Defense Federal Acquisition Regulation Supplement

DoDI 5230.24 Distribution Statements on Technical Documents

ISO/IEC/IEEE 15288 Systems and software engineering — System life cycle processes

IEEE 15288.1 Standards for Application of Systems Engineering on Defense Programs

IEEE 15288.2 Standards for Technical Reviews and Audits on Defense Programs

MIL-HDBK-505 Definitions of Item Levels, Item Exchangeability, Models, and Related Terms

MIL-DTL-15024 Plates, Tags, and Bands for Identification of Equipment, General Specification for

MIL-STD-130 Identification Marking of U.S. Military Property

MIL-STD-196 Joint Electronics Type Designation System

MIL-STD-881 Work Breakdown Structures for Defense Materiel Items

MIL-STD-961 Defense and Program-Unique Specifications Format and Content

MIL-STD-1285 Department of Defense Standard Practice: Marking of Electrical and Electronic Parts

MIL-STD-13231 Department of Defense Standard Practice: Marking of Electronic Items

MIL-STD-31000 Technical Data Packages

Title 10 United States Code Section 2302, Definitions

Defense Standardization DoD Acquisitions: Buying Commercial Items and Nondevelopmental

Program Office SD-2 Items

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 5 of 46
2.2 Related Publications

NOTE: Additional useful sources.

ACMP 2009 (STANAG 4427) Guidance on Configuration Management

SAE GEIA-STD-0007 Logistics Product Data

SAE TA-STD-0017 Product Support Analysis

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

ASME Y14.24 Types and Application of Engineering Drawings

ASME Y14.41 Digital Product Definition Data Practices

DoDD 5000.01 The Defense Acquisition System

DoDI 5000.02 Operation of the Defense Acquisition System

DoDI 8320.04 Item Unique Identification (IUID) Standards for Tangible Personal Property

IEEE-STD-828 IEEE Standard for Configuration Management in Systems and Software Engineering

ISO/IEC/IEEE 12207 Systems and software engineering - Software life cycle processes

ISO/IEC/IEEE 24765 Systems and software engineering - Vocabulary

ISO 10007 Quality management systems - Guidelines for configuration management

MIL-HDBK-61 Configuration Management Guidance

MIL-HDBK-502 DoD Handbook Product Support Analysis

MIL-STD-882 System Safety

MIL-STD-962 Defense Standards Format and Content

2.3 Definitions

ACQUIRER: An individual or enterprise that (1) commissions the engineering, design and/or manufacturing/production of a
product, (2) is a prospective purchaser of the end products of a system or a portion thereof or, (3) is a user or consumer of
the product.

ALLOCATED BASELINE (ABL): The approved requirements for a product, subsystem or component, describing 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 documentation. The allocated baseline 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). (Adapted from Defense Acquisition Guidebook (DAG))

ALLOCATED CONFIGURATION DOCUMENTATION (ACD): The documentation describing a CI's functional, performance,
and interoperability requirements that are allocated from those of a system or higher level configuration item; interface
requirements with interfacing configuration items; and the verifications required to confirm the achievement of those
specified requirements.

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

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 6 of 46
AS-BUILT CONFIGURATION: The configuration of an item as actually produced. The as-built configuration consists of the
as-designed configuration at the time of production as modified with approved engineering changes and variances. In
addition, if the as-designed configuration consists of design alternatives, the as-built configuration reflects the actual
produced item.

NOTE: 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 further modification of the as-built configuration. When this
distinction exists, the exact definition of each must be described in the CM Plan.

AS-MAINTAINED CONFIGURATION: The configuration of an item as currently in-service. The as-maintained configuration
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-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. Conducted by authorized individuals for the purpose of
assessing compliance with established design/ performance requirements, commercial and appropriate military standards,
and functional, allocated, and product baselines as appropriate. (Adapted from ISO 9000)

BASELINE: A formally controlled and maintained set of data that serves as the basis for defining change. When used as a
verb, baseline is the act of initially establishing and approving a set of data.

CHANGE REQUEST: Information 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.

COMMERCIAL AND GOVERNMENT ENTITY (CAGE) CODE: A five position alphanumeric code 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. (Adapted from ASME Y14.100)

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. A CSCI 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. A CSCI may also be interchangeably termed as a Software Configuration Item (SWCI). (Adapted from

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
ISO/IEC/IEEE 24765)

COMPUTER SOFTWARE UNIT: The lowest separately compliable piece of code element within the software product
structure, corresponding to a separately compliable piece of code. (Adapted from ANSI/EIA-649)

CONFIGURATION: The functional and physical characteristics of existing or planned hardware, firmware or software, or a
combination thereof, as set forth in technical documentation and ultimately achieved in a product.

CONFIGURATION APPROVAL AUTHORITY: The organization or person such as an Acquirer Configuration Control Board
(CCB) Chairman authorized to approve: (1) a baseline, (2) a configuration change to a product, (3) changes to product
definition information and other related documents, (4) release or cancellation of documents for use in a specific program,
and (5) results of audits.

CONFIGURATION AUDIT: Review of processes, product definition information, documented verification of compliance with
requirements and an inspection of products to confirm that products have achieved their required attributes and conform to
released product configuration definition information. See also “Functional Configuration Audit” and “Physical Configuration
Audit”. (Adapted from ANSI/EIA-649)

CONFIGURATION BASELINE: Configuration of a product, at a specific point in time, which serves as a basis for defining
change, for conducting verifications and for other management activities. For a software product, the build baseline includes
the actual product. (Adapted from ANSI/EIA-649)

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.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 7 of 46
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 CI’s current approved and
baselined configuration documentation.

CONFIGURATION DOCUMENTATION: The technical documentation that identifies and defines the item’s functional
performance and physical characteristics. The configuration documentation is developed, approved and maintained through
three distinct evolutionary, increasing levels of detail. The three levels of configuration documentation are the functional
configuration documentation, the allocated configuration documentation and the product configuration documentation.

CONFIGURATION IDENTIFICATION: The configuration management function that encompasses the selection of CIs which
are to be separately configuration managed, organization of system into a hierarchical structure of all its components, the
determination of the types of configuration documentation required for the system and its components; the issuance of
numbers and other identifiers to be affixed to the system and its components and to the technical documentation that defines
their configuration; the release of CIs and their associated configuration documentation; and the establishment of
configuration baselines for CIs.

CONFIGURATION ITEM (CI): Any hardware, software, firmware or aggregation that satisfies an end use function and is
designated by the Acquirer for separate configuration control which includes establishing the CI's requirements and verifying
that the CI's configuration meets the requirements and that its configuration documentation accurately describes its
configuration. The term CI will be used to mean hardware and software items unless there is a specific need to distinguish
between them in which case the term hardware configuration item (HWCI) and software configuration item (SWCI) will be
used.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
NOTE: Initially, depending on the level to which the Acquirer is intending to conduct baseline control, developing Suppliers
may define/propose their CIs and provide them to the Acquirer for approval. The Acquirer may then approve those
CIs or give the Supplier formal direction to change them.

CONFIGURATION MANAGEMENT (CM): CM is a technical and program management process applying appropriate
resources, processes and tools to establish and maintain consistency between the product requirements, the product and
associated product configuration information.

a. In this document, CM refers to the five functions described in the Introduction of this document and applies to hardware,
firmware, and software.

b. As applied to CIs, a discipline applying technical and administrative direction and surveillance over the life cycle of
items to:

1. Manage and plan

2. Identify and document the functional and physical characteristics of CIs.

3. Control changes and variances to CIs and their related documentation.

4. Record and report information needed to manage CIs effectively, including the status of proposed changes and
implementation status of approved changes.

5. Audit CIs to verify conformance to specifications, drawings, interface control documents and other contract
requirements.

c. As applied to digital data files, CM pertains to the application of selected configuration identification and configuration
status accounting principles to:

1. Uniquely identify the digital data files, including versions of the files and their status (e.g., working, released,
submitted, approved).

2. Record and report information needed to manage the data files effectively, including the status of updated versions
of files.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 8 of 46
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 records is achieved and
maintained throughout the applicable phases of the product’s life cycle or the duration of the contract. (Adapted from
ANSI/EIA-649)

CONFIGURATION STATUS ACCOUNTING (CSA): The CM function that formalizes the recording and reporting of the
established product configuration information (including historical information), the status of proposed changes, and the
implementation of approved changes and changes occurring to product units due to operation and maintenance. CSA
implementation includes assurances that the information is current, accurate, and retrievable.

DESIGN ACTIVITY: An organization that has, or has had, responsibility for the design of an item. (Adapted from ASME
Y14.100)

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. (Adapted from ASME Y14.100)

DETAIL SPECIFICATION: A specification that states design requirements, such as materiels to be used, how a requirement
is to be achieved, or how an item is to be fabricated or constructed. A specification that contains both performance and
detail requirements is still considered a detail specification. Both defense specifications and program-unique specifications
may be designated as a detail specification. (Adapted from MIL-STD-961)

EFFECTIVITY: A designation, defining the product range e.g., serial numbers, block numbers, batch numbers, lot numbers,
model, dates or event, at which a specific product configuration applies, a change is to be or has been affected, or to which
a variance applies. (Adapted from ANSI/EIA-649)

ENGINEERING CHANGE: A change to the current approved configuration 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
Proposal (ECP) to indicate the urgency with which the ECP is to be reviewed, evaluated and, if approved, ordered and
implemented.

ENGINEERING CHANGE PROPOSAL (ECP): A proposed engineering change to configuration documentation and the
technical data, by which the change is described, justified and submitted to a Configuration Approval Authority for
approval/disapproval or deferral.

ENGINEERING RELEASE: An action whereby configuration documentation or an item is officially made available for its
intended use.

ENGINEERING RELEASE RECORD (ERR): Information (in a document or data base) that indicates or authorizes an
engineering release. These records provide:

a. An audit trail of CI documentation status and history.

b. Verification that engineering documentation has been changed to reflect the incorporation of approved changes and to
satisfy the requirements for traceability of variances and engineering changes.

c. A means to reconcile engineering and manufacturing data to assure that engineering changes have been accomplished
and incorporated into deliverable units of the CIs.

FIRMWARE: The combination of a hardware device and computer instructions and/or computer data (i.e., firmware code)
that reside on the hardware device. The firmware code and data contained in these devices provides the control program
for the device. Firmware code and data are held in non-volatile memory devices such as Read Only Memory (ROM),
Erasable Programmable Read Only Memory (EPROM) or flash memory. In other words a combination of persistent memory
and program code and data stored in it, it is non-volatile, read-only, and performs a control function.

FIT: The ability of an item to physically interface or interconnect with or become an integral part of another item.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 9 of 46
FORM: The shape, size, dimension, mass, weight and other measurable parameters which uniquely characterize an item.
For software, form denotes operating systems, compilers, input/output schemas and formats.

FUNCTION: (1) The action or actions which a system or system component is intended and/or designed to perform. (2) The
actions or actions which the user, operator, or maintainer is expecting to perform, or which a system or system component
is designed to perform.

FUNCTIONAL BASELINE (FBL): Describes the system’s performance (functional, interoperability, and interface
characteristics) and the verification required to demonstrate the achievement of those specified characteristics. It is directly
traceable to the operational requirements contained in the Initial Capabilities Document (ICD) or equivalent document.
(Adapted from Defense Acquisition Guidebook as of June 2013)

FUNCTIONAL CONFIGURATION AUDIT (FCA): The formal examination of functional characteristics of a CI, prior to
acceptance, to verify test results met the requirements specified in its functional and allocated configuration documentation.

FUNCTIONAL CONFIGURATION DOCUMENTATION (FCD): The information describing the system's functional,
performance, interoperability, and interface requirements as well as the verifications required to demonstrate the
achievement of those specified requirements.

HARDWARE: An item that is made from materials or has components that are made from materials.

IDENTIFIER: A unique numeric or alphanumeric code applied to documents and products, for the purpose of identification,
change control, status accounting, verification and audits. Identifier types include the following:

a. Enterprise Identifier: Uniquely identifies a design or manufacturing organization responsible for a particular product.
Example: CAGE CODE, Data Universal Numbering System (DUNS) Number. See also Design Activity Identification.

b. Group Identifier: Uniquely identifies a group of like units of the same product manufactured under uniform conditions.
Examples: lot number/batch number.

c. Product Identifier: Unique to the issuing organization, used to designate products of the same configuration and to
differentiate them from other products. Examples: part identifying number (PIN), Universal Product Code (UPC), Stock-
Keeping Unit (SKU).

d. Document Identifier: Unique to the issuing organization, used to identify configuration documentation. Examples:
drawing number, specification number, document control number.

e. Type Identifier: An alphanumeric identifier, unique within the issuing organization that is used to designate a line of
products. Examples: M16 Rifle, MK48 Torpedo, F119 Engine.

f. Unit Identifier: A sequentially issued identifier used to designate a specific instance of a product among like products.
Examples: Item Unique Identification (IUID), serial number, Vehicle Identification Number (VIN).

g. Revision Identifier: A sequentially issued identifier that distinguishes a change to a design or document in order to
differentiate between two closely related design or document iteration from another. (Adapted from ANSI/EIA-649)

INTERCHANGEABLE ITEM: An item which (1) possesses comparable functional and physical characteristics as to be
equivalent in performance, reliability and maintainability to another item of similar or identical purposes and (2) is capable
of being exchanged for the other item without selection for fit or performance, alteration of the items themselves, or adjoining
items, except for adjustments. (Also known as an Alternate Item) (Adapted from MIL-HDBK-505)

INTEGRATED DATA ENVIRONMENT (IDE): Associated tools for implementing digital data operations in an acquisition
program. May also be referred to as “Integrated Digital Environment”.

INTERFACE: The functional and physical characteristics at a common boundary.

INTERFACE CONTROL: The process of identifying, documenting, conforming, and controlling all functional and physical
characteristics at the interface of two or more items.
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 10 of 46
INTERFACE CONTROL DOCUMENTATION (ICD): Interface control drawings, requirements or other descriptive products
which define, describe, and/or depict physical, functional and test interface of related or co-functioning CIs

INTERFACE CONTROL WORKING GROUP (ICWG): For programs which encompass a system, CI or a CSCI design cycle,
an ICWG is established to control interface activity among the Acquirer, Supplier(s) or other agencies including
documentation of interface agreements and resolution of interface problems.

INTEROPERABILITY: The ability of the defense services and agencies to exchange information with each other (joint
operations) or with an allied system (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. (Adapted from MIL-HDBK-505)

ITEM UNIQUE IDENTIFICATION (IUID): A system of establishing unique item identifiers (UII) within the Department of
Defense by assigning a machine-readable character string or number to a discrete item which serves to distinguish it from
other like and unlike items. (Adapted from MIL-STD-130)

MATERIEL: A generic term for complete systems, equipment, stores, supplies and spares, including related documentation,
manuals, computer hardware, firmware and software.

NON-DEVELOPMENTAL ITEM (NDI): An item available with little or no development effort required by the Acquirer. NDIs
include:

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

b. Items already developed and in use by other services, Defense activities and Government agencies.

c. Items already developed by foreign governments that can be supplied in accordance with mutual defense cooperation
agreements and Federal and DoD acquisition regulations. (Adapted from SD-2)

NOTICE OF REVISION (NOR): Documentation of revisions to drawings, associated lists or other stated documents which
require change after ECP approval.

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. A performance specification defines
the functional requirements for the item, the environment in which it must operate, and interface and interchangeability
characteristics. Both defense specifications and program-unique specifications may be designated as performance
specification. (Adapted from MIL-STD-961)

PHYSICAL CONFIGURATION AUDIT (PCA): The formal examination of the “as-built” configuration of a validated CI to
determine conformance with its design documentation, with the goal of establishing or verifying the CI’s product baseline.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
The objective of the PCA is to resolve any discrepancies between the production-representative item that has successfully
passed Operational Test and Evaluation (OT&E) and the associated documentation currently under configuration control.
At the conclusion of the PCA, the final product baseline is established and all subsequent changes are processed by formal
engineering change action.

PRODUCT: The result of a process. The following six generic product categories (and their combination into systems) are
addressed within this standard:

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

b. Software; e.g., computer program, dictionary;

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

d. Documentation; e.g., specifications, drawings, test procedures, publications, version description documents;

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 11 of 46
e. Services; e.g., transport services; transport;

f. Facility; e.g., laboratory, machine shop.

PRODUCT BASELINE (PBL): Describes the detailed design at a specific point in time, for production, fielding/deployment,
and operations and support. The PBL prescribes all necessary physical (form, fit, or function) characteristics and selected
functional characteristics designated for production acceptance testing and production test requirements. The initial PBL
includes "build-to" specifications for hardware (product, process, material specifications, engineering drawings, 3D
Computer Aided Design (CAD) models, and other related data) and software (software module design - "code-to"
specifications). The As-Delivered and subsequent PBLs add product operational information needed to operate and
maintain the product. (Adapted from Defense Acquisition Guidebook)

PRODUCT CONFIGURATION DOCUMENTATION (PCD): A CI’s detailed design documentation including those
verifications necessary for accepting product deliveries (first article and acceptance inspections). Based on program
production/procurement strategies, the design information contained in the PCD can be as simple as identifying a specific
part number or as complex as full design disclosure.

PRODUCT DEFINITION INFORMATION: Information that defines the product’s requirements, documents the product
attributes, and is the authoritative source for configuration management of the product.

PRODUCT OPERATIONAL INFORMATION: Information developed from product definition information used to test,
operate, maintain and dispose of a product.

RELEASE: The designation that the configuration documentation is complete and suitable for use. Release means that the
product has transferred from developmental configuration and is subject to configuration control procedures.

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 Acquirer. The purpose of repair is to reduce the effect of the
nonconformance. Repair is distinguished from rework in that the characteristic after repair still does not completely conform
to the applicable drawings, specifications, or contract requirements. Unique configuration identification must be applied to
repaired items.

RETROFIT: The incorporation of new design parts, software, or firmware resulting from an approved engineering change
to an item’s current approved configuration documentation into already Acquirer accepted (Material Inspection and
Receiving Report, DD Form 250) and/or operational items.

REVISION: An attribute that distinguishes a change to a design or document in order to differentiate one closely related
design or document iteration from another. A revision represents a change to a document’s contents or a modification to a
part such that it remains interchangeable with its previous iterations. See also version. (Adapted from ASME Y14.35)

REWORK: A procedure applied to a nonconformance that will completely eliminate it and result in a product that conforms
completely to the drawings, specifications, or contract requirements. The supplier must 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. The serial number does not
establish the PIN but tracks the number of items that were produced under the PIN. Serial numbers should be assigned to
all functional and major assemblies requiring special tracking.

SOFTWARE: (1) All or part of the programs, procedures, rules and associated documentation of an information processing
system or (2) computer programs, procedures, and possibly associated documentation and data pertaining to the operation
of a computer system (ISO/IEC/IEEE 24765). The definition of software is independent of the media on which the software
is stored or the device in which the software executes. Thus, the software portion of firmware is considered software and is
subject to all of the software CM requirements defined in this document. The software portion of firmware - the firmware
code - is subject to software configuration management to the extent applicable to the kind of firmware code (e.g., lower
level software language versus netlist data).

SOFTWARE CONFIGURATION DOCUMENTATION: Technical data or information, regardless of media, which documents
the requirements, design or details of computer software; explains the capabilities and limitations of the software; or provides
operating instructions for using or supporting computer software during the software’s operational life cycle.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 12 of 46
SOURCE CONTROL DRAWING: A drawing that provides an engineering description, qualification requirements and
acceptance criteria for commercial items or vendor-developed items procurable from a specialized segment of industry that
provide the performance, installation, interchangeability or other characteristics required for critical applications. The
drawing provides a list of approved sources of supply and the sub-vendor’s item identification for the item(s) that have been
qualified and approved for use in the critical application(s). The source control drawing establishes the source control item
identification. (Adapted from ASME Y14.24)

SPECIFICATION: The essential technical requirements for purchasing materiel. Procedures necessary to determine that
the requirements for the specified materiel covered by the specification have been met are also included. (Adapted from
MIL-STD-961)

SPECIFICATION CHANGE NOTICE: A request to propose, transmit and record changes to a specification.

SUB-SUPPLIER: An entity, at any level, under contract to Supplier (also known as sub-contractor, sub-tier supplier, sub-
vendor).

SUBSTITUTE ITEM: An item which possesses such functional and physical characteristics as to be capable of being
exchanged for another only under specified conditions or in particular applications and without alteration of the items
themselves or of adjoining items. (Adapted from MIL-HDBK-505)

SUPPLIER: An individual, partnership, company, corporation, association or other entity tasked under the terms of an
Acquirer contract or an agreement to provide the Acquirer with the design, development, manufacture, maintenance,
modification or supply of items may also be referred to in certain binding agreements as a Contractor or Vendor.

SYSTEM: An aggregation of system elements and enabling system elements to achieve a given purpose or to provide a
capability. (Adapted from DAG)

SYSTEM ELEMENTS: Members of a set of elements that constitute a system. Also referred to as configuration items,
subsystems, segments, components, assemblies, or parts. (Adapted from ISO/ICE/IEEE 15288 and Defense Acquisition
Guidebook. (Adapted from DAG)

TAILORING REQUIREMENTS: The process by which decisions are made to exclude or modify individual requirements
(sections, paragraphs, or sentences) in a standard or contract.

TECHNICAL DATA: Product configuration information recorded (regardless of the form or method of recording) of a
scientific or technical nature (including software configuration documentation) 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
information. (Adapted from DFARS Clause 252.227-7013 and EIA-649)

a. Technical data is required to define and document an engineering design or product configuration (sufficient to allow
duplication of the original items) and is used to support production, engineering, and logistics activities. This aspect of
technical data is called product definition information.

b. Technical data which provides instructions for the installation, operation, maintenance, training, and support of a system
or equipment can be formatted into a technical manual. This aspect of technical data is called product operational
information.

A technical manual normally includes operation and maintenance instructions, parts lists or parts breakdown and related
technical information 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. (Title 10, United States Code, Section 2302,”Definitions”).
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

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 required to ensure adequacy of item
performance. It consists of applicable technical data such as models, drawings, associated lists, specifications, standards,
performance requirements, Quality Assurance Provisions (documented requirements, procedures, and criteria necessary
for demonstrating that products conform to design requirements), software documentation, and packaging details. (Adapted
from MIL-STD-31000)

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 13 of 46
TYPE DESIGNATION: A combination of letters and numbers arranged in a specific sequence to provide a short significant
method of identification. (Adapted from MIL-STD-196)

UNIT: An assembly or any combination of parts, subassemblies and assemblies mounted together, normally capable of
independent operation in a variety of situations. (Examples: Hydraulic jack, electric motor, electronic power supply, internal
combustion engine, electric generator, radio receiver). A unit should not be confused with a Computer Software Unit.
(Adapted from MIL-HDBK-505)

NOTE: The size of an item is a consideration in some cases; for example, an electric motor for a clock may be considered
as a part but not normally subject to disassembly.

UNIQUE IDENTIFICATION: A system of establishing globally unique and unambiguous identifiers within a Defense
enterprise, which serves to distinguish a discrete entity or relationship from other entities or relationships.

UNIQUE ITEM IDENTIFIER (UII): A globally unique and unambiguous identifier that distinguishes an item from all other like
and unlike items. The UII is a concatenated value that is derived from a UII data set of one or more data elements.

VALUE ENGINEERING CHANGE PROPOSAL (VECP): A proposal submitted by the Supplier to propose a change that, if
accepted and implemented, provides an eventual, overall cost savings to the Government. A subcategory of ECP which
proposes to reduce cost to manufacture, test, inspect, maintain, or operate the item. The purpose of the VECP is to provide
an incentive to propose engineering changes which reduce cost without reducing product performance. Savings resulting
from approved VECPs are shared between the supplying and acquiring activities as stipulated by the contract.

VARIANCE: A departure from approved product configuration documentation information that does not require revision of
approved product configuration documentation information (also known as Waiver or Deviation).

VENDOR: Any organization providing services or goods to the Acquirer, including other government organizations or the
Supplier.

VERSION: A specific configuration of a product or document. Modifications to a version of software (resulting in a new
version) require CM actions by the Supplier, the Acquirer, or both.

2.4 Acronyms/Abbreviations

The acronyms used more than once in this document are defined as follows:

ABL Allocated Baseline

ACD Allocated Configuration Documentation
ACL Allowance Component List
ACMP Allied Configuration Management Publications
AEL Allowance Equipage List
ANSI American National Standards Institute
APL Allowance Parts List
ASR Alternative Systems Review
ASSIST Acquisition Streamlining and Standardization Information System
CAD Computer Aided Design
CAGE Commercial and Government Entity
CAM Computer Aided Manufacturing
CAS Contract Administration Service
CCB Configuration Control Board
CDR Critical Design Review
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

CDRL Contract Data Requirements List

CI Configuration Item
CM Configuration Management
CMP Configuration Management Plan
COTS Commercial-Off-the-Shelf
CPI Critical Program Information
CSA Configuration Status Accounting
CSCI Computer Software Configuration Item
DAG Defense Acquisition Guidebook

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 14 of 46
DID Data Item Description
DoD Department of Defense
ECP Engineering Change Proposal
EIA Electronics Industry Association
EPROM Erasable Programmable Read Only Memory
ERR Engineering Release Record
FBL Functional Baseline
FCA Functional Configuration Audit
FCD Functional Configuration Documentation
ICD Interface Control Document
ICWG Interface Control Working Group
IDD Interface Design Document
IDE Integrated Data or Integrated Digital Environment
IMS Integrated Master Schedule
IPB Illustrated Parts Breakdown
IUID Item Unique Identification
LSA Logistics Support Analysis
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

MIP Maintenance Index Pages

MRC Maintenance Requirement Cards
NCM Nonconforming Material
NDI Non-Developmental Item
NOR Notice of Revision
NSN National Stock Number
OEM Original Equipment Manufacturer
OT&E Operational Test and Evaluation
PBL Product Baseline
PBLI Product Baseline Index
PCA Physical Configuration Audit
PCD Product Configuration Documentation
PDR Preliminary Design Review
PIN Part Identification Number
PMS Planned Maintenance System
PPSL Program Parts Selection List
PRR Production Readiness Review
RFV Request for Variance
ROM Read Only Memory
SCN Specification Change Notice
SEMP Systems Engineering Management Plan
SFR System Functional Review
SOW Statement of Work
SPS Software Product Specification
SRR System Requirements Review
STANAG Standardization Agreement
SVR System Verification Review
SVD Software Version Description
SWCI Software Configuration Item
TDP Technical Data Package
TRR Test Readiness Review
UII Unique Item Identifiers
VECP Value Engineering Change Proposal

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 15 of 46
3. CONFIGURATION MANAGEMENT REQUIREMENTS

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.

(1) The Supplier shall comply with CM requirements in this document as tailored in the contract.

(2) The Supplier shall require its Sub-suppliers to comply with or suitably tailored the same CM requirements that are being
imposed upon the Supplier.

(3) The Supplier shall use a CM process to control all configuration documentation representing or comprising the
configuration item.

(4) The Supplier shall support the Acquirer’s requests to audit and verify Supplier and Sub-Supplier CM process
requirements.

3.1 Planning and Management

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.
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

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
configuration 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.

(1) Supplier shall perform CM planning to define the following factors:

a. Objectives of the CM program and of each applicable CM element.

b. Appropriate level of CM activity for each CM function throughout the product’s life cycle.

c. CM organization and organizational relationships.

d. Responsibilities and authority of CM professionals.

e. CM resources to be used (tools, techniques, training, and methodologies).

f. Coordination activities to be used with internal and external agencies (e.g., Acquirer, other Suppliers, other
Government agencies, foreign governments).

g. Functions, responsibility, and authority of CCBs.

h. A release process for product configuration documentation.

i. Methods to be used to ensure the effectiveness of sub-supplier/sub-vendor CM processes.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 16 of 46
j. CSA activities for creating, editing, reviewing, approving, releasing, publishing, and distributing product
configuration documentation and configuration change documentation.

k. Identification and labeling structure for CIs.

NOTE: The Acquiring Activity may cite DI-SESS-80858 Supplier's Configuration Management Plan and DI-MISC-
80508 Technical Report–Study/Services, for specifying the delivery of the data product that emanates from
meeting this requirement.

3.1.1 Monitoring Configuration Management Performance

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.

The purpose of monitoring an organization’s CM performance is to assess, appraise, and evaluate the value of its CM
processes in order to provide continuous improvements of the processes. Assessments can be conducted with Acquirer
oversight and agreed upon by both parties during the project’s life cycle.

(1) The Supplier shall include in their Configuration Management Plan (CMP) a methodology for generating, measuring
and reporting CM performance data.

(2) The Supplier shall make CM performance data available to the Acquirer.

Suggested performance metrics may include but are not limited to:

a. Number of open changes and variances awaiting Acquirer disposition

b. Number of closed Supplier changes and variances

c. Number of minor changes/variances

d. Number of major changes/variances

e. Change processing cycle time

f. Average amount of time (days) changes or variances remain open

g. Percentage of requests for change/variance by category, nomenclature, CI identifier number, etc.

h. Change request rejection rate and reason for rejection

3.1.2 Supplier’s Configuration Management Plan

ANSI/EIA-649 Principle CMP-7: Performing configuration management includes responsibility for the configuration
management performance of subcontractors and suppliers.

(1) Supplier shall submit to the Acquirer for review and approval the CM Plan describing the processes, methods and
procedures used to manage the functional and physical characteristics of the assigned CI(s) for the life of the contract.
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

This will also include the CM performance of sub-tier suppliers.

NOTE: The Acquiring Activity may cite DI-SESS-80858 Supplier's Configuration Management Plan, for specifying the
delivery of the data product that emanates from meeting this requirement.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 17 of 46
3.1.3 Technical Reviews

(1) The Supplier shall provide configuration documentation to support each Technical Review.

These reviews may include the following:

a. Alternative Systems Review (ASR)

b. System Requirements Review (SRR)

c. System Functional Review (SFR) (establishing the Functional Baseline)

d. Preliminary Design Review (PDR) (establishing Allocated Baseline)

e. Critical Design Review (CDR) (establishing the initial Product Baseline)

f. Test Readiness Review (TRR)

g. System Verification Review (SVR)

h. Production Readiness Review (PRR)

i. Other technical reviews, whether periodic or ad hoc, as prescribed by the contract.

NOTE: See reference ISO/IEC/IEEE 15288 Systems and Software Engineering -System Life Cycle Processes and all
associated Addenda and Amplifications for how the reviews are to be conducted.

3.1.4 Product Configuration Documentation Processes

ANSI/EIA 649 Principle CMP-8: Information processes, including collection and processing, controlling status,
providing interoperability and exchange and long term preservation, are essential elements of effective CM planning
and management.

(1) The Supplier shall address contractually specified product configuration documentation requirements in its CMP,
especially data handling, processing, storage, integrity, transfer, releasability/disclosure, security, and maintenance
documentation requirements.

(2) The Supplier shall inform the Acquirer of any requirements that will be imposed on the Acquirer to maintain the security
and integrity of shared data.

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.
CIs and their configuration documentation shall be assigned unique identifiers as described below.
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.
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 18 of 46

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-11: 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-12: The configuration of any product, or any document, plus the approved changes, is the
current baseline.

The purpose of Configuration Identification is to incrementally establish and maintain a definitive basis for control and status
accounting for a product and associated configuration documentation as it evolves throughout its life cycle. The
responsibility for configuration documentation information gets passed between engineering and CM as it is developed by
engineering, then reviewed at design reviews, and then formally managed by CM to become part of formal baselines.

(1) The Supplier shall use a documented process for configuration identification.

(2) The Supplier shall identify and track critical program information (CPI), as defined in the program's Program Protection
Plan, to ensure that CPI is not inadvertently included in exportable configurations.

NOTE: See ISO/IEC/IEEE 15288 Systems and Software Engineering -System Life Cycle Processes and all associated
Addenda and Amplifications.

(3) The Supplier shall accomplish the following for hardware and software:

a. Apply the criteria identified in 3.2.1 to select CIs.

b. Establish a CI structure and hierarchy.

c. Select configuration documentation to be used to define configuration baselines for each CI.

d. Identify and control interfaces.

e. Assign identifiers (i.e., enterprise, product, unit, group, and document) to CIs and their component parts and
associated configuration documentation, discrete part identifying number (PIN) including prefixes and suffixes, and
serial, lot, or batch numbers, with a specific Acquirer type designation, as appropriate.

f. Change PIN whenever a non-interchangeable condition is created and must not change the original serial number
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

of a unit/item/CI even when a change affecting interchangeability may require rework and re-identification.

g. Include the CAGE Code of the Design Activity for hardware and software and affix those CAGE codes to all CIs,
their subordinate parts and assemblies, configuration documentation, software media, and products.

h. Place each item of configuration documentation (e.g., item, material, or process specifications) and software
specification, software version description (SVD), etc. under configuration control.

i. Establish and manage the functional, allocated and product baselines at the appropriate points in the system/CI life
cycle, upon Acquirer approval/contractual implementation of the configuration documentation.

j. Mark or label items and documentation with their applicable identifiers that correlates to the item, configuration
documentation and other associated data,

k. Obtain Acquirer approval of the type designation and nomenclature for each CI that is designated by the Acquirer
for control, tracking and logistics purposes.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 19 of 46
NOTE: See MIL-STD-196 Joint Electronics Type Designation System, ASME Y 14.100 Engineering Drawing and
Related Documentation Practices, and DODI 5320.24 Distribution Statements on Technical Documents.

NOTE: The Acquiring Activity may cite DI-SESS-81254 Request for Nomenclature, DI-SESS-81121 Baseline
Description Document, for specifying the delivery of the data product that emanates from meeting this
requirement.

(4) In addition to the list above, the Supplier shall accomplish the following for software:

a. Assign system product-unique identifiers to elements of the software development environment such as
Commercial-Off-the-Shelf (COTS) development products like compilers, linkers, loaders, binary developmental
libraries, configuration settings, automation scripts, and other elements that are part of the system and will conform
to the format specified in the CMP.

b. Provide a part number representing the device with the embedded code (in cases where both the hardware device
and the embedded code are controlled via a single engineering drawing-Altered Item Drawing).

c. Ensure the part number and the software medium is labeled with the supplier’s code/name identification and marked
separately on the device.

d. Designate computer software as CIs.

NOTE: The Acquiring Activity may cite DI-SESS-81011 Drawing/Model Number Assignment Report, for specifying the
delivery of the data product that emanates from meeting this requirement.

3.2.1 Configuration Item Selection

(1) The Supplier shall select and submit potential CI’s for Acquirer review and selection concurrence.

(2) The Supplier shall identify as a CI any item that satisfies a system end use function and designates it for separate CM
because the item meets or impacts one or more of the following:

a. An item critical to the functioning of the system.

b. An item whose failure might result in serious injury, loss of life or loss of primary system capability.

c. An item whose technology is complex, not well known, and critical to meeting acquisition, operational or
supportability goals of the program.

d. Is under government control as designated by the Acquirer.

e. Requires separate designated, versions or nomenclatures.

f. Is critical or high risk and failure would have significant financial impact.

g. Requires any one of the following logistics elements:

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

1. Supply support Allowance Parts List (APL)

2. Supply support Allowance Equipage List (AEL)

3. Supply support Allowance Component List (ACL)

4. Test equipment (e.g., General Purpose, Special Purpose or Built-in)

5. Technical manuals

6. Planned Maintenance System (PMS) Maintenance Index Pages (MIP) and Maintenance Requirement Cards
(MRC)

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 20 of 46
7. Danger or Caution Tag Out requirements

8. National Stock Number (NSN)

NOTE: The Acquiring Activity may cite DI-SESS-81254 Request for Nomenclature and DI-SESS-81879 Configuration
Item Documentation Recommendation, for specifying the delivery of the data products that emanates from
meeting this requirement.

3.2.2 Configuration Baselines Types

There are three major baseline types established during the life cycle of a product: functional, allocated and product. The
FBL and ABL are outputs of the design process used as inputs to subsequent parts of the design process and must be
maintained and configuration controlled by the acquiring activity or supplying activity as required by the contract. The PBL
constitutes the final output of the design process and is controlled by the acquiring activity. The Supplier may be designated
as the maintainer of the configuration baselines.

3.2.2.1 Configuration Baselines and Their Configuration Documentation

(1) The Supplier shall generate the configuration documentation required for the configuration baselines being established
by the Acquirer, as tailored in the contract.

NOTE: The Acquiring Activity may use MIL-STD-31000 Technical Data Packages and its associated Data Item
Descriptions (DIDs) for specifying the delivery of the data product that emanates from meeting this requirement.

(2) The Supplier shall ensure each succeeding baseline is traceable to, and a detailed extension of, its predecessor(s).

3.2.2.2 Functional Configuration Documentation (FCD)

(1) The supplier shall document the FBL of a CI by:

a. Describing its functional, performance, interoperability and interface requirements.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
b. Describing the verifications required to demonstrate achievement of those requirements.

c. Identifying any specialized software and documenting the operating environment used to author the above
requirements.

3.2.2.2.1 Allocated Configuration Documentation (ACD)

(1) The Supplier shall document the ABL of a CI by:

a. Describing its functional, performance, and interoperability requirements that are allocated from those of a system
or higher level configuration item; and interface requirements with interfacing configuration items.

b. Describing the verifications required to demonstrate achievement of those requirements.

c. Identifying any specialized software and documenting the operating environment used to author the above
requirements.

3.2.2.2.2 Product Configuration Documentation (PCD)

(1) The Supplier shall document the PBL of a CI by:

a. Describing its detailed design including necessary physical (form, fit, and function) characteristics and selected
functional characteristics designated for production, acceptance testing and production test requirements.

b. Identifying the verifications necessary for accepting product deliveries (first article and acceptance instructions).

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 21 of 46
c. Identifying and documenting the design of any special tooling, software, equipment and facilities required to
manufacture, operate, maintain, calibrate, or inspect items contained in the design.

d. Identifying and documenting the design of any special packaging parts required to package the CI.

e. Including any quality assurance provisions required to accept deliveries of the CI (first article or acceptance
inspection).

f. Including any unique process specifications required to manufacture, operate, maintain, or calibrate items contained
in the design.

g. Identifying any specialized software and documenting the operating environment used to author the detailed design.

h. Include technical data which provides instructions for the installation, operation, maintenance, training, and support
of a system or equipment.

(2) The Supplier shall document the PBL of a privately developed CI by including any quality assurance provisions required
to accept deliveries of the CI (first article or acceptance inspection).

3.2.2.3 Maintenance of Configuration Documentation

(1) The Supplier shall maintain the current approved configuration documentation by creating a new revision to
configuration documentation when incorporating approved changes within 90 days, unless otherwise stated in the
contract or agreement.

The new revision to the configuration document will provide traceability by detailing conditions before and after the
change is incorporated and by identifying the change as the revision authority.

3.2.3 Engineering Release System

(1) The Supplier shall use an Engineering Release process which employs formal release records to authorize the use of
new or revised configuration documentation.

(2) The Supplier shall use an engineering release system to issue initial and subsequent changes to the product
configuration documentation.

(3) The Supplier shall use an engineering release process to authorize the use of configuration documentation associated
with an approved configuration

(4) The Supplier shall incorporate all approved configuration changes into the configuration documentation.

(5) The Supplier shall incorporate approved configuration documentation and Engineering Release Record into their CSA
system.

(6) The Supplier shall obtain approval from the Acquirer if Supplier wants to use their own format for Engineering Release
Record (ERR) submittals to ensure data compatibility in the digital environment.

(7) ERR’s shall be used to incorporate approved ECPs into configuration documentation and to release new or revised
configuration documents.

NOTE: The Acquiring Activity may cite DI-SESS-80463 Engineering Release Record for specifying the delivery of the
data product that emanates from meeting this requirement.

3.2.4 Configuration Identifiers

(1) The Supplier shall uniquely identify each CI.

(2) The Supplier shall determine the types of configuration documentation required for each CI.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 22 of 46
(3) The Supplier shall assign unique identifier and other identifiers for the CIs and to the technical documentation that
comprises the CI’s configuration documentation.

(4) The design document identifier (i.e., CAD model, engineering drawing) shall be the same as, or included within, the part
number.

3.2.4.1 Product Identification/Marking

(1) The Supplier shall identify all CIs including their sets, groups, units, assemblies, subassemblies, parts or other items by
marking in accordance with MIL-STD-130, MIL-STD-1285, or MIL-STD-13231, as applicable.

(2) The Supplier shall adhere to DoD Item Unique Identification (IUID) directives, instructions, and standards as tailored in
the contract.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
NOTE: For DoD IUID directives, instructions and standards for each applicable Unique Identification and Unique Item
Identifier CI, see MIL-STD-130.

(3) When required in acquisition documents, IUID marking shall be in accordance with MIL-STD-130. Identification marking
may be applied direct to an item or by separate means in accordance with MIL-DTL-15024.

(4) For CIs marked with Unique Item Identifier (UII), the supplier shall check DoD IUID Registry to ensure that the UII has
not been previously assigned to an item.

3.2.4.2 Software Marking and Labeling

(1) The Supplier shall mark and label software as follows:

a. Embed software identifier and version in the source code header.

b. Mark each software medium (i.e., disks, hard drives) with a label to include distribution statement, ITAR statement
and classification.

c. Each label shall contain, or provide cross-reference to, a list of the applicable software identifiers of the entities it
contains.

d. The label shall also indicate the status of the software maturity on the medium, e.g., whether this software is a
release candidate or if the software has been tested and verified."

e. Mark with a label all CSCIs deliverable media. Label shall contain:

1. Acquirer Contract number.

2. CSCI Number (include a designator indicating whether source or executable code).

3. Design activity Cage Code. .

4. Media Number (e.g., 1 of 2, 2 of 2) if there are multiple units per set. Each time a new version of software is
issued, new copy numbers, starting from 1, must be assigned.

3.2.5 Interface Management

ANSI/EIA-649 Principle CI-13: 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.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 23 of 46
3.2.5.1 Interface Identification and Documentation

(1) The Supplier shall identify the internal and external interface requirements for the system and its CIs.

(2) The Supplier shall incorporate into the FCD, ACD, and PCD all interface information.

(3) The Supplier shall maintain configuration control of interface requirements defined in baseline specifications.

(4) Prior to the PBL, the Supplier shall define and control all interfaces.

NOTE: The Acquiring Activity may cite DI-SESS-81248 Interface Control Document, for specifying the delivery of the data
product that emanates from meeting this requirement.

3.2.5.2 Interface Control Working Group (ICWG) Membership

(1) Each interfacing Supplier shall support and provide a representative to the Acquirer’s ICWG.

(2) The ICWG Supplier representative shall be empowered to:

a. Commit the interfacing sub-supplier to specific interface actions and agreements.

b. Provide assigned and agreed-to draft interface control documentation at a specified period prior to the Acquirer’s
ICWG meeting where it will be discussed.

c. Update, release, control and re-release interface control documentation reflecting the ICWG decisions.

d. Distribute copies of such released interface control documentation to other ICWG participants.

3.3 Configuration Change Management

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

ANSI/EIA-649 Principle CCM-1: Changes to a product are accomplished using a systematic, measurable change
process.

(1) The Supplier shall apply configuration control to each CI, its components and configuration documentation.

(2) The Supplier shall ensure that:

a. Configuration baselines are maintained and controlled.

b. Configuration identification control of all CIs and their associated configuration documentation is maintained.

c. Product configuration changes and variances are documented, coordinated, evaluated, dispositioned, and recorded
in a CM/status accounting system and reported to the acquirer.

d. Requested configuration changes and variances address all areas of impact, to include cost, operational,
sustainment, and implementation actions (e.g., ordering material, designing tooling, manufacturing planning, and
interface design, support equipment, software code, producing parts, retrofit).

e. Released/approved configuration changes are incorporated into all product configuration information including the
CM/status accounting system, and implemented into each product/CI/component impacted, in a timely manner.

f. Released/approved configuration changes are verified as being incorporated to maintain product configuration
control and product configuration information consistent and prepare release authorization documentation.

g. Released/approved variance corrective actions are implemented and verified.

(3) Supplier shall support a joint Acquirer’s/Supplier Configuration Control Board(s).

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 24 of 46
3.3.1 Engineering Change Proposal (ECP)

(1) The Supplier shall use an ECP to document changes to Acquirer approved configuration documentation.

NOTE: The Acquiring Activity may cite DI-SESS-80639 Engineering Change Proposal, for specifying the delivery of
the data product that emanates from meeting this requirement.

3.3.1.1 Engineering 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.

(1) When an engineering change affects documentation previously approved by the Acquirer, the Supplier shall perform
the following actions:

a. Define the need for the change.

b. Review product model and other technical data to determine what specific changes will need to be made

c. Prepare an ECP, Notice of Revision (NOR) and technical data supporting the change.

d. Prepare a separate ECP for each engineering change that has its own distinct objective.

e. Incorporate the Acquirer-approved ECP into the configuration documentation, including engineering changes
negotiated into the contract.

f. Implement and update configuration documentation with approved changes described in the ECP, using a
documented engineering release system.

g. Record all changes in the CSA system database.

h. Verify that the approved change was implemented correctly.

i. Identify superseding revisions to ECPs. An ECP must be revised when alterations or changes to the initial ECP are
necessary.

j. Provide an implementation timeline/schedule for each ECP classification (Class I and II) and the ECP priority type
(Emergency, Urgent, or Routine).

k. Provide in its technical data the impact if the engineering change is disapproved.

3.3.1.2 Classification and Authority of ECP

ANSI/EIA-649 Principle CCM-4: Classification of a requested change determines the appropriate level of review and
the applicable change approval authority.

(1) The Supplier shall use content in “DD Form 1692” or equivalent for assigning a Major (Class I) or Minor (Class II)
classification to an ECP.
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 25 of 46
3.3.1.3 ECP Format

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.

(1) The Supplier shall use appropriate form/text, such as "DD Form 1692”, or equivalent for referencing and managing a
change.

(2) The Supplier shall obtain approval from the Acquirer if the Supplier wants to use its own ECP format for Major (Class I)
and Minor (Class II) ECPs.

NOTE: The Acquiring Activity may cite DI-SESS-80639 Engineering Change Proposal, for specifying the delivery of
the data product that emanates from meeting this requirement.

3.3.1.4 Supporting Data

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.

(1) The Supplier shall support ECPs with drawings and other data (e.g., Logistics Support Analysis (LSA) data, detailed
cost proposal data, test data and analyses, quality, packaging, interchangeability factors) to better understand and
evaluate the change and its impacts upon the system, its operation and support.

(2) The Supplier shall include in the ECP implementation costs, when the contract references life cycle cost and/or
operation and support cost model, the following costs:

a. All future production and spare items projected to be procured for the program.

b. All projected operation and support costs for operation of the total inventory of items by the Acquirer.

(3) The Supplier shall include in the ECP, as supporting data, a summary of any testing done by the Supplier to validate
concepts or new technology to be employed in the proposed change and details of such test data vital to the decision
regarding acceptance of the change.

3.3.1.5 ECP Decisions

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
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.

The Acquirer is configuration approval authority for all Major (Class I) engineering changes for the CI once the baseline has
been approved/accepted by the Acquirer.

3.3.1.6 Engineering Change Priorities

The Acquirer uses the engineering change priority of emergency, urgent, or routine to determine the time frame in which
the ECP is to be reviewed, evaluated, ordered, and implemented.

(1) The Supplier shall not assign an Emergency or Urgent Engineering Change Priority to a Minor (Class II) ECP.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 26 of 46
3.3.1.7 Related Engineering Changes

A related engineering change occurs when the desired engineering change in one item (the basic or original engineering
change) requires related engineering changes in other items to retain (or attain) either an interface match or compatibility
and interoperability of the associated items.

3.3.1.7.1 Related Engineering Changes - Single Prime, Single Procuring Activity

(1) The single prime/procuring Supplier shall include all support data and interface items in one basic/original uniquely
numbered engineering change.

3.3.1.7.2 Related Engineering Changes - Single Prime Multiple Procuring Activities

(1) The Supplier shall assign a number to the basic ECP.

(2) The Supplier shall use the basic ECP number, plus a separate dash number, for related ECPs submitted to other
procuring activities.

3.3.1.7.3 Related Engineering Changes - Separate Primes

(1) The Supplier shall submit a coordinated basic ECP when a desired engineering change in one product (the basic ECP)
requires related engineering changes in other products that are the responsibility of other prime Suppliers who are
participating in a specific item development or production program.

(2) The Supplier’s coordinated basic ECP shall include data showing the extent of the coordination and its results to the
related ECPs of the other prime Suppliers.

(3) The Supplier shall include in the basic ECP the impact on the other items.

(4) The Supplier shall cross-reference basic and other related ECPs.

3.3.1.8 Minor (Class II) ECP

(1) The Supplier shall assign an ECP classification of a Minor (Class II) to an ECP whose engineering change does not
meet the criteria for a Major (Class I) change.

Minor (Class II) ECPs are limited to administrative or documentation clarifications and corrections.

3.3.1.8.1 Concurrence in Classification

(1) The Supplier shall obtain Acquirer classification concurrence of any Minor (Class II) ECP. The Acquirer may delegate
authority to the Supplier or Acquirer’s designated representative for the concurrence of classification for Minor (Class
II) ECPs as tailored in the contract.

(2) The Supplier shall cancel a Minor (Class II) ECP if the Acquirer disagrees with the classification of the ECP. The Supplier
may reprocess the proposed change as a Major (Class I) ECP.

(3) The Supplier shall submit to the Acquirer for final decision, any classification disagreements between the Supplier and
the Acquirer’s designated representatives.
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

3.3.1.8.2 Approval of Minor (Class II) Changes

(1) The Supplier shall submit the Minor (Class II) change to the Configuration Approval Authority after the classification
review by the Acquirer or Acquirer's designated representative prior to the release and implementation.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 27 of 46
3.3.2 Requests for Variance (RFV)

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.

(1) The Supplier shall obtain the Acquirer’s approval on any product that will be produced as defective or nonconforming
(i.e., pre-production RFV) before delivery to the Acquirer.

(2) The Supplier shall obtain Acquirer’s approval on any product that is produced as defective or nonconforming (i.e., post-
production RFV) before delivery to the Acquirer.

Pre-production RFVs request permission to produce a product that does not conform to contract
requirements/documentation for a limited amount of time and for specified effectivity, and post-production RFVs, request
approval of product found to be not conforming to contract requirements/documentation after it’s produced.

(3) The Supplier’s RFV shall not include a requirement to change the product configuration documentation.

(4) If the Acquirer determines that the variance would be permanently acceptable, then the Supplier shall submit an ECP
to accomplish the change.

(5) If the RFV is for the benefit of the Supplier, the Supplier shall provide, as part of the RFV documentation, equitable
consideration based on either (or both) the quantity of items affected by the RFV or the extent the affected items do not
meet the Acquirer's contractual requirements.

(6) Upon RFV disposition, the Supplier shall document in the CSA system: RFV description, how the NCM addressed by
the RFV, is impacted including the impact to any additional product/part , the RFV stated corrective action to prevent
recurrence, and the corrective action taken/accomplished by the Supplier to prevent RFV reoccurrence.

NOTE: The Acquiring Activity may cite DI-SESS-80640 Request for Variance, for specifying the delivery of the data
product that emanates from meeting this requirement.

3.3.2.1 Recurring Variances

(1) The Supplier shall obtain the Acquirer’s approval before submitting a reoccurrence RFV with the same nonconformance.
Corrective action plans included in a RFV should reduce the need for recurring Variances.

(2) The Supplier shall evaluate recurring variances for possible submittal of an ECP.

Requested variances are limited to their documented effectivity which is less than the remaining contract period for all
produced items/units; recurring variances are resubmitted as a major engineering change.

3.3.2.2 Classification of Variances

(1) The Supplier shall use content in “DD Form 1694” for assigning a Critical/Major or Minor classification to an RFV.

(2) The Supplier shall submit to the Acquirer for final decision, any classification disagreements between the Supplier and
the Acquirer’s designated representatives.

(3) Suppliers shall provide an implementation timeline for Critical and Major classified RFVs.

3.3.2.3 RFV Decisions

The Acquirer is configuration approval authority for all Critical and Major RFVs. The Configuration Approval Authority for all
Minor RFVs is the Acquirer, or Acquirer’s designated representative.

(1) The Supplier shall submit all proposed Critical and Major RFVs to the Acquirer with data from the Acquirer’s designated
representative, if available.

(2) The Supplier shall submit all requested Minor RFVs to the Acquirer or Acquirer’s designated representative.
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 28 of 46
3.3.2.4 Minor RFVs

(1) The Supplier shall assign an RFV classification of Minor to an RFV that does not meet the criteria for a Critical or Major.

Generally, Minor RFVs address product changes that are temporary and do not impact the baseline.

3.3.3 Specification Change Notice (SCN)

(1) The Supplier shall prepare a separate proposed SCN for each specification that would require revision.

(2) The Supplier shall submit SCNs in conjunction with any ECP that affects a specification.

NOTE: The Acquiring Activity may cite DI-SESS-80643 Specification Change Notice, for specifying the delivery of the
data product that emanates from meeting this requirement.

3.3.4 Notices of Revision (NORs)

(1) The Supplier shall submit a NOR for each document affected by an ECP.

(2) The Supplier shall prepare and submit with each NOR’s all information required to disposition the NOR and it’s
associated ECP.

NOTE: The Acquiring Activity may cite DI-SESS-80642 Notice of Revision, for specifying the delivery of the data
product that emanates from meeting this requirement.

3.4 Configuration Status Accounting (CSA)

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 performed; reporting is accessible to support program/project activities as needed

CSA formalizes the recording and reporting of the accurate and timely established product configuration information. CSA
provides status of proposed changes, the implementation of approved changes and changes occurring to product units due
to operation and maintenance.

(1) The Supplier shall maintain the validity of the CSA by storing valid data in the CSA system.

(2) The Supplier shall perform CSA analysis to detect and identify trends and report problems.

3.4.1 Supplier CSA System

The Supplier may utilize any information technology tools or systems desired to meet CSA functional process requirements
described herein.

(1) The Supplier’s CSA system shall be closely linked to the data repository used to store and manage the product
configuration and product operational information.

This close linkage may be accomplished via use of an all-encompassing product data management system (with CM,
data repository, requirements management, and traceability functionality all in the same product) or by integration of
separate stand-alone IT tools/systems.

NOTE: The Acquiring Activity may cite DI-SESS-81253 Configuration Status Accounting Information, for specifying the
delivery of the data product that emanates from meeting this requirement.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 29 of 46
(2) The Supplier shall use a CSA system to capture, store, and maintain product configuration information about the product
that is either provided by the Acquirer or created by the Supplier during the duration of the contract.

(3) The Supplier shall implement a CSA system that has the following capabilities:

a. Capture and maintain the currently approved product configuration information by the identification number
assigned to each CI.

b. Capture and maintain all historical product configuration information with traceability detailing product configuration
from contract award to the present.

c. Store and manage all product configuration information, which includes but not limited to product definition

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
information (information that defines the product’s requirements, documents the product attributes, and is the
authoritative source for CM of the product) and/or product operational information (information developed from
product definition information used to test, operate, maintain and dispose of a product).

d. Identify dependencies 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 documentation for
approved configuration changes.

g. Record, track and report the status of corrective actions (repairs, use-as-is, scrap) for nonconforming materiel
addressed by the RFVs which affects the configuration of any CIs.

h. Record and report the planning and 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. Record and report all product data inherited from sub-tier suppliers, to include vendor part numbers and serial
numbers, and provide clear traceability from these components to their respective next higher assemblies.

(4) The Supplier shall:

a. Make CSA system and product configuration information readily available to the Acquirer or Acquirer’s designated
representative, via on-site inspection, remote access, or regular submissions of CSA information and updates in
accordance with the contract.

b. Be in compliance with DoD Cyber Security requirements for the purpose of interoperating with the Acquirer’s system
as in an integrated digital environment.

c. Ensure recorded product configuration information is adequately secured, safeguarded and retrievable after
extended storage.

d. Provide a digital delivery to the Acquirer upon the completion of the contract, CSA information and configuration
baseline documentation created, collected, and managed during the contract. The form, format and delivery date
for this data delivery will be in accordance with DID.

(5) The Supplier shall document the incorporation of all retrofit changes to those units identified for retrofit.

NOTE: The Acquiring Activity may cite DI-SESS-81245 Installation Completion Notification, for specifying the delivery
of the data product that emanates from meeting this requirement.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 30 of 46
3.4.2 CSA Analysis Requirements

ANSI/EIA-649 Principle CSA-3: Metrics derived from configuration status accounting information are used to evaluate
and improve CM process effectiveness.

(1) The Supplier shall evaluate CSA corrective actions to verify that problems have been resolved, metrics of adverse
trends have been reversed and changes have been correctly implemented in the appropriate processes and products;
and determine whether additional problems have been introduced.

Suggested performance metrics may include but are not limited to those that are listed in 3.1.1.

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 information 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.

The audit verifies 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 documentation determines
that it is adequate for its intended purposes and accurately reflects a design compliant with the product’s functional and
physical requirements. DoD utilizes Functional and Physical Configuration Audits (FCA/PCA) to achieve these goals.

3.5.1 Common Supplier Audit 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 Acquirer.

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 Acquirer’s approval.

e. Ensure that each configuration audit schedule is compatible with the availability of the necessary information and
contract articles, (e.g., system engineering data, released engineering documentation, trade study results,
producibility analysis results, risk analysis results, product specifications, quality control records, manuals,
drawings, reports, hardware, Interface Design Document (IDD), and SVD for software, or firmware code).

f. Ensure sub-suppliers participate in planning and conducting configuration audits and an audit plan is prepared to
identify their requirements and responsibilities.

g. Designate a representative for the audit.

h. Provide a current listing of all RFVs, SCNs, and ECPs against the CI either requested or approved.

i. Ensure that participating Supplier and Sub-supplier personnel are prepared to discuss the technical detail of the
presented materiel.

j. Participate in the resolution of discrepancies identified during the FCA/PCA.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 31 of 46
k. Summarize conclusions and add appropriate comments summarizing the side meetings and the main meeting into
the official minutes.

l. Document significant questions and answers, action items, conclusions, and recommended courses of action
resulting from each audit.

m. Record all discrepancies identified during the audit and process each one until it is closed out or a suitable residual
task, including identification of responsible activities and suspenses, have been established and which will lead to
the close out of the discrepancy/action item.

n. Verify the implementation of engineering changes and variance corrective actions to confirm consistency is
maintained between the product and its product configuration information.

(2) 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.

(3) Supplier shall complete all audit entry and exit criteria prior to completion or close-out of the audit.

NOTE: The Acquirer should consult IEEE 15288.2 Technical Reviews and Audits and all associated Addenda and
Amplifications for tailoring PCA Entry and Exit criteria which are determined through acceptance of the
Supplier's Systems Engineering Management Plan (SEMP).

NOTE: The Acquiring Activity may cite DI-SESS-81646 Configuration Audit Plan, DI-ADMN-81249 Conference
Agenda, and DI-ADMN-81250 Conference Minutes, for specifying the delivery of the data product that
emanates from meeting this requirement.

3.5.2 Functional Configuration Audit (FCA)

The objective of the FCA is to verify the CI’s and system’s performance against its approved functional and allocated
configuration documentation. The software CI (or CSCI) FCA ensures that all requirements have a related 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 performance requirements as documented in the
approved FCD and ACD.

(2) 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 and provided to the Acquirer for appropriate action.

(5) The Supplier shall use test data from the verification of the CI for the FCA.

(6) The Supplier shall not audit the CI without prior Acquirer approval of the FBL and ABL of the CI or system involved.

3.5.2.1 Supplier FCA Responsibilities

(1) The Supplier shall provide the following information to the Acquirer prior to the audit date:

a. List of items to be audited to include documents.

b. List of tasks to be accomplished at the FCA for the CI.

c. Matrix that identifies and provides traceability for all requirements; includes a cross reference to the test plans, test
procedures, test programs with automatic/automated test equipment (when applicable), test reports (results of
demonstrations, inspections and analyses for each requirement) and any known deficiencies supported by
applicable deficiency report numbers.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 32 of 46
(2) The Supplier shall provide the following information and data necessary to support the FCA.

a. The configuration documentation for the CI being audited.

b. All approved ECPs.

c. An account of the ECPs incorporated and tested as well as proposed.

d. Test plans, specifications, descriptions, procedures, recorded results and analyses for the CI.

e. A general discussion of the entire CI test effort delineating problem area accomplishments.

f. CI requirements that were not met, including a proposed remedy for each item.

g. Complete list of test requirements not yet performed and a plan for accomplishing each requirement.

h. Analyses or simulations for those requirements which cannot be completely verified through the use of testing.

i. Provide the following for CSCIs:

1. Database characteristics, storage allocation data and timing and sequencing characteristics for compliance with
specified requirements.

2. Documents that comprise or describe the contents or the use of the software product for format and
completeness (e.g., Software Product specification (SPS), User’s Manual, SVD))

3. Records that reflect the changes made to the developmental configuration for the CSCI.

4. Listing of all versions of the developmental and non-developmental software, firmware for the CSCIs that are
in the software library.

5. Findings of all internal CM and software, firmware QA audits of the CSCI.

j. Preliminary Design Review (PDR) and Critical Design Review (CDR) minutes. The Acquirer examines to ensure
that all findings have been incorporated and completed and that all action items are closed.

(3) The Supplier shall provide the FCA minutes to include the requirements traceability and test matrix.

3.5.3 Physical Configuration Audit (PCA)

The purpose of the PCA is to provide assurance to the Acquirer that the product configuration documentation (including
CAD models, drawings and software source code) accurately reflects the validated product, and the documentation is a
clear, complete and accurate representation of the intended design and to establish the final product baseline. The Supplier
and Acquirer conducts a PCA to examine the as-built configuration of a validated CI, comparing results against its design
documentation plus any approved changes. The software PCA is completed prior to performing 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 during the audit is documented by CM and evaluated by the project lead for
appropriate action.

(1) The Supplier shall conduct the PCA to verify that the PCD is consistent with the validated CI.

(2) The Supplier shall ensure compatibility between the CI with the Program Parts Selection List (PPSL), and examine the
CI to ensure that the proper parts are actually installed.

(3) When PCAs are conducted in increments, the Supplier shall conduct a final system-level PCA to ensure the system
PBL is correct.

(4) The Supplier shall use test data from the validation of the CI for the PCA.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 33 of 46
(5) The Supplier shall document each PCA non-compliance and provided to the Acquirer for appropriate action.

(6) If any portions of the inspections, tests, or audits need to be re-accomplished, the Supplier shall invite the Acquirer to
witness the required inspections, tests, and audits.

3.5.3.1 Supplier PCA Responsibilities

(1) The Supplier shall provide the following information to the Acquirer prior to the audit date:

a. Data describing the item configuration, to include:

1. CI specifications.

2. A list delineating both approved and outstanding changes against the CI.

3. Complete shortage list.

4. Acceptance test procedures and associated test data from those procedures and from the successful FCA.

5. Engineering drawing index including revision letters.

6. Operating and support manuals; including operator’s manuals, maintenance manuals, illustrated part
breakdown, programmer’s manuals, diagnostic manuals, etc.

7. Proposed Material Inspection and Receiving Report, DD Form 250.

8. Approved nomenclature and nameplates.

9. SVDs for software.

10. FCA official minutes for each CI.

11. Status of the current Original Equipment Manufacturer (OEM)/Supplier Quality Assurance Programs.

12. Parts Selection List.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
13. Interface Design Document for software.

14. Current approved issue of hardware development and software and interface requirements specifications to
include approved SCNs and approved variances.

15. Operational test plans, specifications, descriptions, procedures, recorded results and analyses for the CI.

16. CI requirements that were not met, including a proposed remedy for each CI.

17. Complete list of operational test requirements not yet performed and a plan for accomplishing each requirement.

18. Analyses or simulations for those requirements which cannot be completely validated through the use of testing.

19. Identification of all changes made during test.

20. Identification of any required changes not completed.

21. All configuration documentation, or electronic representations of the same, required to identify the CI.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 34 of 46
b. Identification of any difference between the physical configurations of the selected production CI(s) and the
development CI(s) used for the FCA, including certifications or demonstrations that these differences do not
degrade the functional characteristics of the selected CI(s).

c. Form, fit and function of the product model data as well as interface or integration data as proof that the product
model and derived output products are current. First Article Tests could be used to provide information in support
of PCA.

(2) The Supplier shall provide the following information and data necessary to support the PCA:

a. Complete product drawings/associated lists package (3D model type, cut-away drawings, and/or Model Based
Definitions) and associated manufacturing instruction sheets (and/or Computer Aided Manufacturing (CAM) data)
for each item of hardware or software identified.

b. Completed inspection reports for selected drawings (3D model type or cut-away drawings and/or Model Based
Definitions) and associated manufacturing instructions (and/or CAM data).

c. Records of the configuration baselines to compare with the Supplier’s engineering release system and change
control procedures, including interim releases of spares/repair parts provisioned prior to PCA to ensure delivery of
currently configured spares/repair parts.

d. Confirmation on the completion of the inspection and test of sub-supplier equipment end items at point of
manufacture.

e. PPSL to support examination of the CI to ensure that the proper parts are actually installed.

(3) The Supplier shall record the following information, at a minimum, in the PCA official minutes for each drawing (3D
model type or cut-away drawings and/or CAD presentation) reviewed and reporting results:

a. Drawing number/title (include revision letter).

b. List of manufacturing instructions and/or CAM data (numbers with change letter/titles) associated with this drawing.

c. A sample of part numbers reflected on the drawing.

3.5.4 Post-Audit Action

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

(1) The Supplier shall complete post-audit actions as assigned/directed.

3.5.5 Configuration Audit Summary

(1) The Supplier shall:

a. Prepare Configuration Audit Summary Report consisting of the applicable audit action items and discrepancy
information that was derived from the applicable audit checklist package.

b. Prepare a detailed configuration audit summary report after successful verification of the completed action items
has been conducted.

c. Provide the completed configuration audit summary report.

NOTE: The Acquiring Activity may cite DI-SESS-81022 Configuration Audit Summary Report, for specifying the delivery
of the data product that emanates from meeting this requirement.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 35 of 46
Table 1 - Cross reference for principles from ANSI/EIA-649

CM Functions and Principles (CM) Reference

Principle CM-1 CM implementation requires a balanced 3. Configuration Management Requirements
and continuous application of CM
functions and their underlying principles
throughout the product life cycle.
Configuration Management Planning and Management Reference
(CMP)
Principle CMP-1 The foundation for CM planning, which 3.1 Planning and Management
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.
Principle CMP-2 CM Planning documents how the 3.1 Planning and Management
organization will implement CM throughout
the applicable phases of the product life
cycle to provide consistency among the
product requirements, product
configuration information and the product.
Principle CMP-3 To implement planned CM functions, 3.1 Planning and Management
resources are identified and applied and
responsibilities to perform CM activities
are assigned.
Principle CMP-4 CM Procedures document how each CM 3.1 Planning and Management
function is implemented to accomplish the
intent of the CM planning.
Principle CMP-5 CM training assures that individuals 3.1 Planning and Management
understand their responsibility, authority,
and accountability as well as the
procedures for performing specified CM
tasks.
Principle CMP-6 Periodic assessment of the effectiveness 3.1.1 Monitoring Configuration Management
of CM procedures and tools and of Performance
compliance with the CM plan maintains
the health of the CM process.
Principle CMP-7 Performing CM includes responsibility for 3.1.2 Supplier’s Configuration Management Plan
the CM performance of subcontractors
and suppliers.
Principle CMP-8 Information processes, including collection 3.1.4 Product Configuration Documentation Processes
and processing, controlling status,
providing interoperability and exchange
and long term preservation, are essential
elements of effective CM planning and
management.
Configuration Identification (CI) Reference
Principle CI-1 Configuration identification is the basis 3.2 Configuration identification
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.
Principle CI-2 Product configuration information serves 3.2 Configuration identification
as the basis for development, production,
operation and maintenance/support of the
product.
--```,`,```,``,`,,

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 36 of 46
Table 1 - Cross reference for principles from ANSI/EIA-649 (continued)

CM Functions and Principles (CM) Reference

Principle CI-3 Enterprise identifiers designating the 3.2 Configuration identification.
responsible designer, manufacturer or
preparer provide uniqueness to the
identifiers of products and product
configuration information.
Principle CI-4 Product identifiers are assigned so that 3.2 Configuration identification
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.
Principle CI-5 Individual units of a product are assigned a 3.2 Configuration identification
unique product unit identifier when there is
a need to distinguish one unit of the
product from another.
Principle CI-6 When a product is modified, it retains its 3.2 Configuration identification
original product unit identifier, even though
its part identifying number is altered to
reflect a new configuration.
Principle CI-7 A series of like units of a product is 3.2 Configuration identification
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.
Principle CI-8 All documents reflecting product 3.2 Configuration identification
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.
Principle CI-9 Intentionally left blank See MIL-STD-881
Principle CI-10 Intentionally left blank N/A
Principle CI-11 A baseline is established by agreeing to 3.2 Configuration Identification
the definition of the attributes of a product
at a point in time and identifies a known
configuration to which changes are
addressed.
Principle CI-12 The configuration of any product or any 3.2 Configuration Identification
document, plus the approved changes, is
the current baseline.
Principle CI-13 Interfaces between products are managed 3.2.5 Interface Management
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.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 37 of 46
Table 1 - Cross reference for principles from ANSI/EIA-649 (continued)

Configuration Change Management (CCM) Reference

Principle CCM-1 Changes to a product are accomplished 3.3 Configuration Change Management
using a systematic, measurable change
process.
Principle CCM-2 Justifying the need for a change provides 3.3.1.1 Engineering Change Process
the rationale to commit resources required
to document, process and if approved,
implement the change.
Principle CCM-3 A unique change identifier enables tracking 3.3.1.1 Engineering Change Process
of the request for change and the status of
implementation and verification of the
approved change.
Principle CCM-4 Classification of a requested change 3.3.1.2 Classification and Authority of ECP
determines the appropriate level of review
and the applicable change approval
authority.
Principle CCM-5 As the primary vehicle for referencing and 3.3.1.3 ECP Format
managing a change, the request for
change document must be clear and
comprehensive from technical, cost and
scheduling perspectives.
Principle CCM-6 In evaluating whether a requested change 3.3.1.4 Supporting data
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.
Principle CCM-7 Change approval decisions are made by 3.3.1.5 ECP Decisions
an appropriate authority who can commit
resources to implement the change. The
decision-maker must be aware of all
impacts and cost factors.
Principle CCM-8 An approved change is implemented in 3.3.1.5 ECP Decisions
accordance with documented direction
approved by the appropriate level of
authority.
Principle CCM-9 If it is necessary to temporarily depart from 3.3.2 Request for Variance (RFV)
specified baseline requirements, a request
for variance should be identified, classified,
documented, coordinated, evaluated and
dispositioned
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Configuration Status Accounting (CSA) Reference

Principle CSA-1 Configuration Status Accounting (CSA) 3.4 Configuration Status Accounting (CSA)
provides an accurate, timely information
base concerning a product and its product
configuration information throughout the
product life cycle.
Principle CSA-2 Information about the product and the 3.4 Configuration Status Accounting (CSA)
product configuration information are
captured as CM tasks are performed;
reporting is accessible to support
program/project activities as needed.
Principle CSA-3 Metrics derived from configuration status 3.4.2 CSA Analysis Requirements
accounting information are used to
evaluate and improve CM process
effectiveness.

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 38 of 46
Table 1 - Cross reference for principles from ANSI/EIA-649 (continued)

Configuration Verification and Audit Reference

Principle CVA-1 Verifying a product’s compliance with the 3.5 Configuration Verification and Audits
physical, functional and interface
requirements in approved product
definition information validates the effective
basis for managing product configuration.
Principle CVA-2 Each change must be verified to ensure 3.5 Configuration Verification and Audits
consistency is maintained between the
product, its configuration information and
related support assets such as test
equipment and spare parts.
Principle CVA-3 Configuration audits are a summation of 3.5 Configuration Verification and Audits
the configuration verification process,
where necessary to establish baselines at
key points in the product life cycle.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 39 of 46
Table 2 - Data item descriptions (DIDS) and DD forms

The below DIDs and DD Forms were current as of the date of this standard. The Acquisition Streamlining and
Standardization (ASSIST) database should be researched at http://quicksearch.dla.mil to ensure that only current and
approved DIDs are cited on Contract Data Requirements List (CDRL), DD Form 1423. The following applies for the data
listed in Table 2.

1. Table 2 is not an all-inclusive list and not all DIDs listed are applicable to all contracts.

2. The DIDs listed in Table 2 should not be placed on contract without verifying their current revision in the ASSIST
database. The DIDs and DD Forms listed are the base identifiers numbers and do not include revisions. All DIDs should
be tailored appropriately. The term "tailoring" means strictly removal of inapplicable or undesirable parts of the DID that
are cited in Block 16 of the CRDL, DD Form 1423.

Requirement
Note
Associated
DID Number DID Title DD Forms with DID
DI-SESS-80463 Engineering Release Record DD Form 2617 3.2.3 (8)
DI-MISC-80508 Technical Report–Study/Services 3.1 (1)
DI-SESS-80639 Engineering Change Proposal DD Form 1692 3.3.1 (1)
3.3.1.3 (1)
DI-SESS-80640 Request for Variance DD Form 1694 3.3.2 (6)
DI-SESS-80642 Notice of Revision DD Form 1695 3.3.4 (2)
DI-SESS-80643 Specification Change Notice DD Form 1696 3.3.3 (2)
DI-SESS-80858 Supplier's Configuration Management Plan 3.1 (1k)
3.1.2 (1)
DI-SESS-81011 Drawing/Model Number Assignment Report 3.2 (4d)
DI-SESS-81022 Configuration Audit Summary Report 3.5.5 (1c)
DI-SESS-81121 Baseline Description Document 3.2. (3k)
DI-SESS-81245 Installation Completion Notification 3.4.1.5
DI-SESS-81248 Interface Control Document (ICD) 3.2.5.1 (4)
DI-ADMN-81249 Conference Agenda 3.5.1 (3)
DI-ADMN-81250 Conference Minutes 3.5.1 (3)
DI-SESS-81253 Configuration Status Accounting Information 3.4.1

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
DI-SESS-81254 Request for Nomenclature DD Form 61 3.2. (3k)
3.2.1 (2g)
DI-SESS-81646 Configuration Audit Plan 3.5.1 (3)
DI-SESS-81879 Configuration Item Documentation Recommendation 3.2.1 (2g)

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 40 of 46
Table 3 - Additional associated DIDS

The below DIDs were current as of the date of this standard. The ASSIST database should be researched at
http://quicksearch.dla.mil to ensure that only current and approved DIDs are cited on CDRL, DD Form 1423. The following
applies for the data listed in Table 2.

1. Table 3 is not an all-inclusive list and not all DIDs listed are applicable to all contracts.

2. The DIDs listed in Table 3 should not be placed on contract without verifying their current revision in the ASSIST
database. The DIDs and DD Forms listed are the base identifiers numbers and do not include revisions. All DIDs should
be tailored appropriately. The term “tailoring" means strictly removal of inapplicable or undesirable parts of the DID that
are cited in Block 16 of the CDRL, DD Form 1423.

DI-SESS-81218 Product Baseline Index (PBLI)

DI-SESS-81343 Information Security (INFOSEC) Boundary Configuration Management Plan
DI-SESS-81830 As-Built Configuration List-Common (ABCL-C)
DI-SESS-81856 Contractual Baseline Report

4. NOTES

4.1 A change bar (l) located in the left margin is for the convenience of the user in locating areas where technical revisions,
not 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

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 41 of 46
ANNEX A - TAILORING WORKSHEET

A.1 GENERAL

This Annex is a tool for practitioners to use to aid them in tailoring requirements of this standard and is not intended to be
part of the contract.

A.2 MATRIX DESCRIPTION

A check mark in the column entitled "Applies" indicates where the Acquirer has determined the applicability of the SAE
Configuration Management Requirements for Defense Contracts, EIA-649-1.

Sub Applies SOW CDRL CDRL

Paragraph Requirement Requirement Y/N Change or Clarification Paragraph DID No. Number Tailoring
3. Configuration (1)
Management
Requirements
(2)
(3)
(4)
3.1 Planning (1) a. DI-SESS-80858
and Supplier's
Management Configuration
Management Plan
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
3.1.1 Monitoring (1)
Configuration
Management
Performance
(2)
3.1.2 Supplier’s (1) DI-SESS-80858
Configuration Supplier's
Management Configuration
Plan Management Plan
3.1.3 Technical (1)
Reviews
3.1.4 Product (1)
Configuration
Documentation
Processes
(2)
3.2 (1)
Configuration
Identification
(2)
(3) a. DI-SESS-81254
Request for
Nomenclature, DI-
SESS-81121
Baseline
Description
Document
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 42 of 46
Sub Applies SOW CDRL CDRL
Paragraph Requirement Requirement Y/N Change or Clarification Paragraph DID No. Number Tailoring
(4) a.
b.
c. DI-SESS-81011
Drawing/Model
Number
Assignment Report
d.
3.2.1 (1)
Configuration

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
Item Selection
(2) a.
b.
c.
d.
e.
f.
g. DI-SESS-81254
Request for
Nomenclature and
DI-SESS-81879
Configuration Item
Documentation
Recommendation
3.2.2
Configuration
Baselines
Types
3.2.2.1 (1)
Configuration
Baselines and
Their
Configuration
Documentation
(2)
3.2.2.2 (1) a.
Functional
Configuration
Documentation
(FCD)
b.
c.
3.2.2.2.1 (1) a.
Allocated
Configuration
Documentation
(ACD)
b.
c.
3.2.2.2.2 (1) a.
Product
Configuration
Documentation
(PCD)
b.
c.
d.
e.
f.
g.
h.
(2)
3.2.2.3 (1)
Maintenance of
Product
Configuration
Documentation
3.2.3 (1) DI-SESS-80463
Engineering Engineering
Release System Release Record
(2)
(3)
(4)

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 43 of 46
Sub Applies SOW CDRL CDRL
Paragraph Requirement Requirement Y/N Change or Clarification Paragraph DID No. Number Tailoring
(5)
(6)
(7)
3.2.4 (1)
Configuration
Identifiers
(2)
(3)
(4)
3.2.4.1 Product (1)
Identification/M
arking
(2)
(3)
(4)
3.2.4.2 Software (1) a.
Marking and
Labeling
b.
c.
d.
e.
3.2.5 Interface
Management
3.2.5.1 Interface (1) DI-SESS-81248
Identification Interface Control
Document
(2)
(3)
(4)
3.2.5.2 Interface (1) a.
Control
Working Group
(ICWG)
Membership
b.
c.
d.
3.3 (1)
Configuration
Change
Management
(2) a.
b.
c.
d.
e.
f.
g.
(3)
3.3.1 (1) DI-SESS-80639
Engineering Engineering
Change Change Proposal
Proposal (ECP)
3.3.1.1 (1) a.
Engineering
Change
Process
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
3.3.1.2 (1)
Classification

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 44 of 46
Sub Applies SOW CDRL CDRL
Paragraph Requirement Requirement Y/N Change or Clarification Paragraph DID No. Number Tailoring
and Authority
of ECP
3.3.1.3 ECP (1) DI-SESS-80639
Format Engineering
Change Proposal
(2)
3.3.1.4 (1)
Supporting
Data
(2) a.
b.
(3)
3.3.1.5 ECP
Decisions
3.3.1.6 (1)
Engineering
Change
Priorities
3.3.1.7 Related
Engineering
Changes
3.3.1.7.1 (1)
Related
Engineering
Changes –
Single Prime
3.3.2.7.2 (1)
Related
Engineering
Changes –
Single Prime
Multiple
Procuring
Activates
(2)
3.3.1.7.3 (1)
Related
Engineering
Changes –
Separate
Primes
(2)
(3)
(4)
3.3.1.8 Minor (1)
(Class II) ECP

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---
3.3.2.8.1 (1)
Concurrence of
Classification
(2)
(3)
3.3.1.8.2 (1)
Approval of
Minor (Class II)
Changes
3.3.2 Requests (1) DI-SESS-80640
for Variance Request for
(RFV) Variance
(2)
(3)
(4)
(5)
(6)
3.3.2.1 (1)
Recurring
Variances
(2)
3.3.2.2 (1)
Classification
of Variances
(2)
(3)

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 45 of 46
Sub Applies SOW CDRL CDRL
Paragraph Requirement Requirement Y/N Change or Clarification Paragraph DID No. Number Tailoring
3.3.2.3 RFV (1)
Decisions
(2)
3.3.2.4 Minor (1)
RFVs
3.3.3 (1) for DI-SESS-80643
Specification Specification
Change Notice Change Notice
(SCN)
(2)
3.3.4 Notices of (1) DI-SESS-80642
Revisions Notice of Revision
(NORs)
(2)
3.4 (1)
Configuration
Status
Accounting
(CSA)
(2)
3.4.1 Supplier (1) DI-SESS-81253
CSA System Configuration
Status Accounting
Information
(2)
(3) a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
(4) a.
b.
c.
d.
(5) DI-SESS-81245
Installation
Completion
Notification
3.4.2 CSA (1)
Analysis
Requirements
3.5
Configuration
Verification and
Audits
3.5.1 Common (1) a. DI-SESS-81646
Supplier Audit Configuration
Responsibilities Audit Plan, DI-
ADMN-81249
Conference
Agenda, and DI-
ADMN-81250
Conference
Minutes
b.
c.
d.
--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

e.
f.
g.
h.
i.
j.
k.
l.
m.
n.
Copyright SAE International
Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT
 SAE INTERNATIONAL EIA-649-1 Page 46 of 46
Sub Applies SOW CDRL CDRL
Paragraph Requirement Requirement Y/N Change or Clarification Paragraph DID No. Number Tailoring
(2)
(3)
3.5.2 Functional (1)
Audit (FCA)
(2)
(3)
(4)
(5)
(6)
3.5.2.1 Supplier (1) a.
FCA
Responsibilities
b.
c.
(2) a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
(3)
3.5.3 Physical (1)
Configuration
Audit (PCA)
(2)
(3)
(4)
(5)
(6)
3.5.3.1 Supplier (1) a.
PCA
Responsibilities
b.
c.
(2) a.
b.
c.
d.
e.
(3) a.
b.
c.
3.5.4 Post Audit (1)
Actions
3.5.5 (1) a. DI-SESS-81022
Configuration Configuration
Audit Audit Summary
Certification Report
b.
c.

--```,`,```,``,`,,,,`,`,`,```,`-`-`,,`,,`,`,,`---

Copyright SAE International

Provided by IHS under license with SAE Licensee=Defense Contract Mgmt Agency/5935922100
No reproduction or networking permitted without license from IHS Not for Resale, 04/08/2015 06:03:27 MDT