Functional Configuration Audit: FCA and PCA Evidence Guide

Hardware engineering programs treat configuration audits like forensic investigations. Three weeks before a customer review board or defense agency auditor arrives, engineering leads freeze active development. Systems engineers dig through shared network drives for missing vibration test plots, while quality engineers cross-examine manufacturing technicians about why a shop floor traveler cites drawing Revision B when Revision D was released two months ago.

It doesn't have to be an emergency reconstruction project. Treat configuration management as a continuous discipline and audit preparation takes hours, not weeks. This guide explains how to prepare defensible evidence for a functional configuration audit (FCA) and a physical configuration audit (PCA), keep your verification links current across active engineering changes, and pass reviews without frantic administrative cleanups.

Step 1: Understand what FCA and PCA each check

A functional configuration audit and a physical configuration audit examine two different halves of engineering integrity. The FCA checks functional performance: did the system, subsystem, or component meet the operational requirements in its contracted technical baseline? The PCA checks physical identity: does the hardware built on the manufacturing floor match the released engineering drawings, bill of materials, and assembly instructions?

Configuration management references such as MIL-HDBK-61B and SAE EIA-649C guide these practices across government and commercial environments. The FCA validates that your verification results satisfy the functional and allocated baselines. Auditors review test data, analytical models, demonstration logs, and inspection sheets against specification paragraphs. If requirement 3.2.1.4 states that a flight actuator must operate at minus 40 degrees Celsius, the FCA verifies that a qualified test record proves it.

The PCA examines the product baseline. Inspectors take a specific production-representative unit and compare its physical markings, serial numbers, part numbers, wire harness routings, and torqued fasteners against the engineering drawings. If the drawing specifies a cadmium-plated fastener with an anaerobic threadlocker, the PCA team checks that the manufacturing traveler records the exact lot number and application verification for that threadlocker.

FCA proves the design works on paper and in the test cell. PCA proves your manufacturing line builds what engineering designed. Pass one without the other and the program is exposed to catastrophic quality escapes.

Step 2: Define the configuration items and the baseline you are auditing against

You can't audit an amorphous hardware assembly. You have to formally designate Configuration Items (CIs). A CI is an aggregation of hardware or software that satisfies an end-use function and is designated for separate configuration management.

Start by locking the specific baseline under review. An audit run against a moving target fails immediately. In aerospace and defense programs, configuration management recognizes three primary baselines:

1. Functional Baseline: Established at the System Requirements Review (SRR), capturing top-level system requirements.

2. Allocated Baseline: Established at the Preliminary Design Review (PDR) and confirmed at the Critical Design Review (CDR), allocating performance from the system down to individual subsystems and CIs.

3. Product Baseline: Established upon successful completion of the FCA and PCA, capturing the complete technical data package required for manufacturing.

Formal configuration baseline discipline means publishing a frozen baseline document index before the audit starts. The index names every applicable specification revision, interface control document, assembly drawing, and bill of materials revision. If your design team releases engineering change orders (ECOs) while the audit team reviews evidence, auditors will issue discrepancy findings for baseline instability. Lock the revisions, issue an audit freeze, and reference that snapshot across all review checklists.

Step 3: Build the FCA evidence set: requirements traced to verification results

The FCA evidence set must show a clean, unbroken line from parent requirements to qualification artifacts. Auditors won't accept informal assertions or verbal confirmations from senior engineers. They want objective quality evidence.

Your primary deliverable is an active verification cross reference matrix (VCRM). The VCRM maps every functional requirement to its verification method (test, analysis, inspection, or demonstration), the corresponding verification procedure, and the approved verification report. For each entry, assemble the complete evidence package:

• The approved test procedure, including revision level and test setup calibration records.

• Raw and reduced test data, with calibration certificates for all instrumentation used during the run.

• Test deviation sheets that note any test aborts, fixture anomalies, or environmental chambers drifting out of tolerance.

• Formal sign-offs from the test director, systems engineering lead, and customer quality representative.

In legacy environments, teams assemble these packages by manually pulling files out of IBM DOORS or static spreadsheets and searching shared drives for test reports. Tandem removes that manual hunting by linking system architecture nodes and requirement tables directly to CAD revisions and validation evidence. With requirements, CAD changes, and verification data connected in one context layer, systems engineers can generate complete FCA evidence packages on demand instead of spending weeks on document retrieval.

Step 4: Build the PCA evidence set: as-built configuration against released design documentation

FCA evidence lives largely in test reports and analytical models. PCA evidence lives on the manufacturing floor and in the inspection records of a designated serial-numbered unit. You need an as-built versus as-designed reconciliation package for that physical unit.

Assemble the following documents for the PCA package:

• As-Designed Bill of Materials (BOM): The engineering BOM released from your CAD and PLM environment at the locked product baseline revision.

• As-Built Bill of Materials: The manufacturing record listing the actual part numbers, lot numbers, date codes, and serial numbers installed in the physical test article.

