Attachment_20_-_CM_Plan_ACV-PLN-02001_v1.0_Signed.pdf

UNCLASSIFIED

AMPHIBIOUS COMBAT VEHICLE

PHASE 1 INCREMENT 1

(ACV1.1)

CONFIGURATION

MANAGEMENT PLAN

(CMP)

ACV-PLN-02001

VERSION 1.0

9 FEBRUARY 2015

DISTRIBUTION A: Approved for public release: distribution unlimited.

PROGRAM MANAGER, ADVANCED AMPHIBIOUS

ASSAULT (PM AAA)

i

UNCLASSIFIED

ii

REVISION HISTORY

Revision Summary of Changes Approved by Date

1.0 Initial Release J.M. GARNER 24Feb2015

UNCLASSIFIED

iii

Table of Contents

1.0 Introduction

1.1 Purpose

1.2 Deviation Policy

1.3 Scope

1.4 Approach for Plan Updates

1.5 Program Description

1.6 Key Terms and Definitions

2.0 Applicable Documents

3.0 Configuration Management Strategy

4.0 Configuration Management Organizations and Responsibilities

4.1 Approval Authority

4.2 Program Manager Advanced Amphibious Assault

4.3 ACV Product Manager

4.4 Assistant Product Manager-Engineering

4.5 ACV CM Manager

4.6 Functional Leads and Subject Matter Experts

4.7 Integration Integrated Product Team

4.8 Contractor(s) Responsibilities

5.0 Configuration Identification

5.1 Technical Data

5.1.1 Technical Data Package

5.2 Configuration Baselines

5.2.1 Functional Baseline

5.2.2 Allocated Baseline

5.2.3 Product Baseline

5.3 Configuration Item Identification Numbers

5.3.1 Hardware and Software Configuration Items

5.3.2 Documentation

5.3.3 Specifications

UNCLASSIFIED

iv

5.3.4 Media Labeling

5.4 Equipment Marking and Identification

6.0 Configuration Change Control

6.1 Change Classification

6.1.1 Engineering Change Proposal

6.1.2 Class II ECP Criteria

6.1.3 Request for Variance

6.2 Forms

6.3 Change Control Process

6.3.1 Process Description

6.3.2 ECP Processing

6.3.3 Request for Variance Processing

6.3.4 Vehicle Software Updates

6.3.5 Test Incident Report and Change Request Processing

6.4 ACV Configuration Control Boards

6.4.1 Configuration Review Board

6.4.2 Configuration Control Board

6.4.3 ACV CCB Responsibilities

6.4.4 Contractor CCB

7.0 Configuration Status Accounting

7.1 CM Tools

7.1.1 ACV Integrated Data Environment

7.1.2 CM System

7.1.3 DOORS

7.2 CM Metrics

8.0 Configuration Audits

8.1 Functional Configuration Audit

8.2 Physical Configuration Audit

8.3 Follow-On Audits

9.0 Interface Control

9.1 Integration IPT

UNCLASSIFIED

v

9.2 Memorandum of Agreement

10.0 Data Management

10.1 Technical Data Management

10.2 Program-Level Documentation Development

Acronyms

UNCLASSIFIED

1.0 Introduction

1.1 Purpose

The purpose of this plan is to define and describe the requirements, responsibilities, process, and procedures necessary for the Configuration Management (CM) of the Amphibious Combat

Vehicle Phase 1 Increment 1 (ACV 1.1), hereafter referred to as ACV. The implementation of the requirements and procedures contained in this CM Plan (CMP) are the responsibility of the

Program Manager Advanced Amphibious Assault (PM AAA). These requirements and procedures apply to the ACV System and provide the guidelines to be used by the ACV

Configuration Control Board (CCB).

1.2 Deviation Policy

The ACV Product Manager (PdM) must approve deviations from this plan. Recommendations for changes or deviations to this plan should be submitted in writing to the ACV CM Manager.

1.3 Scope

The scope of the CMP applies to the development, production, operations, sustainment, and disposal of ACV Configuration Items (CIs). This plan outlines specific processes and procedures used for performing Configuration Identification, Change Control, Configuration

Status Accounting (CSA), and Configuration Audits for CIs under the direction of PM AAA.

This plan supports the ACV Systems Engineering Plan (ACV-PLN-01002), which describes the interdisciplinary processes and Systems Engineering (SE) strategies for use throughout the life cycle of the ACV.

1.4 Approach for Plan Updates

This CMP was developed following the guidance of MIL-HDBK-61A, Configuration

Management Guidance, and SIAT-HDBK-003, CM Implementation Handbook. This plan is intended to be a living document and will be updated as required. Requests for changes, deviation, or updates to this CMP are submitted to the ACV CM Manager who will review and route the request for changes or revision to relevant management and stakeholders for review and recommendation for concurrence. The ACV CM Manager will retain an electronic file of all submitted requests for change, related documents, and revision packages. Approved CMP revision history will be logged in the Revision History Log of this CMP.

1.5 Program Description

The ACV supports expeditionary protected mobility capability and capacity requirements by enhancing Marine Operating Forces’ tactical and operational mobility with balanced levels of performance, protection, and payload. The ACV will facilitate maneuver throughout an operating area to include the ability to cross rivers and inland waterways. The ACV will be capable of using water obstacles, including the sea within the littoral operating area, as maneuver

UNCLASSIFIED

