Industry Acronyms

Configuration Management

Q: What is the difference between configuration management and version control?

Version control is one mechanism inside configuration management, not a synonym for it. A version control system (Git, SVN, or a PDM vault) tracks revisions of individual files such as schematics, Gerbers, HDL, and test scripts. Configuration management is the broader discipline that defines which specific set of those revisions, together with the bill of materials, firmware image, calibration data, and approved deviations, constitutes a released baseline of the product. CM adds the four functions that version control alone does not provide: configuration identification (assigning part numbers and baselines), configuration control (the change control board process), configuration status accounting (knowing the as-built state of every serial number), and configuration audits (FCA and PCA). On an RF module you might have hundreds of versioned files, but the CM baseline says revision C of the assembly equals layout rev 4, firmware 2.1.7, and BOM rev B.

Q: What standards govern configuration management for RF and defense hardware?

The civilian and commercial baseline standard is ANSI/EIA-649 (National Consensus Standard for Configuration Management), which defines the five core CM functions. For defense work, MIL-STD-973 was the historical standard and is now largely superseded by EIA-649B with the MIL-HDBK-61 guidance handbook and contract-specific data item descriptions. ISO 10007 provides quality-management-aligned CM guidance and is referenced by AS9100 aerospace quality systems. For software and firmware, IEEE 828 (Standard for Configuration Management in Systems and Software Engineering) applies. A typical RF contractor delivering to a defense prime must satisfy EIA-649B, AS9100/ISO 10007, and the specific CDRLs flowed down in the statement of work, with formal functional and physical configuration audits before first article acceptance.

Q: How does a change control board decide whether an RF design change needs a new part number?

The change control board (CCB) classifies a proposed change as Class I or Class II. A Class I change affects form, fit, function, interface, or any contractually controlled parameter, for example shifting a filter passband, changing connector type from SMA to 2.92 mm, altering gain by more than the spec tolerance, or modifying an ICD. Class I changes require customer approval and almost always force a new part number or at least a major dash number. A Class II change is documentation or minor process correction that does not affect interchangeability, such as a typo fix or an equivalent-component substitution from an approved vendor list; it can be handled internally with only a revision letter bump. The deciding test is interchangeability: if a unit built to the new configuration cannot be freely swapped for an old one without affecting system performance, it gets a new identifier.

/kuhn-fig-yuh-RAY-shun MAN-ij-muhnt/ (CM)

A formal engineering discipline that identifies, controls, audits, and reports the functional and physical configuration of an RF product so that hardware, firmware, and documentation never drift out of step. Governed by standards such as ANSI/EIA-649 and the legacy MIL-STD-973, it locks each released design to an approved baseline and routes every proposed change through a change control board. The discipline binds together revision control of design files and full traceability from a serial number back to the exact layout, firmware image, and bill of materials used to build it. In millimeter-wave production, where a 0.1 mm dielectric change can shift a passband by hundreds of MHz, CM is what makes unit number 500 measure identically to the first article.

Category: Industry Acronyms

Governing Standards: EIA-649B, MIL-STD-973, ISO 10007

Core Functions: Identification, Control, Status Accounting, Audit

How CM Locks an RF Build to Its Baseline

Configuration management exists because RF and millimeter-wave hardware is unforgiving of silent change. A substrate vendor swapping a laminate from a dielectric constant of 3.48 to 3.55, a connector buyer accepting an SMA part with a slightly longer launch pin, or a firmware engineer pushing an untracked gain-table update can each move a delivered unit outside its specification while every drawing still appears correct. CM defends against that drift by formally declaring a configuration: a named, frozen set of part numbers, document revisions, firmware images, and approved deviations that together define exactly what a given build is. Once a functional baseline (the requirements), an allocated baseline (the design that meets them), and a product baseline (the as-built article) are established, no element changes without passing through a documented process.

The discipline rests on five recognized functions. Configuration identification assigns the part numbers, dash numbers, and revision letters that name each item and its baseline. Configuration control runs proposed changes through a change control board (CCB) that classifies each one and approves or rejects it. Configuration status accounting records the as-designed and as-built state of every serial number, so a field failure on unit 312 can be traced to the precise firmware and BOM it shipped with. Configuration audits close the loop: a functional configuration audit (FCA) verifies that the article meets its requirements through test, and a physical configuration audit (PCA) verifies that the as-built hardware matches the released drawings. A fifth function, management and planning, ties these together in a CM plan delivered to the customer.

