04 — The product information model

“The fan has changed” is insufficient information for an engineering business. It might mean that the supplier corrected a drawing, introduced a non-interchangeable replacement, changed the fan used on Vehicle 04, or replaced a failed physical fan on Vehicle 01. Each interpretation affects different obligations, orders, installation work and evidence. A product information model establishes the nouns and relationships needed to distinguish them.

The model is a logical account of information and meaning. It precedes database configuration. It asks what the business must identify, what may change independently, which relationships have engineering significance and who may authorise them. Installed tools do not settle these questions. The logical records below describe engineering meaning rather than native Teamcenter object definitions.

Identity, revision and use

A type or part identity identifies a defined kind of item. It persists while controlled changes are made under the programme's identity policy. A revision identifies a particular controlled definition of that item. An occurrence identifies its use in a parent structure and configuration context. A physical instance identifies an actual manufactured item at the serial or lot granularity the programme requires.

Suppose the fictional fan type is FAN-EX. Revision A and revision B are different controlled definitions associated with that identity. Whether a proposed change is allowed to remain under the same part identity depends on an explicit interchangeability and identification policy. A changed mating connector may justify a new identity because old and new cannot be freely substituted. The existence of a revision facility in software is not permission to conceal incompatibility within it.

The cooling-module fan occurrence identifies where that fan is used. Another use of the same fan elsewhere has its own context, even if it references the same revision. The occurrence may carry installation orientation or a position designation; it should not duplicate authoritative fan characteristics such as the supplier's rated interface definition. A physical serialised fan installed in Vehicle 01 is a different record again. Removing it does not delete the design occurrence or change the reusable fan type.

An occurrence path alone can be fragile if restructuring changes its parent. This operating model assigns stable use identities where history and cross-view reconciliation depend on them, while retaining parent relationships and valid contexts. Persistence through restructuring needs explicit rules: moving an occurrence is not always the same engineering event as deleting one and introducing another. The implementation must preserve the interpretation chosen by the configuration authority.

Concrete logical records

The following illustrative records describe required meaning, not an application programming interface or a supplier data format.

Each record needs provenance: who created it, its source, its controlled state and the authority for consequential decisions. An identifier is an addressable reference, not proof of correctness. A supplier number and an internal number can refer to the same item through a controlled cross-reference; they should not be merged merely because descriptions resemble one another.

Relationships carry engineering meaning

“Related to” is useful for navigation but weak for decisions. A requirement may be derived from another requirement, allocated to a system element, satisfied by a design argument and verified by a result. These are different claims. A manufacturing operation consumes material or installs a component; a test result assesses a specified characteristic. An order purchases an identified supply scope. None of these relations means the same thing as product composition.

Relationships may themselves require revision, applicability and approval. A hose connects two endpoint occurrences in a particular installation. Changing one endpoint can alter the connection even when both reusable part definitions remain unchanged. Recording only the hose's part number loses the contextual obligation. Connection design and completion are developed in chapter 05a; the information model provides identities to which those definitions and records attach.

An engineering bill of materials (EBOM), manufacturing bill of materials (MBOM) and bill of process (BOP) answer different questions: what engineering defines, how material is organised for manufacture, and what operations realise it. The cooling module may be a design grouping, purchased package and installation module, while service replaces its fan separately. Reconciliation should explain the mapping and any intentional differences. It should not force identical trees merely to make comparison easy.

Siemens describes Teamcenter capabilities for BOM management and manufacturing process planning. These public descriptions support the capability categories, not the specific logical records above or a guaranteed implementation of their semantics. Teamcenter BOM management, manufacturing process planning

Authority is specific

An authoritative attribute is the value which the business has empowered a named source and role to control for a stated use. Authority cannot be inferred from whichever system last copied it. The authority register identifies the information class, attribute or coherent attribute group, owner, authoring source, approval role, permitted consumers and reconciliation rule.