space via a robust tactical swim capability (shore-to-shore). This tactical level of water mobility will enable shore-to-shore maneuver and complement the operational (ship-to-shore) capability of the Assault Amphibious Vehicle. The ACV is required to support the Ground Combat

Element in the conduct of operations ranging from irregular to major combat operations.

The ACV 1.1 Program will be initiated at Milestone (MS) B and will award two (2) contracts to manufacture 16 Engineering, Manufacturing, and Development (EMD) vehicles per contract, integrate Government Furnished Equipment (GFE), and provide test support. The contracts will also contain options for Low Rate Initial Production (LRIP) and Full Rate Production (FRP). At

MS C, the Government will down select to a single Contractor and exercise the option(s) to procure 60 ACV LRIP vehicles. After the FRP decision approval, the Government will exercise the option(s) to procure an additional 148 ACVs.

1.6 Key Terms and Definitions

Build - An operational version of a system or component that incorporates a specified subset of the capabilities that the final product will provide.

Configuration Control Authority (CCA) - Activity or organization that controls the configuration of the product and determines what changes are to be installed or incorporated in that product. The CCA to effect a product configuration change under a contract does not automatically mean that a change can be directed or made to a document for which another organization is the controlling design activity and has content responsibility.

Current Document Change Authority (CDCA) - An agency, activity, or organizational entity that is responsible for the content of the document and is the only authority that can effect changes to the document.

Free text - Human-readable information other than what is encoded in a machine-readable medium.

Human-readable information - Information intended to be conveyed to a person.

Human-readable interpretation - Human-readable information provided adjacent to a machine-readable medium representing the encoded data within the medium.

Human translation - Human-readable information provided within proximity of the machine-readable medium, representing portions of the information encoded and data field descriptions not encoded in the symbols.

Item unique identification (IUID) - A system of establishing unique item identifiers within the

Department of Defense (DoD) by assigning a machine-readable character string or number to a discrete item, which serves to distinguish it from other like and unlike items.

Machine-readable Information (MRI) marking - A pattern of bars, squares, dots, or other specific shapes containing information interpretable using equipment specifically designed for that purpose.

The patterns may be applied for interpretation by digital imaging, infrared, ultra-violet, or other interpretable reading capabilities.

UNCLASSIFIED

Nomenclature - The approved item name or the name as designated in the contract documents.

Serial number - An assigned designation that provides a means of identifying a specific individual item.

Unique identification (UID) - A system of establishing globally unique and unambiguous identifiers within the Department of Defense (DoD), which serve to distinguish a discrete entity or relationship from other like and unlike entities or relationships.

UNCLASSIFIED

2.0 Applicable Documents

The following documents and associated references, at their current revision level, are applicable to the ACV program CM. In the event that this plan and the listed documents result in conflict, this plan will take precedence.

Document Identifier Title

ASME Y14.100 (Series) Engineering Drawing Practices

MIL-STD-1806

Marking Technical Data Prepared By Or For The Department

Of Defense

MIL-STD-129P Military Marking For Shipment And Storage MIL-STD-130N Identification Marking Of U.S. Military Property

MIL-STD-31000 Technical Data Packages

MIL-HDBK-61A Configuration Management Guidance

MIL-HDBK-1467 Acquisition of Software Environments and Support Software

ANSI/EIA-649-B National Consensus Standard for Configuration Management

IEEE/EIA 12207.2 Software Lifecycle Process- Implementation Considerations

ISO/IEC 12207 Software Life Cycle Processes

AAA-PRO-01002 Document Lifecycle Process

AAA-PRO-01006 Requirements Development Process

AAA-PRO-01009 Problem Reporting and Corrective Action Process

AAA-PRD-01010 Configuration Review Board Procedure

AAA-PRD-01011 Configuration Control Board Procedure

AAA-PRD-01002 Document Identification Procedure

AAA-PRD-01004

Engineering Metrics and Technical Performance Measures

Procedure

ACV-PLN-01002 ACV Systems Engineering Plan

ACV-PLN-04001 ACV Item Unique Identified Plan

MCSCO 4130.1

Marine Corps System Command Order, Configuration

Management Policy

DoD 5010.12-M Procedures for the Acquisition and Management of Technical

Data

SIAT-HDBK-003 MCSC CM Implementation Handbook

UNCLASSIFIED

3.0 Configuration Management Strategy

After SRR-1, The ACV1.1 System Performance Specification will be baselined and placed under

Government configuration control establishing the Functional Baseline. The Government has

CDCA of the functional baseline, with ECP and Request for Variance (RFV) approval residing within PM AAA. Changes to the Functional Baseline can only be made through Government approved ECPs and formal contract changes between the Program Office and the Contractor(s).

The ACV allocated and initial product baselines developed by the Contractor will be reviewed and established at PDR/CDR. Each Contractor will be required to deliver a Master CI List identifying the ACV Configuration Items (CIs), associated configuration documentation

(technical baseline artifacts) and to which baseline it belongs, among other attributes (i.e.

CDCA). Since the ACV EMD phase will be competitive, during the EMD phase the

Contractor(s) will have CCA of the system and CDCA for released configuration documentation

(allocated and product baselines) for which another Government activity or commercial organization is not already the CDCA. The Government will not take control of the Contractor’s allocated and initial product baselines during EMD; however, the Government will maintain

