4. Product Information Models and Lifecycle Data

Introduction and Context

Product Lifecycle Management (PLM) depends on the ability to represent a product consistently from its initial concept through design, production, operation, maintenance, retirement, and disposal. Engineering drawings, three-dimensional models, specifications, software, supplier records, manufacturing instructions, inspection results, service histories, and regulatory certificates are not isolated documents. Together, they form a body of product information that must remain identifiable, related, controlled, and accessible throughout the product lifecycle.

The central difficulty is that different functions view the same product differently. Design engineering is concerned with geometry, functional requirements, interfaces, and design intent. Manufacturing focuses on process sequences, work centres, tooling, materials, and assembly feasibility. Procurement requires supplier parts, approved sources, commercial information, and delivery constraints. Service organizations need replaceable units, maintenance tasks, serial-number histories, and field configurations. A successful PLM environment reconciles these views without destroying the information needed by any one function.

This chapter examines the models used to represent product information and the lifecycle data associated with those models. Particular attention is given to parts, documents, specifications, metadata, classifications, product structures, variants, and the relationship among engineering bills of material (EBOMs), manufacturing bills of material (MBOMs), and service bills of material (SBOMs). The discussion treats PLM as both an information-management discipline and an organizational practice.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain the role of product information models in PLM.

2. Distinguish parts, documents, specifications, metadata, classifications, and configurations.

3. Describe how product structures and bills of material represent functional and physical relationships.

4. Compare EBOM, MBOM, and SBOM structures and explain their reconciliation.

5. Apply lifecycle states, revision rules, effectivity, and change governance to product data.

6. Evaluate practical risks involving data quality, duplication, access, traceability, and configuration control.

7. Propose an information architecture for a multi-disciplinary product environment.

Product Information as a Lifecycle Model

A product information model is a formal representation of the objects, properties, relationships, and rules that describe a product. It answers questions such as: What is the item? Which version is approved? Where is it used? Which documents define it? Which requirement does it satisfy? Which manufacturing operation creates it? Which service kit replaces it? Under what conditions is it effective?

A useful model normally contains four layers. The first is the object layer, consisting of items such as parts, assemblies, raw materials, software components, tools, documents, requirements, processes, and suppliers. The second is the attribute layer, containing properties such as material, mass, tolerance, safety classification, maturity state, owner, and validity date. The third is the relationship layer, which records links such as “is part of,” “is documented by,” “satisfies,” “is manufactured by,” “is replaced by,” and “is applicable to.” The fourth is the governance layer, which defines access rights, approval workflows, revision rules, retention periods, and audit records.

The object is not the same as its representation. A component may be a controlled part object, while its CAD model, drawing, test report, and supplier certificate are separate information objects linked to it. This distinction prevents a common error: treating a file name as if it were the product definition. A CAD file can be renamed, copied, or replaced; the controlled part identity and its lifecycle history should remain stable.

Important Information Objects

A part is an identifiable item intended to perform a physical or logical function within a product. It may be a purchased component, manufactured component, standard item, raw material, software element, or complete assembly. A part generally has a persistent identifier and may have multiple revisions or versions.

A document is a controlled information container or record that communicates, proves, or supports product knowledge. Examples include drawings, specifications, test reports, process plans, manuals, certificates, and inspection records. Documents may define a part, provide evidence of conformity, or prescribe an activity.

A specification states measurable requirements or constraints. It may define material composition, performance, environmental resistance, dimensions, interface conditions, or acceptance criteria. Specifications can be internal, customer-provided, regulatory, or industry-based. Their authority and applicability must be explicit.

Metadata is structured information about an object. Author, creation date, revision, status, owner, classification code, security level, and effective date are examples. Metadata makes information searchable and supports automation; it is not merely administrative decoration.

A classification system groups objects according to shared characteristics. A fastener classification may use diameter, thread type, length, material, and head form. Classification reduces duplicate creation, improves search, supports standardization, and enables reuse. A classification should not replace a unique item identity: two items may belong to the same class while differing in a technically significant property.

A configuration is a defined selection and arrangement of product elements under specified conditions. Configurations may differ by market, customer, model year, option, operating environment, or regulatory requirement. Configuration management ensures that the product delivered, manufactured, or serviced can be reconstructed accurately.

Identity, Revision, Version, and Effectivity

Product data requires precise identity rules. An item number identifies an information object, while a revision identifies a controlled change to that object. A version may refer to a working or system-generated iteration that has not yet become an approved revision. Organizations must define these terms consistently because confusion between them creates false traceability.

