Use of Hardware Configuration Items by Aerospace & Defense Industry Contractors
What are hardware configuration items and how are they used in configuration management software by aerospace & defense industry contractors?
Part 1 of 2
In this series of CMsights posts from CMstat on configuration management best practices we will describe what are hardware configuration items (“CI” or “HWCI”) and where they are used. Next, we will examine how are CIs best employed by A&D contractors in configuration management software used at the program, project and product levels. This includes the role of industry standards such as DOD-STD-480A, MIL-HDBK-61A, and SAE EIA-649. In our final part we will share examples of how CIs help with the as-built, as-tested, as-delivered, as-deployed, as-maintained, and as-disposed configuration of fielded products, complete systems, or even digital twins.
History of Configuration Items
There has been much discussion regarding configuration management and the use of configuration items in on-line forums and other on-line articles recently. Googling the words Configuration Items or the acronym CI will result in approximately 26,300,000 results. Very few of these results pertain to hardware configuration items yet most of the products manufactured for the Aerospace and Defense industry marketplace are hardware or consist of largely hardware.
Configuration Management as a management tool and philosophy first appeared in U.S. Government standards during the 1960’s nuclear weapons proliferation and posturing between the USA and the former USSR, often referred to as the cold war, and our first attempt to explore a nearby celestial object as space fairing nations raced to be first to set foot on the moon. Since that time the practice of CM has evolved into the following five basic elements that form the foundational pillars of modern-day CM management software.
Configuration Management Planning
Configuration Management Identification
Configuration Change Management
Configuration Status Accounting
Configuration Verification and Audit
The thing we call a Configuration Item (CI) and assigning a Configuration Item Identifier (CII) are part of Configuration Management Identification. The CII when combined with the item’s part number, serial number/lot number, and the Commercial and Government Entity (CAGE) code, definitively identifies a company’s product from any other company’s product.
When you think about it you can easily have multiple companies selling products that have the same part number. Possibly these items could have the same serial number/lot number. When you add in the CII and the CAGE code you have a four-level authentication tying what you are purchasing to a specific pedigree and manufacturer. CIs and the CIIs started out being unique to government procurements and have been embraced by many non-government industries as well over the last several decades. While some industries do not lend themselves to adoption of CIs we expect this trend of CI usage to continue in the Aerospace and Defense (A&D) industries.
DOD-STD-480A on 12 April 1978 gave the following definition in section 110.18:
“Configuration item (CI). An aggregation of hardware/software, or any of its discrete portions, which satisfies an end use function and is designated by the Government for configuration management. CIs may vary widely in complexity, size and type, from an aircraft, electronic or ship system to a test meter or round of ammunition. During development and initial production, CIs are only those specification items that are referenced directly in a contract (or an equivalent in-house agreement). During the operation and maintenance period, any reparable item designated for separate procurement is a configuration item. (DOD Directive 5010.19)”
Configuration management principles that originated with the U.S. Government are now embodied in SAE EIA-649, National Consensus Standard for Configuration Management at https://www.sae.org/standards/content/eia649b/.
Role of Configuration Items
There are several differentiators that set a CI apart from any other part or assembly being made. A CI requires that a specification be created stating what the requirements for the item being developed are. The specification does not define how the item is going to meet these requirements. It does define how the requirements are to be verified. There are four accepted verification methods: Inspection, Demonstration, Test and Analysis. Specification requirements form the Functional Baseline. Specification requirements for complex items are allocated to lower level systems and subsystems. This is known as the Allocated Baseline. When the product is accepted for use it is known as the Product Baseline.
These baselines often tie to formal reviews attended by the customer and perhaps the end user. In a government environment these reviews have specific goals. The figure below identifies the reviews as well as the audits by program phase as defined by AcqNotes at http://acqnotes.com/acqnote/tasks/functional-configuration-audit-2.
Three of these are of particular importance during product development. The System Requirements Review (SRR) assures a systems level overview of the requirements. Preliminary Design Review (PDR) assures the customer that the requirement allocations have been well thought out and the design solution has a high probability of success. The Critical Design Review (CDR) evaluates the design maturity since PDR and in some cases authorizes the contractor to start releasing engineering for production or in other cases to start fabrication. Sometime after first unit production two audits take place. The Physical Configuration Audit (PCA) assures that the item was built to the released engineering. The Functional Configuration Audit (FCA) assures that the item meets all the requirements in the specification. Collectively they are known as customer oversight.
Traditionally the trail of engineering artifacts through the documentation leading to assuring the verification methods cited in the specification was maintained in hard copy form. This was known as the paper trail. The advent of the electronic computer has allowed the paper documentation to be digitized and the paper trail has become a digital thread linking data artifacts to requirements. As example test procedures are linked to the article being tested, As-Run test procedures are linked to the test procedure, and test reports are linked to the test procedure and the article being tested. If multiple articles are being tested the As-Run test procedure and test report for each item tested is linked to a specific serial or lot number.
As electronic tools continue to evolve identifying the digital thread becomes easier. A virtual or digital twin of the item being produced can be used to run test scenarios, analysis, assembly sequence optimization and factory layout to enhance producibility and production. Digital twins are also useful in identification of artifacts required to be added to the digital thread required for a more complete set of validation and verification resources. Digital twins are also particularly useful in modeling as fielded usage of the item being produced often highlighting components and sub-assemblies subjected to wear and fatigue that need to be considered as additional CIs for operation and maintenance activities.
Use of Configuration Items in A&D
While it is certainly possible to have a very robust configuration management process without the use of Cis, Configuration Management Identification still requires that something “similar to” a CI be in place. Perhaps the only thing holding some A&D contractors from defining something as a CI is semantics. If their identifiers do everything a CI is used for then it is probably a CI Identifier.
It is often believed that a CI is only used between the customer or end user and the top-level contractor. This is far from the truth. Most A&D contracts require that configuration management requirements levied on the 1st tier supplier be flowed down to 2nd tier suppliers. 2nd tier suppliers in turn flow them down to 3rd tier suppliers and so forth. The fact that 1st tier supplier is not aware that a 3rd or 4th tier supplier is using CIs does not negate their existence. MIL-HDBK-61A explains in Figure 3-2 just this tiering of CI designations.
Once a product is finalized for production it may be determined that certain element of the design should also be identified as CIs. These may be items that need to be stocked in the customer or end user inventory for the Operations and Maintenance phase. For a ground vehicle they might include such things as the motor, transmission, major suspension system elements, seats, doors, etc.
Coming Next
In Part 2 of this series of CMsights posts on the use of configuration items we will explore why CIs are so important when maintaining the history of configurations during each stage of the “As-X” lifecycle of products, equipment, or complete systems. This includes not just the as-designed or as-manufactured stages but also as-tested, as-certified, as-shipped, as-installed, as-provisioned, as-maintained and as-retired. While basic configuration management capabilities are often found in engineering-centric PDM software, the real test of CM-focused software, like PDMPlus CM, is how well they accommodate the needs of these downstream lifecycle As-X users.
Receive CMsights
Subscribe to CMsights News for the latest updates from CMstat on Configuration Management, Data Management, EPOCH CM, and EPOCH DM.
Request a Demo
See how EPOCH CM and EPOCH DM support industry standards and best practices in Configuration Management and Data Management.