CCA over the GFE throughout the lifecycle. This affords development Contractors maximum flexibility during the upfront competitive phase to make changes to the allocated and product baselines as they proceed through EMD vehicle build and competitive testing. During the upfront competitive phase, the ACV program office will receive CDRL deliveries of

Configuration Status Accounting (CSA) and Vehicle Configuration Data to ensure Government insight and visibility into the development and maturity of each Contractor’s design solution and the vehicles’ configuration throughout testing.

After down-select to a single LRIP Contractor, the ACV Program will conduct a Physical

Configuration Audit (PCA) of LRIP vehicles, to verify that the necessary controls, measures, and manufacturing processes are in place to consistently produce as-built configurations with minimal variability against the as-released configuration baseline. The LRIP PCA will verify and establish the product baseline that will be delivered to the field. After completion of the

PCA, the Government will assume CCA of the ACV and will act as CDCA over the selected allocated and product baseline configuration documents. From this point forward, changes to the

ACV configuration have to be submitted to the Government for approval. Configuration Item

(CI) attributes such as mission criticality, safety, cost, and interface risks will be used to make final decisions on CDCA and timing of ownership turnover.

UNCLASSIFIED

4.0 Configuration Management Organizations and Responsibilities

This section delineates how the CM effort will be integrated organizationally. It describes the major roles and their responsibilities associated with the CM activities of the ACV Program.

4.1 Approval Authority

The Approval Authority is the person responsible for approving or disapproving ECPs/RFVs.

The Approval Authority at PM AAA for ACV engineering changes has been delegated to the

ACV PdM, unless it is safety critical (requiring a safety letter or message). In this rare instance, PM AAA will be the Approval Authority.

4.2 Program Manager Advanced Amphibious Assault

Has overarching responsibility and authority for how CM is implemented and executed on the ACV program

Approves ACV CM Plan

Approval Authority for approving or disapproving safety related ECPs/RFVs as defined in Section 6.0 Configuration Change Control

Approves the levels and delegation of configuration change authority for both CIs themselves and the technical data products that describe them in accordance with authority delegation from higher authority

Provides the resources required to execute the CM processes

Ensures that the ACV statement of work and contract deliverable language is tailored to support the delivery of appropriate CM data in accordance with program acquisition and sustainment strategies

4.3 ACV Product Manager

Designates a qualified CM Manager for the Projects under his or her cognizance

Ensures successful implementation of CM processes for the Projects in compliance with

MCSCO 4130.1 Command CM policy

Ensures CM Manager participation in efforts and decisions relating to contracts, systems engineering, logistics, interfaces, system upgrades, re-planning, configuration documentation, Program tools, and sustainment

Recommends the levels and delegation of configuration change authority for CIs, all cognizant subsystem CIs, and the baseline technical data products that describe them

Approval Authority for ECPS/RFVs as delegated by PM AAA and defined in Section 6.0

Configuration Change Control

Chairs the ACV CCB

UNCLASSIFIED

4.4 Assistant Product Manager-Engineering

Approves CM processes and procedures developed to support this plan

Recommends the levels and delegation of configuration change authority for CIs, all cognizant subsystem CIs, and the baseline technical data products that describe them

Evaluates and assesses the extent of impacts to areas of proposed changes to their vehicle’s requirements and designs

Voting member of the ACV CCB and Chairs the CCB in the absence of PdM and Deputy

PdM

Chairs the ACV Configuration Review Board (CRB)

Sponsor or advocate to the ACV CCB for proposed changes primarily affecting vehicle requirements or Government controlled CIs

Ensures CM requirements and CDRLs are identified in contracts

Ensures CM Manager participation in efforts and decisions relating to contracts, systems engineering, logistics, interfaces, system upgrades, re-planning, configuration documentation, Program tools, and sustainment

4.5 ACV CM Manager

Designated by the ACV PdM to execute and direct CM activities for the ACV program

Works with the PdM and Assistant Product Manager-Engineering (APdM-E) for ACV to ensure that adequate resources and funding are available to perform CM activities

Develops the CMP during the initial system development phase and revises the plan as necessary throughout the lifecycle

Oversees CMP implementation and development of detailed CM policy and procedures

Participate in and attend technical and program reviews

Coordinates and assists with the planning and execution of functional or physical configuration audits

Reviews CM status accounting, metric reports, and CM CDRLs

Reviews and monitors the Contractor’s CM activities

Identifies CM project risks, provides related data to the Risk Manager, and implements appropriate risk management measures

Identifies opportunities for CM process improvement and develops strategies and implementation plans

Establishes the CM environment

Provides support to the CRB and CCB

Ensures CRB/CCB members and program personnel receive adequate training to perform their CM activities

Prepares and submits standard reports, as necessary, to document the status of CM activities

UNCLASSIFIED

4.6 Functional Leads and Subject Matter Experts

Each functional lead (i.e. Logistics, Reliability) or subject matter expert is responsible for participating in the change control process by reviewing proposed changes and assessing them based on their expertise area. Their responsibilities are as follows:

In accordance with established guidelines, recommends which baseline technical data products should fall under PM AAA authority for change control

Evaluates and assesses the extent of impacts to their functional areas of proposed changes to requirements and vehicle designs

Sponsors or advocates to the ACV CCB for proposed changes primarily affecting their applicable requirements or cognizant Government managed CIs

Advise the PdM, Deputy PdM, or APdM-E on best means and timing of implementing a change based on schedule, cost, and contract considerations