For example, a bracket may retain item number BRK-2045 while moving from revision A to revision B after a hole diameter changes. A designer may create several working versions of revision B, but only the approved revision should be released for production. The revision scheme must also state whether a change is form-fit-function significant, interchangeable, or safety-critical.

Effectivity specifies when, where, or to which product population information applies. Time effectivity may state that a revision is valid from a particular date. Serial-number effectivity may apply a change beginning with unit 1201. Lot effectivity may apply it to a material batch, while model or option effectivity may restrict it to a product variant. Effectivity is essential when old and new configurations coexist in the field.

Lifecycle states describe maturity and permission. A typical sequence is In Work, Under Review, Approved, Released, Obsolete, and Archived. These labels are meaningful only when associated with rules. For instance, an In Work model may be editable by its owner, an Approved drawing may require formal change control, and an Obsolete item may remain visible for historical service records but be prohibited from new production.

Product Structures: From Components to Meaningful Relationships

A product structure is a hierarchical or network representation of how product elements relate to one another. The familiar parent-child hierarchy is useful for assemblies, but PLM structures can also capture alternative, reference, functional, and process relationships.

A usage relationship connects a child item to a parent and may contain quantity, unit of measure, find number, position, reference designator, effectivity, and substitute information. The statement “four bolts are used in the housing assembly” is therefore more informative than a simple list of the bolt number. It records how many are required, where they are used, and under which configuration.

A functional structure describes what the product must do. It may contain functions such as “convert electrical energy,” “support payload,” or “control temperature.” A logical structure allocates functions to systems and subsystems. A physical structure identifies the actual parts and assemblies that realize those functions. Keeping these views related helps engineers evaluate whether a physical change affects a requirement or a system function.

A document structure organizes drawings, models, reports, instructions, and certificates. A requirements structure links stakeholder needs to system requirements, allocated requirements, verification methods, and evidence. These structures create digital traceability across the product definition rather than relying on informal references in filenames or spreadsheets.

Bills of Material and Their Different Purposes

A bill of material (BOM) is a structured description of the items required to define, make, sell, install, operate, or service a product. The word “BOM” therefore does not refer to one universal list. Its content depends on the viewpoint and business purpose.

Engineering BOM

The EBOM represents the product as conceived and designed by engineering. It commonly follows functional and system decomposition. It includes design parts, assemblies, quantities, reference designators, design documents, and sometimes requirements or analysis links. The EBOM expresses design intent and the physical relationships needed to define the product.

An EBOM may contain items that are not directly visible on the manufacturing floor, such as design-only reference objects, virtual assemblies, or software allocations. Conversely, it may omit manufacturing consumables, packaging, process aids, or intermediate assemblies because those are not part of the engineering definition.

Manufacturing BOM

The MBOM represents how the product is planned and assembled in a manufacturing environment. It may reorganize engineering parts into manufacturing assemblies, work packages, kits, phantom structures, and operation-specific groupings. It includes manufacturing-specific materials, consumables, tools, process constraints, and plant or line applicability where appropriate.

The MBOM is not simply a copied EBOM. A single engineering assembly may be divided into several manufacturing stages. Purchased components may be grouped into a kit, while a design assembly may be temporarily disassembled for painting, inspection, or subassembly production. The MBOM must preserve the technical identity of the product while expressing the physical and logistical reality of production.

Service BOM

The SBOM represents the product from the perspective of operation, maintenance, repair, overhaul, and replacement. It identifies serviceable units, maintenance assemblies, spare parts, consumables, diagnostic references, and replacement relationships. A service assembly may combine several engineering parts into a replaceable unit, or it may expose components that were not separately handled during production.

The SBOM is particularly important for products with long operating lives. The configuration of a fielded product may differ from its original manufacturing configuration because of retrofits, repairs, substitutions, and approved modifications. Service information must therefore support serial-number traceability and historical reconstruction.

Reconciliation of EBOM, MBOM, and SBOM

BOM reconciliation is the controlled alignment of different product views. It does not require every BOM to be identical. Instead, it requires that differences be understood, authorized, traceable, and technically coherent.

A practical reconciliation approach begins with a common item identity. Where the same physical item is used by engineering, manufacturing, and service, the systems should reference one controlled item rather than create unrelated duplicates. The next step is to map relationships. Each MBOM node should be traceable to one or more EBOM objects, and each serviceable unit should be traceable to the physical product definition and its approved replacement logic.

The reconciliation process commonly includes:

• defining the scope and purpose of each BOM;
• establishing common item, revision, unit-of-measure, and naming rules;
• mapping parent-child relationships across views;
• identifying manufacturing-only, service-only, consumable, and phantom items;
• applying effectivity and configuration rules;
• validating quantities, interfaces, and interchangeability;
• connecting change notices so that affected BOMs are updated together; and
• auditing unresolved differences before release.