For example, engineering controls the released fan selection for a vehicle configuration. Procurement controls the commercial order and supplier commitment. Receiving records what arrived, including mismatches. A receiving clerk cannot make an incorrect fan acceptable by changing its received identity to match the order. Engineering cannot make a purchase amendment effective by editing the EBOM. The records must disagree visibly until an authorised disposition resolves the discrepancy.

DOORS holds the customer requirements. NX, Capital, Teamcenter and SAP have selected roles, but the authority of particular fields, derived requirements and physical configuration records remains to be designed. Replicas should retain source identifiers and revision context. Where a copy is transformed, the transformation and interpretation must be defined. A text description copied into a purchase order may become a contractual statement; treating it as a harmless cache would be a serious category error.

Datasets and documents also need identity and context. A CAD file is not necessarily the entire released part definition. Specifications, approved notes and external references may contribute. A rendered drawing and its source model should be linked by an explicit derivation or representation relationship. If their content conflicts, the programme needs an authority rule and correction process; “use the latest file” is inadequate.

Baselines and time

A baseline is an identified, controlled set of information and relationships established for a purpose. It might support a design review, supplier commitment, manufacturing package or acceptance decision. It must identify the included versions and relevant selection rules. A saved list of top-level part identities cannot reproduce a configuration if the child selection changes later.

Applicability states where a definition or decision is intended to apply: perhaps Vehicles 03 and 04, a serial range or an option combination. Date effectivity is useful only when the date's meaning is defined. Approval date, intended introduction date, actual installation date and the date a record was entered are different facts. Late entry of an installation event must not imply that the fan was physically installed only when the clerk recorded it.

The business therefore needs two practical historical questions: what was believed and authorised at a past decision, and what is now known to have been physically true then? Corrections should preserve provenance rather than silently rewrite the earlier decision basis. This temporal requirement does not prescribe a particular database implementation.

The connector change across four vehicles

A supplier proposes a new fan connector after Vehicle 01 has entered build. The change record identifies the old and proposed definitions, affected endpoint uses and the reason. Impact analysis traverses the fan use to the mating harness, protection and control assumptions, supplier orders, installation plans, inspection procedures and support material. It must include already-released packages and existing physical stock, not just the current authoring model.

Vehicle 01 may retain the existing compatible pair under its approved basis; Vehicle 02 may need an order amendment before supply; Vehicles 03 and 04 may adopt the replacement pair. These are possible assessed outcomes, not automatic selections. The disposition records the actual decision for each vehicle, including any rework or retest obligations. A mixed pair remains incompatible even if each component is individually released.

When a fan arrives, receiving records its actual identity and pedigree. Installation links the actual fan to the vehicle position and operation. Inspection or functional evidence refers to that configuration. If the wrong mating half is discovered, a nonconformance and authorised recovery preserve the truth of what happened. Publishing a revised BOM cannot retrospectively establish that the shop installed it.

Information at programme scale

For millions of occurrences over multi-year manufacture, a part-level search and an occurrence-level impact query answer different questions. One finds all uses of a reusable definition; the other identifies selected configurations, released work fronts and actual installed instances. Thousands of people need scoped authority and access, durable identifiers and repeatable baseline selection. They also need exception handling when supplier data arrives late or inconsistent.

The programme should test the information model with representative queries before large migration: identify vehicles with an affected connector pair; distinguish ordered from installed fans; reproduce a manufacturing commitment; identify results invalidated by changed inputs; explain differences between engineering, manufacturing and service structures. These tests evaluate meaning as well as retrieval. Public vendor pages provide no throughput guarantee for these particular queries.

For four vehicles, some controlled registers may initially be simple. Their relationships and authority should still be explicit. The cost of an elaborate schema is justified only where it supports decisions, traceability or reliable exchange. The model succeeds when people can answer what was authorised, what applies, what exists and what evidence supports it without treating those as interchangeable questions.