4.7 Integration Integrated Product Team

The Integration Integrated Product Team (IPT) is responsible for overseeing the integration of all

GFE on ACVs. The IPT ensures that interfaces are identified in the Interface Control drawings/documents and resolves interface issues. Changes to GFE interfaces that affect their integration onto ACVs will follow the change control process as defined in this CMP. The

Integration IPT is responsible for ensuring the CM Manager participation in efforts and decisions relating to interfaces, upgrades, re-planning, configuration documentation, and sustainment of all

GFE to be integrated.

4.8 Contractor(s) Responsibilities

The Contractor(s) is/are responsible for implementing a CM program that supports and interfaces with the ACV program. CM processes shall be in place to address the CM activities and management for Contractor(s) CIs during development, production, operations, and sustainment that support the ACV program. The Contractor(s) is/are responsible for ensuring Suppliers implement a CM program that will effectively manage CIs.

UNCLASSIFIED

5.0 Configuration Identification

Configuration Identification is the systematic identification of a CI, together with all technical documentation that identifies and defines its characteristics, so it can be designed, procured, manufactured, tested, operated, or repaired during its life cycle. The criterion for selecting an item to be designated as a CI is based on the need to control its functional, technical, or operational performance; interfacing or physical characteristics, including cost considerations.

The process of identifying items requiring CM is a tiered and evolutionary process that drives to greater levels of detail as the system matures.

As each CI is identified, the configuration documentation needed to describe it, and the interfaces between CIs will be identified. The configuration documentation associated with each

CI provides the basis for configuration control, logistics support, post-deployment software support, and re-procurement. As described in ANSI/EIA-649-B, all other product documentation

(such as operation and maintenance manuals, illustrated parts breakdowns, test plans and procedures) is based on and related to information in the configuration documentation. CIs and their configuration documentation are only identified to the level necessary for design, procurement, manufacture, test, operation, or repair (by USMC Maintenance as defined by

Marine Corps Order 4790.25 Ground Equipment Maintenance Program) during their life cycle.

The Contractor, as the CCA and primary CDCA, during the EMD phase, will identify the ACV

CIs, associated configuration documentation, and determine the appropriate CDCA who will manage and control changes to the CIs, (via controlling changes to their functional, allocated, and product requirements once these have been baselined for each CI). The Contractor will establish and deliver to the Government a Master CI List containing a hierarchical list of ACV

CIs, the documentation that defines each CI, and the CDCA of each configuration document.

This Master CI List provides the basis for the CM of the ACV. The Contractor will recommend, subject to Government agreement, the CIs and configuration documentation that should be designated for Government control. During LRIP when the Government assumes CCA and

CDCA any changes to the configuration baselines will be submitted to the Government for review and approval in accordance with this CMP. Secondary CDCAs will work with their

Suppliers to establish further breakdowns of these CIs, the data that describes their requirements, and who will control changes to those requirements once the ABL and PBL are established.

5.1 Technical Data

The ACV Master CI List defines the CI documentation that serves as the basis for the ACV technical data.

ACV technical data is recorded information (regardless of the form or method of recording) of a scientific or technical nature (including computer software documentation) relating to the ACV development and production. Technical data does not include application computer software; or

UNCLASSIFIED

financial, administrative, cost, pricing, or management data; or other information incidental to contract administration.

Technical Data Package (TDP) is required to define and document an engineering design or product configuration, sufficient to allow duplication of the original items. TDP is a technical description of an item adequate for supporting an acquisition strategy, production, engineering, and logistics support. The description defines the required design configuration and procedures necessary to ensure adequacy of item performance.

5.1.1 Technical Data Package

The ACV Program will consider the merits and costs of procuring the TDP to promote future re-procurement competition and operational support cost reduction through delivery of or access to relevant drawings and manufacturing data, processes, and supply logistics part data for sustainment. The Government will receive an initial Product Baseline at the Critical Design

Review. The Government plans to receive an updated product baseline deliverable that forms the basis for production, sustainment, future changes, and upgrades at the System Verification

Review. The Government, through the Prime Contractor and the Prime Contractor interface with

Suppliers, will have access to the technical data and technical data packages via reports, tools, etc.

The ACV Program will follow the guidance in MIL-STD-31000A Technical Data Packages

(TDP) for the selection of TDP Level, Type, Elements, and TDP data management products that will make up the TDP. The ACV TDP might consist of:

Specifications (system, subsystems, components)

Engineering drawings

Models and Simulations

Architectures (i.e. system, physical, etc.)

Software Descriptions

Indenture parts lists/Bill of Materials

Interface Control Drawings/Documents

Processes

Test Plans, Procedures, Reports

Documents that define the physical geometry, material composition, performance characteristics, manufacture, and assembly

Assembly Information (i.e. Critical torques, sealant type/locations, special procedures, and tolerances)

5.2 Configuration Baselines

The ACV CM employs three (3) types of configuration baselines: the functional, allocated, and product baselines, to provide for the progressive definition and documentation of the requirements and design information describing the various CIs designated for the ACV system.

UNCLASSIFIED

Configuration baselines will be managed and delivered in accordance with the ACV CM

Strategy defined in Section 3.0. Prior to delivery, the configuration will be baselined by the