Consider a gearbox. Engineering may define a housing, gear train, bearings, seals, and fasteners in the EBOM. Manufacturing may create machining, bearing installation, shaft assembly, and final-test structures in the MBOM. Service may define the complete gearbox as a replaceable unit, with a seal kit and bearing kit as field-replaceable items in the SBOM. These structures are different, but they must agree on identity, interfaces, approved alternatives, revision effectivity, and the relationship between the complete unit and its replaceable elements.

Reconciliation can be supported by a cross-reference matrix. Each row identifies an item or assembly, while columns record EBOM usage, MBOM usage, SBOM usage, effectivity, ownership, and discrepancy status. Such a matrix is especially useful during migration from legacy systems, although it should not become a permanent substitute for integrated relationships in the PLM architecture.

Data Governance and Change Control

Product information has value only when its meaning and authority are controlled. Data governance assigns responsibility for definitions, quality, access, retention, and change. Typical roles include data owner, data steward, author, approver, configuration manager, manufacturing representative, service representative, and system administrator.

Change control connects technical decisions with lifecycle records. A change request describes a problem or opportunity; a change proposal evaluates alternatives, cost, risk, and affected objects; a change order authorizes implementation; and release records establish the new approved baseline. The workflow should include cross-functional review when a change affects manufacturability, supply, service, safety, regulatory conformity, or customer commitments.

A mature change process evaluates impact through relationships rather than manual memory. If a material specification changes, the system should help identify affected parts, drawings, suppliers, processes, inspection plans, service manuals, and field units. Impact analysis is one of the major reasons for building a connected information model.

Data quality should be assessed using dimensions such as completeness, accuracy, consistency, timeliness, uniqueness, validity, and traceability. Duplicate parts, missing units, inconsistent material names, obsolete links, uncontrolled spreadsheets, and ambiguous revision codes are common sources of lifecycle risk.

Digital Technologies and Emerging Practice

Modern PLM platforms use relational databases, object-oriented models, graph relationships, workflow engines, and application programming interfaces to connect lifecycle information. Model-based definition replaces or supplements standalone drawings by embedding product requirements, tolerances, annotations, and manufacturing information in a three-dimensional model. The objective is not simply to eliminate drawings but to create a more authoritative and machine-readable product definition.

Digital threads connect requirements, design objects, analyses, manufacturing plans, quality evidence, and field data. Digital twins extend this idea by associating a physical asset with lifecycle information and, in some applications, operational data. Their usefulness depends on trustworthy identity, configuration, and sensor-data relationships; a visually impressive dashboard cannot compensate for weak product data governance.

Artificial intelligence can assist with duplicate detection, classification, semantic search, anomaly identification, and impact analysis. It may suggest that two part descriptions are similar or identify a likely affected assembly after a change. Human authorization remains necessary because similarity is not the same as interchangeability, and automated recommendations may overlook safety, contractual, or regulatory context.

Interoperability is increasingly important. Neutral exchange formats, standardized identifiers, APIs, and digital collaboration environments allow PLM, enterprise resource planning, manufacturing execution, simulation, quality, and service systems to exchange information. Integration should be designed around governed meanings and relationships rather than unrestricted file transfer.

Applied Case: Reconciling Product Views for an Industrial Pump

Background

The following is an illustrative case involving a manufacturer of centrifugal pumps used in chemical-processing plants. The company designs pumps in a CAD and PLM environment, plans production in an enterprise resource planning system, and supports customers through a separate service organization.

Situation and Problem

Engineering maintained an EBOM containing the impeller, casing, shaft, mechanical seal, bearings, fasteners, motor adapter, and instrumentation. Manufacturing had developed local spreadsheets that grouped components according to machining and assembly stations. Service used a catalogue in which the complete pump was treated as a replaceable unit, while seal kits and bearing kits were listed as spare parts.

A customer reported a seal failure and requested the correct replacement kit for a pump installed three years earlier. The service team found two seal kits with similar descriptions. Engineering had changed the seal material in revision C because of chemical compatibility, but manufacturing had continued using old stock for certain serial numbers. The service catalogue did not contain serial-number effectivity, and the ERP system used a different item code from PLM.

Analysis

The immediate problem was not merely an incorrect catalogue entry. It resulted from disconnected identities, incomplete effectivity, and ungoverned differences among BOMs. The same physical pump family had several representations, but the relationships among them were weak. The change to the seal affected engineering definition, procurement, manufacturing inventory, inspection requirements, and service replacement logic.

