Configuration Management and Standards

The Discipline That Keeps the Thread Honest

Configuration management is the discipline of knowing what you have, how it got that way, and what happens if you change it. Without CM, PLM is a warehouse of artifacts with no guarantee that what is stored reflects what is built, tested, or fielded. Without CM, the digital thread may exist on paper but cannot be trusted in practice.

CM is not bureaucracy. It is the engineering discipline that prevents the following scenarios — all of which occur routinely in organizations without rigorous CM:

• A test is run against a configuration that does not match the released design. The test passes. The product fails in the field because the as-tested and as-built configurations diverged.
• A change is implemented in manufacturing but never reflected in the engineering data. The next time an engineer analyzes the product, they analyze a configuration that no longer exists.
• Two fielded units with the same part number have different internal configurations because modifications were applied inconsistently. A service bulletin written for one fails on the other.

Every one of these is a thread break — not because the data connections were never established, but because the data the thread connects is no longer trustworthy.

The Four Functions of CM

CM is defined by four functions, formalized in standards like EIA-649 and practiced (to varying degrees) in every engineering organization that builds physical or complex software systems.

Configuration Identification. Establishing and documenting the configuration items that make up a system, including their naming, numbering, and baseline definitions. This sounds like paperwork. It is actually the foundation of everything else. If you cannot uniquely identify every artifact — with a part number, a revision, and a serial or lot number — you cannot track it, control it, or audit it. Identification answers: "What do we have?"

Configuration Control. The process of evaluating, approving, and implementing changes to baselined configuration items. A baseline is a snapshot of an approved configuration — the set of artifacts, at specific revisions, that have been reviewed and released. Change control ensures that no modification to a baseline occurs without evaluation of its impact, approval by the appropriate authority, and implementation tracking. Control answers: "What changed, and was it approved?"

Configuration Status Accounting. Recording and reporting the status of configuration items and change actions. What revision is each item at? What changes are pending? What changes have been implemented? Where? Status accounting is the thread's audit log — the running record that lets you reconstruct the history of any artifact. Accounting answers: "What is the current state, and how did it get there?"

Configuration Audit. Verifying that the actual product matches its documentation. Functional Configuration Audit (FCA) verifies that the product meets its requirements. Physical Configuration Audit (PCA) verifies that the as-built product matches the as-designed documentation. Auditing answers: "Does what we have match what we said we have?"

These four functions work together. Identification creates the naming system. Control governs changes. Accounting tracks status. Auditing verifies truth. Remove any one and the system degrades: without identification, you cannot track; without control, changes are chaos; without accounting, you cannot answer status questions; without audit, your records may be fiction.

Baselines: Snapshots of Truth

A baseline is a formally approved configuration at a specific point in time. It is the reference against which all subsequent changes are measured. Engineering organizations maintain multiple baselines as a product matures.

Functional Baseline. Established at system-level requirements review. Defines what the system must do. All subsequent design work must satisfy this baseline.

Allocated Baseline. Established when requirements are allocated to subsystems and components. Defines the design-to for each element. Changes to the allocated baseline require evaluating impact on the functional baseline above and the product baseline below.

Product Baseline. Established when the detailed design is verified and the product is approved for production. Defines what is built. Changes to the product baseline require evaluating impact on manufacturing, test, and fielded configurations.

Baselines are not static — they evolve through controlled change. But every change is measured against the baseline: what was it, what will it become, what is affected. Without baselines, "the current design" is whatever is on the engineer's screen at the moment, and "what changed" is whatever they remember.

Interoperability Standards: Enabling the Thread Across Tools

The digital thread runs across tools. Requirements in one tool, design in another, simulation in a third, test management in a fourth. If each tool stores data in a proprietary format, every cross-tool connection requires custom integration code that breaks when either tool updates. Interoperability standards exist to solve this problem — by defining common data formats and connection protocols that allow tools from different vendors to exchange and link data.

The practical reality is that no single standard covers the entire thread. Different standards address different lifecycle domains and different types of data. Understanding what each standard does — and where it falls short — is essential for building integrations that survive tool upgrades and vendor changes.

The Practical Reality of Standards Adoption

No engineering organization runs entirely on standards-based integrations. The reality is a patchwork: some connections use OSLC, some use STEP, some use proprietary APIs, some use flat-file exports, and some use email with attachments. The goal is not standards purity — it is reducing the number of custom, fragile connections that break when tools update.

A pragmatic approach prioritizes standards-based integration for the highest-volume, highest-risk data flows — the connections that break most often and cost the most when they do. For lower-volume connections, a well-documented custom integration may be perfectly adequate. The mistake is assuming that buying "standards-compliant" tools automatically creates interoperability. It does not. Standards compliance means the capability exists. Exploiting that capability requires configuration, testing, and maintenance — just like any other engineering system.

CM and Standards Together

CM and interoperability standards serve the same goal from different directions. CM ensures that the data in the thread is trustworthy — that what is recorded matches what is real, and that changes are controlled. Standards ensure that the data in the thread can flow across tool boundaries without losing structure or meaning.

Together, they answer the question: can we trust that the data connected by our digital thread is accurate, current, and complete — even when it spans multiple tools, multiple teams, and multiple lifecycle phases? If the answer is yes, you have a functioning thread. If the answer is "mostly" or "we think so," you have work to do.

Assessment