ACV CCB. The CCB will generate documentation that clearly lists the data elements that make up the baseline. Any changes to an ACV approved baseline will be processed in accordance with Section 6.0 for approval prior to implementation.

5.2.1 Functional Baseline

The Government developed, owned, and managed FBL is concerned with system-level descriptions in terms of performance. The ACV FBL configuration documentation includes performance characteristics, verification tests of those characteristics, CI interfaces, design constraints, and Integrated Logistics Support (ILS) requirements. Initially, the FBL will be managed within the Government’s Dynamic Object Oriented Requirements System (DOORS) requirements database (AAA-PRO-01006 PM AAA Requirements Development Process) and maintained within a CM database as items such as the Capability Development Document

(CDD) and the ACV System Performance Specification. The CM database will track, store, and report Change History as well as store each version of the CI. DOORS will be used as the

Requirements database for tracing and reporting functionalities that may not be available from the CM database. The Government will maintain CDCA of all FBL documentation.

The ACV FBL consists of the ACV1.1 System Performance Specification.

5.2.2 Allocated Baseline

The ABL is concerned with subsystem/component level descriptions in terms of performance that is consistent with meeting the system-level performance characteristics. The ABL for a CI describes the functional and interface requirements that are allocated from those of the system or higher level CI and the verification required to demonstrate achievement of those characteristics.

The ACV ABL will primarily consist of specifications and Interface Control Documents (ICDs) at the subsystem CI level and below. The elements that make up the ACV ABL will be defined in the Master CI List. The ACV ABL will be managed within the Contractor’s requirements management database and maintained within the Contractor’s CM databases through the EMD phase. With the exception of GFE, the Contractor is allowed to make changes to the requirements and verification methods in the ACV ABL throughout the EMD phase and up until the LRIP Lot1 PCA. After the LRIP Lot1 PCA, the Government will assume control of the ABL and CM will be formally transitioned from the Contractor to the Government configuration control authority. Changes to Government controlled ABL will be submitted to the CCB for review and approval in accordance with this CMP.

5.2.3 Product Baseline

The PBL establishes detailed descriptions of systems, subsystems, and components. The PBL for a CI describes the configuration during the production, fielding/deployment, and operational support phases of its life cycle. The elements that make up the ACV PBL will be defined in the

UNCLASSIFIED

Master CI List. The production representative PBL is established at the PCA of each designated system, subsystem, or item. For the ACV, the PCA for the Personnel Variant will be conducted on LRIP vehicle’s PBL. Upon successful completion of the PCA, CM of appropriate portions of the product baselines will be formally transitioned from the Contractor to the proper Government configuration control authority and CDCA as applicable. Subsequent PCAs may be performed if significant changes are made to the PBL. Changes to Government controlled PBL CI’s and configuration documentation will be submitted to the CCB for review and approval in accordance with this CMP.

5.3 Configuration Item Identification Numbers

5.3.1 Hardware and Software Configuration Items

CIs, both hardware and software, are uniquely identified for tracking purposes. Each hardware

CI will be identified and managed following guidance as outlined in MIL-HDBK-61A and

ASME Y14.XX series. Each software CI will be identified and managed following guidance as outlined in MIL-HDBK-1467 and ISO/IEC 12207.

CI identification will include, at a minimum, the following:

Part numbers

Serial numbers

Nomenclature

CAGE code

IUID

CDCA

Software versions, if applicable

Firmware versions, if applicable

5.3.1.1 Unique Identification and Serialization

UID, when used on new equipment, major modifications, and re-procurements of equipment and spares, will be in accordance with MIL-STD-130 and the ACV’s IUID Plan (ACV-PLN-04001).

Joint Government and Contractor logistics analysts will determine which components will require UID and serialization. CIs selected for UID will transition, if not already, to Government

CDCA for separate CM. Serialization will be an integral part of the UID.

5.3.1.2 Part Number Change Criteria

When modification of a part, subassembly, or complete article renders it not interchangeable with its superseded configuration, the part number of that item must be changed. When modification of a part, subassembly, or complete article remains interchangeable with the previous configuration, only a dash number suffix of that part number is changed. This practice leaves the original base number and serial number intact. Production of the new configuration will continue to assign serial numbers sequentially to the (unchanged) base numbered part(s) and

UNCLASSIFIED

permit no duplication of serial number assignments. Conversely, when the superseding item cannot be made from the previous version item, a new base number is assigned to the new configuration along with a new series (SN001 and up) of sequential serial numbers. The superseded item serial number record will show disposition of the superseded items.

5.3.2 Documentation

Specifications, drawings and associated technical data, associated parts lists, reports, and plans are assigned identification numbers in accordance with MIL-HDBK-61A and ASME Y14.XX series guidance. Those assigned numbers are sequential as defined in the Contractor’s CMP.

Revisions supersede previous proposals in their entirety.

ACV program specifications, plans, processes, and procedures developed by PM AAA will be assigned identification numbers per PM AAA Document Lifecycle Process (AAA-PRO-01002) and PM AAA Document Identification Procedure (AAA-PRD-01002).

5.3.3 Specifications

Government specifications are developed using PM AAA’s Requirements Development Process

(AAA-PRO-01006). The identifier for the ACV System Performance Specification is ACV-SPE-

02003. This specification is under PM AAA control and any Contractor proposed changes to, or variances from, have to be requested via Class I ECPs or RFVs following the change process in this CMP.

5.3.4 Media Labeling