A cross-functional team mapped the EBOM, production structures, inventory items, service kits, drawings, supplier certificates, and installed-base records. It identified that the seal change was approved for pumps beginning with serial number P-1840, but the effectivity was recorded only in an engineering change document and not in the service structure.

Approach and Solution

The company established a common item identity for the seal and created controlled links to its revisions, approved suppliers, material specification, inspection record, and service kit. The MBOM retained a manufacturing-specific grouping for the seal installation operation but referenced the same controlled seal item. The SBOM defined the seal kit as a service assembly and included replacement rules for earlier pump configurations.

A serial-number effectivity table was added. Service personnel could now enter the pump serial number and retrieve the applicable seal revision, kit, installation instruction, torque values, and compatibility warning. Existing inventory was segregated by revision, and the change process was modified to require manufacturing and service impact review before release.

Outcome

The organization reduced ambiguity in service selection and gained a traceable relationship from the fielded pump to the applicable seal revision. Production retained its required process structure without creating a second technical identity. Engineering, manufacturing, and service could each view the product in a useful form while relying on shared controlled objects.

Learning Points

The case demonstrates that BOM reconciliation is not an exercise in making lists look identical. It is the management of meaning across viewpoints. Common identity, explicit effectivity, controlled replacement logic, and cross-functional change impact are more important than a single universal hierarchy. It also shows why service data must be considered during design and not added only after the product enters the field.

Challenges, Risks, and Professional Considerations

One major risk is duplication. Different departments may create separate item numbers for the same component because of naming differences or system limitations. Duplication increases inventory, obscures usage, and makes change impact analysis unreliable. Another risk is over-standardization: forcing all products into one rigid structure can conceal legitimate differences in function, manufacturing, or service practice.

Access control creates a further challenge. Product information may contain export-controlled technology, personal data from service records, supplier intellectual property, or safety-critical design details. Access should follow legitimate business need, contractual restrictions, segregation of duties, and applicable legal requirements. Audit trails should record who changed or approved controlled information.

Organizations must also preserve historical truth. Replacing an obsolete document without retaining the prior approved version can make it impossible to determine what was supplied to a customer or installed in a field asset. Retention policies should therefore distinguish current usability from historical accountability.

Ethically, engineers and managers have a duty not to obscure uncertainty or release incomplete information merely to meet a schedule. Incorrect revision status, unverified substitutions, or misleading configuration records can create safety hazards and expose an organization to regulatory and professional consequences. Product information is part of the evidence supporting responsible engineering decisions.

Best Practices for Product Information Management

Effective organizations generally adopt the following practices:

1. Define a common data dictionary for item names, units, states, revisions, and effectivity.

2. Assign ownership and stewardship for major information domains.

3. Separate persistent item identity from file names and working versions.

4. Use controlled relationships instead of unmanaged hyperlinks and spreadsheets.

5. Design EBOM, MBOM, and SBOM processes together.

6. Require cross-functional impact analysis for significant changes.

7. Treat metadata quality as a measurable engineering and business responsibility.

8. Preserve approved historical configurations and field effectivity.

9. Integrate PLM with ERP, manufacturing, quality, and service systems through governed interfaces.

10. Use automation and AI to assist, not replace, engineering judgment and approval authority.

Chapter Summary

Product information models provide the structure through which PLM identifies, describes, relates, controls, and governs product knowledge. Parts, documents, specifications, metadata, classifications, requirements, and configurations must be represented as connected objects rather than disconnected files. Identity, revision, lifecycle state, and effectivity establish whether information is authoritative and to which product population it applies.

Product structures express functional, logical, physical, document, process, and service relationships. EBOMs represent design intent, MBOMs represent production realization, and SBOMs represent operation and maintenance needs. These views should not be forced into identical hierarchies; they should be reconciled through shared identities, explicit mappings, effectivity, replacement logic, and change control. Digital threads, model-based definition, interoperability, analytics, and AI can improve access and impact analysis, but their value depends on data quality and governance. The professional objective is a trustworthy, traceable, and usable product information environment across the entire lifecycle.

Key Terms

Product information model: A formal representation of product objects, attributes, relationships, and governance rules.

Part: An identifiable product element intended to perform a physical or logical function.

Document: A controlled information record that defines, supports, or evidences product knowledge.

Specification: A statement of measurable product, material, process, or performance requirements.

Metadata: Structured information describing an object, such as owner, status, revision, or effective date.

Classification: A system for grouping objects according to shared characteristics.

Configuration: A defined selection and arrangement of product elements under specified conditions.

Revision: A controlled change state of an identified product or information object.

Version: A working or system-generated iteration of an object, not necessarily an approved revision.

Effectivity: The rule defining when, where, or to which product population information applies.