• Manufacturing Routing Sheets and Travelers: Stamped, dated traveler operations proving every machining step, surface treatment, torque check, and wiring crimp inspection happened in sequence.

• First Article Inspection (FAI) Reports: Characteristic accountability and verification records conforming to AS9102 or applicable contract and customer requirements.

• Approved Engineering Variances: Every deviation and waiver request tied to the physical unit, with customer disposition and signed engineering rationale.

During the physical inspection, the audit team disassembles or inspects the hardware alongside the top-level drawing. They check physical part markings, label placements, cable clamp spacing, and fastener grip lengths. Say a technician substituted a 300-series stainless washer because the specified part was out of stock, and the substitution has no approved engineering deviation. The audit team will halt the review. Reconcile every line item on the as-built traveler against your drawing notes before you present the hardware.

Step 5: Keep evidence current through design changes

Configuration audits fail most often when active design changes sever the links between requirements, drawings, and verification reports. A mechanical engineer modifies a structural bracket in CAD to fix a manufacturing clearance issue. The drawing revision bumps from C to D. The change is approved, but nobody notes that the original vibration qualification test ran on Revision B.

When auditors catch this during the FCA, the program faces painful delays. The bracket needs re-qualification testing or an engineering delta-qualification analysis. Design changes must trigger immediate updates to the verification record.

Build an explicit verification impact evaluation into your engineering change workflow. For every proposed CAD revision, require the author to answer three questions:

1. Does this geometry change affect any allocated requirement or interface boundary?

2. Does this change invalidate any completed qualification test, analytical model, or inspection record?

3. Which physical serial numbers must be retrofitted or re-inspected to maintain configuration conformity?

Tandem tracks CAD changes across SolidWorks, Onshape, Fusion, and NX, and evaluates mechanical edits against linked requirements and validation records. When geometry shifts, the engineering team immediately sees which downstream verification evidence is affected. Stale test records never make it into the audit binder.

Step 6: Run a pre-audit readiness check and close discrepancies

Never walk into a formal FCA or PCA without a dry run. Schedule an internal pre-audit thirty days before the formal customer review. Assign internal quality and systems engineers who are independent of the project team to play hostile auditors.

Have them pull ten random requirements from the system specification and demand immediate proof of verification, down to the raw data files. At the same time, pick five subassemblies on the shop floor traveler and demand the material certs, fastener torque logs, and drawing release notices.

Log all findings in an Audit Discrepancy Matrix, categorized by severity:

• Priority 1 (Showstopper): A requirement lacks objective verification evidence, or an unapproved part substitution exists on the physical article. These items block baseline approval.

• Priority 2 (Administrative Defect): A test report is missing a secondary approval signature, or a drawing title block contains a typo. These items don't invalidate the design but need correction.

• Priority 3 (Observation): Minor procedural suggestions that improve traceability without affecting baseline compliance.

Stand up a rapid-response team to close all Priority 1 and Priority 2 discrepancies before the external audit kickoff. If an engineering analysis has to be rerun to cover a modified tolerance, finish it, sign it, and index it into the audit package before the customer arrives.

What to do next: troubleshooting common audit gaps

When configuration audits stall, the root cause is almost always one of three gaps. Address them early.

First, unclosed qualification test anomalies. Say a qualification unit had an intermittent telemetry drop during thermal-vacuum testing. The test finished, and the engineers logged the anomaly as an instrumentation glitch without formal root-cause closure. Customer auditors will seize on that open event. Run a formal Failure Review Board (FRB), document the corrective action, and append the signed resolution report to the verification package.

Second, drawing redlines lingering on the manufacturing floor. Engineering changes discussed in Slack or redlined on paper drawings that never reached the formal change system are direct PCA failure points. Audit your assembly floor travelers against released drawings in your PLM or PDM system. Any discrepancy between the floor traveler and the released revision must be reconciled through a formal change notice or an approved engineering waiver.

Third, missing traceability for commercial off-the-shelf (COTS) components. Teams verify custom mechanical components meticulously, then assume catalog fasteners, power supplies, and connectors comply automatically. Auditors expect Certificates of Conformance (CoCs), manufacturer lot numbers, and environmental compliance documentation for COTS hardware. Check your incoming inspection records and attach supplier CoCs to the PCA evidence set for every critical COTS component.

Conclusion

Configuration audits should confirm your daily engineering discipline. They shouldn't test your ability to reconstruct records under pressure. When your team keeps clear connections between customer requirements, mechanical design changes, and validation artifacts, passing an FCA and PCA is a routine milestone, not an organizational crisis.

Tandem gives hardware teams a unified context layer that connects design intent, requirements, CAD changes, and validation evidence across tools like SolidWorks, Onshape, Fusion, and NX. Instead of spending weeks hunting down files, your team keeps audit-ready traceability through every engineering iteration. Explore how Tandem helps engineering teams manage baselines and prepare for configuration audits.