To better track and uniquely identify each piece of CM controlled media, all media will be labeled with as much information as possible. A label will be affixed to each media item with the following information:

Unique number assigned by CM (Media/Serial Number) for each piece of media

Program, software CI nomenclature

Version number {example – 1.0.3}

Title

Classification; if classified, need “declassify on” statement

Contract Number (if applicable)

CAGE code of originating activity

Program Date {format = DD MMM YYYY}

Distribution Statement

Numbering Scheme if there are multiple units per set Disk x of x {example – Disk 1 of

3, Disk 2 of 3, Disk 3 of 3}

Numbering Scheme if there is more than one copy being delivered; each must be distinct

{example –Unique Number -1, Unique Number -2, etc.}

Barcode (if needed)

UNCLASSIFIED

Generation Date (if needed){format= DD MMM YYYY}

5.4 Equipment Marking and Identification

ACV equipment marking and identification, MRI and free text, shall follow the guidance in the

Government IUID Plan and MIL-STD-130N. MRI marking is preferred for all items marking, but is only mandatory for IUID designated items. MRI (Data Matrix symbol) with Human-readable information, translation or interpretation, shall be applied to items specifically designated for IUID by program managers or acquisition activities. The use of MRI may not be suitable or adequate for all identification marking needs. Free text marking protocol is the standard alternative when MRI is not used.

Marking of ACV equipment for shipment and storage shall be done in accordance with MIL-

STD-129P(4).

UNCLASSIFIED

6.0 Configuration Change Control

Configuration control ensures that proposed changes to a CI baseline are properly documented, accurate configuration identification is maintained, and changes are approved prior to implementation. The control and procedures for processing, evaluating, and the disposition of

Class I ECPs and RFVs for the ACV Program are based on the guidance defined in MIL-HDBK-

61A, PM AAA Configuration Review Board Procedure (AAA-PRD-01010), PM AAA

Configuration Control Board Procedure (AAA-PRD-01011), and this CMP.

The approval process for changes to CI baseline documentation depends upon the CDCA for that baseline documentation. Changes to Government or delegated second tier authority controlled baseline documentation are submitted to the Government or delegated second tier authority for approval. For baseline documentation that the Government does not control, the Contractor is authorized to approve and implement changes without prior Government approval, and may delegate approval authority to Suppliers over specific baselines as defined in their CMP and applicable subcontracts.

This plan identifies those activities that are responsible for reviewing, processing, and approving proposals that change the baseline configuration documentation. Except as specifically noted, use of the term ECP in this plan includes any ECPs submitted for Government approval and the

Contractor’s Major or Critical RFVs submitted for Government approval.

6.1 Change Classification

Proposed Class I engineering changes and Critical or Major Variances will be submitted to the

Government for disposition prior to incorporation. Proposed Class II changes and minor variances will be reviewed by the ACV CRB to ensure conformance to classification guidelines.

The following definitions of engineering changes and variances apply per MIL-HDBK-61A.

6.1.1 Engineering Change Proposal

An ECP is the management tool used to propose a configuration change to a CI and its

Government-baselined performance requirements and configuration documentation. Proposed changes to hardware and software will be submitted for approval via ECPs.

6.1.1.1 Class I ECP Criteria

An ECP proposing a change to approved configuration documentation for which the Government is the CDCA or that has been included in the contract or statement of work by the tasking activity, and:

affects any physical or functional requirement in approved functional or allocated configuration documentation, or

UNCLASSIFIED

affects any approved functional, allocated, or product configuration documentation, and cost, warranties, or contract milestones, or affects approved product configuration documentation and one or more of the following:

o GFE o Safety o Performance o Reliability and maintainability o Interfaces o Compatibility or interoperability o Logistics support o Delivered technical manuals for which changes are not funded o Will require retrofit of delivered units o Preset adjustments or schedules affecting operating limits or performance to the extent that a new identification number is required o Interchangeability, substitutability, or replaceability of any item down to non-repairable subassemblies o Sources on a source control drawing o Skills, manning, training, biomedical factors, or human engineering design

Class I ECPs may be solicited or unsolicited. Generally, unsolicited Class I ECPs are discouraged. However, a preliminary ECP may be submitted to allow evaluation of the desirability of expending resources to document fully a proposed change. Changes that impact the following areas are instances where unsolicited ECPs may be justified:

Safety

Compatibility

Correction of Defects

Survivability

Security

Product improvement(s) that may significantly reduce life cycle costs, including Value

Engineering Change Proposals consistent with the DFAR Value Engineering clause of the applicable contract

Technology improvements

6.1.2 Class II ECP Criteria

A Class II ECP is an engineering change or variance that does not affect any of the criteria provided above for a Class I change. For example:

Drafting Error (i.e. mismatch between parts list and drawing; missing or wrong quantity;

incorrect or missing CAGE code; or military part number)

UNCLASSIFIED

Engineering Enhancement (i.e. dimensions that do not adversely affect structure part integrity; improvement of the product durability; material change that meets or exceeds technical requirements and specifications)

Manufacturing Information (i.e. hole mismatch to next higher assembly, hole location incorrect, wrong quantities of hole callout, or incorrect hole size)

CI Change that is Backwards Compatible (i.e. does not require a new CI part number; no impact to the PBL; does not change the fit or function of higher assemblies)