Lifecycle state: A governed maturity or permission status, such as In Work, Approved, or Obsolete.

Product structure: A representation of product elements and their relationships.

EBOM: Engineering Bill of Material representing the designed product and design intent.

MBOM: Manufacturing Bill of Material representing how a product is planned and assembled.

SBOM: Service Bill of Material representing maintainable, replaceable, and service-related product elements.

BOM reconciliation: Controlled alignment of different BOM views through mappings, identities, and effectivity.

Digital thread: Connected lifecycle relationships linking product information across functions and systems.

Data stewardship: Operational responsibility for maintaining the quality, meaning, and governance of data.

Model-based definition: Product definition in which a three-dimensional model and embedded annotations provide authoritative technical information.

Review Questions

Short Answer Questions

1. What is the difference between a product information object and its file representation?

2. Why is effectivity important in configuration management?

3. Define metadata and give three examples relevant to PLM.

4. What is the primary purpose of an SBOM?

5. Why should classification not be used as a substitute for unique item identity?

Long Answer Questions

1. Explain the layers of a product information model and show how they support lifecycle control.

2. Compare the purposes and typical contents of EBOM, MBOM, and SBOM structures.

3. Discuss the relationship among item identity, revision, version, lifecycle state, and effectivity.

4. Describe a cross-functional process for reconciling EBOM, MBOM, and SBOM data.

5. Examine the role of data governance and change control in maintaining trustworthy product information.

Analytical / Application Questions

1. A manufacturer has separate part numbers for a component used by engineering, production, and service. Analyze the risks and propose a controlled remediation plan.

2. A design change applies only to products manufactured after a specified serial number, but the service organization has no serial-number records. Determine the information that must be established before releasing the change.

3. Design defines a complete assembly, while manufacturing divides it into three production stages and service replaces it as one unit. Explain how the three structures can remain different yet technically reconciled.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the relationship between a controlled part and its CAD file?

A. The CAD file is the permanent identity of the part

B. The part and its CAD file are separate objects that may be linked

C. A part cannot exist without a single CAD file

D. Changing the CAD file name automatically creates a new part

Correct Answer: B. The part and its CAD file are separate objects that may be linked

Question 2

A revision applies only to products with serial numbers greater than 1200. This is an example of:

A. Classification

B. Document structure

C. Serial-number effectivity

D. Functional decomposition

Correct Answer: C. Serial-number effectivity

Question 3

Which BOM primarily expresses design intent and engineering decomposition?

A. EBOM

B. MBOM

C. SBOM

D. Procurement BOM

Correct Answer: A. EBOM

Question 4

Why might an MBOM legitimately differ from an EBOM?

A. Manufacturing never needs engineering information

B. The MBOM represents production stages, kits, tools, and process groupings

C. The MBOM must contain unrelated customer data

D. Differences eliminate the need for configuration control

Correct Answer: B. The MBOM represents production stages, kits, tools, and process groupings

Question 5

A service organization needs to identify the correct replacement seal for a fielded pump. Which information is most critical?

A. Only the original designer's name

B. The pump's serial effectivity and applicable seal revision

C. The colour of the manufacturing workstation

D. The number of CAD files in the project folder

Correct Answer: B. The pump's serial effectivity and applicable seal revision

Question 6

Which activity is central to BOM reconciliation?

A. Making every BOM hierarchy identical

B. Deleting manufacturing-only items

C. Mapping shared identities and relationships across product views

D. Replacing all structured data with spreadsheets

Correct Answer: C. Mapping shared identities and relationships across product views

Question 7

What is the principal value of metadata in a PLM system?

A. It makes files visually larger

B. It supports search, governance, automation, and interpretation

C. It removes the need for approvals

D. It prevents all design changes

Correct Answer: B. It supports search, governance, automation, and interpretation

Question 8

A component is grouped with other objects according to diameter, material, and thread type. This activity is:

A. Classification

B. Effectivity allocation

C. Service replacement

D. Revision approval

Correct Answer: A. Classification

Question 9

Why should an obsolete product revision remain accessible in some circumstances?

A. To permit uncontrolled reuse in new designs

B. To preserve historical configuration and field accountability

C. To avoid assigning item identities

D. To eliminate audit trails

Correct Answer: B. To preserve historical configuration and field accountability

Question 10

Which use of artificial intelligence is appropriate in product information management?

A. Automatically approving safety-critical changes without review

B. Replacing all configuration managers

C. Assisting duplicate detection and impact analysis while retaining human authorization

D. Treating similar descriptions as proof of interchangeability

Correct Answer: C. Assisting duplicate detection and impact analysis while retaining human authorization