For a St. Petersburg millimeter-wave shop, the payoff is repeatability under audit. A defense prime ordering a 71 to 76 GHz converter expects every unit across a multi-year buy to be interchangeable, and CM is the contractual mechanism that guarantees it. The change control board is where engineering judgment meets that contract: a proposed layout tweak that shifts the LO leakage by 2 dBc may be a harmless Class II correction, or it may be a Class I change that requires customer sign-off and a new part number, depending entirely on whether interchangeability is preserved.

Classifying a Change: Class I vs Class II

The single most consequential CM decision is change classification. A Class I change touches form, fit, function, interface, weight, reliability, safety, or any contractually controlled parameter, and it requires customer approval before incorporation. A Class II change is administrative or a like-for-like correction that does not affect interchangeability and can be approved internally. The interchangeability test is decisive: if a unit built to the new configuration cannot replace an older unit without affecting system-level performance, the change is Class I and earns a new identifier.

Governing Relationships and Identifiers

Baseline composition (released configuration):
Baseline_rev = { Layout_rev ∪ Firmware_ver ∪ BOM_rev ∪ Approved Deviations }

Interchangeability rule (drives part-number change):
New P/N required ↔ Δ(Form, Fit, Function, Interface) ≠ 0

Status-accounting completeness target:
As-built coverage = (Serials with full config record / Total serials shipped) × 100% ≈ 100%

Audit pass criteria:
FCA: measured performance ⊇ spec requirements · PCA: as-built ≡ released drawings

Example: assembly rev C ≡ layout rev 4 ∪ firmware 2.1.7 ∪ BOM rev B. A connector change from SMA to 2.92 mm alters Interface, so ΔInterface ≠ 0 → Class I → new dash number.

CM Function Reference

CM Function	Purpose	Key Artifact	Owner	RF Example
Identification	Name items and baselines	Part / drawing numbers, baselines	CM engineer	P/N for a 18-26.5 GHz down-converter, rev letter
Change Control	Approve or reject changes	ECP, CCB minutes	Change Control Board	Class I LO-leakage tweak needs customer sign-off
Status Accounting	Track as-built state	As-built record per serial	CM / production	Unit 312 shipped with FW 2.1.7, BOM rev B
Functional Audit (FCA)	Verify it meets requirements	Test data package	Quality / test	Measured NF 3.2 dB ≤ 3.5 dB spec
Physical Audit (PCA)	Verify build matches drawings	PCA report	Quality	As-built laminate matches called-out Rogers part

Common Questions

Frequently Asked Questions

What is the difference between configuration management and version control?

Version control (Git, SVN, a PDM vault) tracks revisions of individual files such as schematics, Gerbers, HDL, and test scripts; it is one mechanism inside CM, not a synonym. Configuration management is the broader discipline that declares which set of those revisions, plus the BOM, firmware image, and approved deviations, forms a released baseline, and it adds identification, change control, status accounting, and audits. A CM baseline might state that assembly rev C ≡ layout rev 4, firmware 2.1.7, BOM rev B.

What standards govern configuration management for RF and defense hardware?

ANSI/EIA-649B is the commercial consensus standard defining the core CM functions; MIL-STD-973 is the legacy defense standard now largely superseded by EIA-649B with the MIL-HDBK-61 handbook. ISO 10007 supplies quality-aligned CM guidance referenced by AS9100, and IEEE 828 covers software and firmware CM. An RF contractor to a defense prime typically must satisfy EIA-649B, AS9100/ISO 10007, and contract-specific CDRLs, with formal FCA and PCA before first-article acceptance.

How does a change control board decide whether an RF design change needs a new part number?

The CCB classifies the change. A Class I change affects form, fit, function, or interface, for example shifting a filter passband, changing a connector from SMA to 2.92 mm, or moving gain beyond tolerance; it needs customer approval and a new part or dash number. A Class II change is a documentation or like-for-like correction that does not affect interchangeability and is handled internally with a revision-letter bump. The deciding test is whether a unit built to the new configuration can still be freely swapped for an old one.

Related Terms

← Configuration Item Configured Grant →