Military or Commercial Off-the-Shelf Part Change (i.e. backwards compatible to previous product; replacement part meets or exceeds technical requirements and specifications)

6.1.3 Request for Variance

A RFV is a specific written authorization to depart temporarily from one or more requirements of an item's approved configuration documentation for a specific number of units. A variance differs from an engineering change in that an approved engineering change requires a corresponding revision of the item's current approved configuration documentation, whereas a variance does not. MIL-HDBK-61A provides creators of RFVs the guidance on the preparation of variances. RFVs were once called Requests for Deviation.

6.1.3.1 Critical Variance Criteria

A variance is classified as Critical when:

The variance consists of a departure involving safety, or

When the variances consist of a departure from a requirement classified as a critical characteristic. A critical characteristic is one that analysis indicates is likely, if defective or not met, to create or increase a hazard to human safety or to result in failure of a weapon system or major system to perform a required mission.

6.1.3.2 Major Variance Criteria

A variance is classified as Major when the variance consists of a departure involving:

Performance

Interchangeability, reliability, survivability, maintainability, or durability of the item or its repair parts

Health

Effective use or operation

Weight and size

Appearance (when a factor)

When the variances consist of a departure from a requirement classified as a major characteristic. A major characteristic is one that analysis indicates is not critical but, if

UNCLASSIFIED

defective or not met, is likely to result in failure of an end item to perform a required mission

6.1.3.3 Minor Variance Criteria

A variance is classified as Minor when:

The variance consists of a departure which does not involve any of the factors listed as

Critical or Major

When the variances consist of a departure from a requirement classified as a minor characteristic. A minor characteristic is one that analysis indicates is significant to product quality but, if defective or not met, is not likely to impair the mission performance of the item

6.2 Forms

The ACV CM will use the following forms:

ECP – (DD Form 1692, 2013) Used to document a proposed change

Notice of Revision (NOR) – (DD Form 1695) Used to document a change to configuration documentation (i.e. specifications, drawings). The Contractor prepares and attaches a NOR with each proposed ECP that affects a configuration documentation.

After ECP approval, the Contractor notifies the Government that the technical data has been updated..

RFV – (DD Form 1694, 2013) Used to document the need to deviate from or waive a requirement.

Modification Installation (MI) – Also known as Retrofit Instruction. Upon CCB approval of a Class I ECP, implementation of hardware or software changes to fielded systems is recorded in a MI, which is tracked to closure. The MI provides specific, step-by-step instructions about the installation of the replacement parts to be installed in delivered units to bring their configuration up to that approved by an ECP. The Contractor notifies the accomplishment of retrofit changes (Mod-kit implementation) to fielded equipment.

The notification is provided to the Government to maintain information about the configuration of unit(s) in the operational inventory (in-service/as-maintained configurations), along with equipment modification history.

6.3 Change Control Process

The configuration change and variance process involves engineering documentation preparation, submittal, review, approval, contracts modification, installation, and update to the baseline documentation.

Proposed configuration changes and requests for variance will be considered only if the change/variance offers a clear benefit to the Government. Engineering changes beneficial to the

UNCLASSIFIED

Government are defined as those considered to be mission critical, mission or design enhancements, deficiency corrections (including those related to safety), performance improvements, cost reduction initiatives, or changes that reduce life cycle costs of the vehicle or other CIs.

Figure 6.3-1 illustrates the ACV Configuration and Change Management Process (CCMP) used for processing changes and variances. Urgent and emergency changes will be fast-tracked.

Figure 6.3-1: Configuration and Change Management Process

6.3.1 Process Description

The CCMP begins when the Contractor or the Government identifies a change or variance requiring the processing of an ECP or RFV respectively. The Contractor prepares the ECP/RFV form and supporting documentation (NORs, drawing, specification, etc.) that will make up the

ECP/RFV package and submits it to the ACV CM Manager. The ECP/RFV package is reviewed and a decision is made on whether to promote the ECP/RFV to the CRB or return it back to the originator for revision. If the ECP/RFV is promoted to the CRB, the APdM-E (CRB Chair) convenes a CRB in accordance with procedure AAA-PRD-01010. The CRB reviews the

UNCLASSIFIED

ECP/RFV package and make recommendations to the CRB Chair on whether to promote the

ECP/RFV to the ACV CCB or return it to the Originator for revision. If the ECP/RFV is promoted to the CCB, the PdM for ACV (ACV CCB Chair) conducts the CCB in accordance with procedure AAA-PRD-01011. The ECP/RFV package is reviewed and the ACV CCB voting members vote on whether to approve or disapprove the ECP/RFV or return it to the

Originator for revision. In the case of ECPs, the CCB might also decide to defer it. After the

ECP is approved, it is monitored as appropriate for implementation. Approved ECPs affecting vehicles in production will be implemented in accordance with the Contractor’s Manufacturing

Plan. Approved RFVs will be monitored and remain in open status until the variance is resolved by a modification. The CCMP ends at implementation after which point CSA activities take place.

6.3.2 ECP Processing

An ECP is developed and processed through the ACV CCB. NORs will be submitted as part of the ECPs to document updates to configuration documentation. ECP approval provides direction to develop and implement the approved change. The ECP will be kept in an open status until all associated documentation is approved. This includes drawing, specification, ILS, and any other documentation changes identified in the ECP. Upon approval of all drawing, specification, ILS, and other documentation changes, the ACV CCB will close the ECP.

6.3.2.1 Class I ECP Processing

All Class I ECPs submitted for Government approval will be reviewed and approved by the

ACV CCB prior to implementation. Class I changes to documentation where the Government is the CDCA, but does not maintain physical control, will be dispositioned by Government CDCA within the Contractor’s change process.

The ACV CCB will process ECPs based on their priority classification:

Emergency/Urgent Priority

ECPs assigned an emergency or urgent priority will be processed within five (5) working days. Depending upon the urgency, this may be accelerated as required.

Routine Priority

A routine priority shall be assigned to proposed ECP when emergency or urgent priority is not applicable. Routine ECPs shall be processed within ten (10) working days.

6.3.2.2 Class II ECP Processing

All Class II ECPs are processed in accordance with the Contractor’s CMP. The CM Manager and ACV1.1 APdM-E will review Class II ECPs to ensure conformance to classification.

UNCLASSIFIED

6.3.3 Request for Variance Processing

RFVs submitted for Government approval should only pertain to items submitted for

Government acceptance and delivery under the appropriate contract. The Contractor will submit all Critical and Major RFVs for Government review via the Procurement Contracting Officer for processing through the ACV CCB.

6.3.4 Vehicle Software Updates

After the Government assumes CCA of the ACV, changes to vehicle software will be submitted to the Government in accordance with the change process described in Government CM Plan.

The Contractor will conduct regression testing following any software modifications to ensure that no new defects have been introduced and no functional degradation has occurred as a result.

The Contractor will generate a software Build definition to capture what functionality or fixes will go into a particular software release. Software Build definitions will be approved through the CCB. The Contractor will resolve all priority 1 and priority 2 software defects prior to software release. The Government will prioritize and determine which priority 3 or higher software defects the Contractor will fix and include in the software Build definition for a particular software release depending on severity, schedule, and cost. The Contractor will use the classifications defined in IEEE/EIA 12207.2 Software Life Cycle Process-Implementation

Considerations Annex J to classify each defect in software products.

A Software Version Description document detailing software configuration is required for each software version release. An updated Software User’s Manual is required for any major software version release.

6.3.5 Test Incident Report and Change Request Processing

Test Incident Reports (TIRs) and Change Requests (CRs) are processed by following the

Problem Reporting and Corrective Action (PRCA) Process (AAA-PR0-01009). Problems found during test events are documented in TIRs, which are validated, prioritized, and if required converted into ECPs. CRs are used to document software problems/defects, propose enhancements to computer programs, update software documentation, and make operating environment changes or Information Assurance changes. Software problems/defects are classified using the criteria defined in IEEE/EIA 12207.2 Software Life Cycle Process-

Implementation Considerations Annex J. The Failure Prevention Review Board, within the

PRCA process, is responsible for determining which TIRs/CRs will become ECPs and for reviewing all draft ECPs/RFVs before they are processed through the CCMP.

6.4 ACV Configuration Control Boards

The ACV CCMP includes two configuration boards, the CRB and the CCB. Final approval/disapproval and effectivity of the ECP/RFV resides with the CCB.

UNCLASSIFIED

6.4.1 Configuration Review Board

The purpose of the CRB is to assess proposed changes before they are presented for consideration at the ACV CCB for decision. CRBs convene in order for the subject matter experts to review/analyze ECPs or RFVs for documentation completeness, accuracy, and administrative correctness. The membership of the CRB provides the assessment of all proposed configuration changes and variances that includes the impacts to existing configuration baselines and assigns staffing for review and compilation of the documentation to be presented to the

CCB.

The CRB comprises appropriate subject matter experts including but not limited to Requirements

Management, Engineering, Logistics, Test & Evaluation, Reliability, Safety, Human Factors, and

Contractor as necessary. The Configuration Manager administers the execution of the CRB with the APdM-E or designee as the Chairperson and final authority to make recommendation to the

CCB to approve or disapprove the proposed change. Details for the conduct of the CRB and the duties and responsibilities of its members are outlined in PM AAA Configuration Review Board

Procedure (AAA-PRD-01010).

6.4.2 Configuration Control Board

The ACV CCB is the sole authority for approving or disapproving ECPs or RFVs affecting the

ACV configuration for which the Government is the CCA and CDCA. The CCB convenes to review the ECP or RFV and the recommendation provided by the CRB to make the final determination to approve or disapprove the proposed change. As the ACV program transitions to development then production and fielding, PM AAA will assume greater control over ABL and PBL elements. PM AAA controls the FBL throughout the lifecycle.

CCBs are conducted in accordance with PM AAA Configuration Control Board Procedure

(AAA-PRD-01011).

6.4.3 ACV CCB Responsibilities

The duties and responsibilities of CCB members are governed by PM AAA CCB Process document. The major responsibilities of the ACV CCB members are described below.

6.4.3.1 Responsibilities of ACV CM Manager

Responsibilities of the ACV CM Manager include:

Coordinate and facilitate the ACV CCB meetings

Prepare, review, and distribute documentation for ACV CCB meetings

Provide CM direction and training to CCB members

6.4.3.2 Responsibilities of the ACV CCB Chairperson

The Chairperson is the Approval Authority of the ACV CCB with the following responsibilities:

UNCLASSIFIED

Lead the ACV CCB

Review engineering changes to ensure sound engineering design decisions have been made and can be implemented readily, easily, and affordably

Authorize change presented to…