27 — Teamcenter reference architecture

A manufacturing team needs to know which cooling module it may install, which instructions apply and what remains unresolved. Giving it access to every engineering file does not answer those questions. The reference architecture must turn controlled engineering decisions into usable, reproducible work packages while preserving the difference between intended product and actual vehicle.

Teamcenter provides the lifecycle coordination centre in this operating model. It does not replace the technical authorities or make every connected record authoritative. Start with the logical information model in chapter 04 and the decision boundaries in chapter 15. Map those meanings to configured services only after testing the relationships on real work.

Controlled information and relationships

Establish separate logical classes for requirements references, architecture elements, analysis cases, product definitions, manufacturing plans, change decisions, physical records and acceptance evidence. A class identifies a distinct responsibility and lifecycle, not necessarily a bespoke database type. A requirement reference preserves its DOORS identifier and baseline context; it does not become an independently editable customer requirement because it appears in Teamcenter.

Product definition comprises part identities, revisions, controlled datasets and contextual occurrences. A part identity answers which kind of item is intended. A revision fixes a controlled definition. An occurrence identifies a use within a parent and configuration. A physical instance identifies the actual supplied or manufactured item. These distinctions prevent a revised fan model from silently changing the recorded fan already installed on Vehicle 01.

Relationships need meaning as precise as their endpoints. A requirement is allocated to a function; an analysis supports an adequacy claim; a definition satisfies an allocated obligation; an operation installs an item; evidence verifies a characteristic on an identified configuration. A generic attachment cannot express all these meanings reliably. Give consequential relationships an owner, version context and applicability, with rules governing their correction.

For the cooling module, identify the radiator, fan, hose and bracket uses separately. Record mechanical mounting relationships, fluid endpoints and the electrical mating interface. A bolt can be a material item while the joint carries contextual requirements. A connector definition identifies reusable characteristics while the connection identifies the two actual endpoint uses. Cross-assembly connections require an integrating owner because neither assembly tree alone contains the entire obligation.

Structures that answer different questions

The engineering bill of materials (EBOM) represents the defined product composition. The manufacturing bill of materials (MBOM) organises material for production. The bill of process (BOP) describes operations, sequence, resources and required evidence. The same cooling module may be designed as a functional grouping, purchased within a supplier package and installed through several operations. Forcing these structures to match would conceal the decisions needed to manufacture it.

Reconciliation therefore records correspondences and justified differences. Every engineering use requiring physical realisation must have a disposition in the manufacturing view. Manufacturing-only consumables and temporary aids require their own classification and authority. A process operation must identify the material or connection it realises and the product-definition basis it follows. An unexplained unmatched line is an exception requiring investigation; an intentional split between installation stages is a recorded mapping.

Siemens describes Teamcenter BOM capabilities including release, effectivity and variants. This supports the product category, rather than the particular logical schema described here. Siemens BOM management. Siemens also describes MBOM and BOP management in Teamcenter Easy Plan; selecting and configuring that capability remains an implementation decision. Siemens Easy Plan.

Releasing a commitment

A baseline fixes the information and relationship versions needed to reproduce a decision. Its purpose matters: a procurement baseline can authorise a bought engine and transmission while the detailed harness routing remains unfinished. It must include the interface constraints that protect that purchase, the outstanding assumptions and the authority accepting exposure. Whole-vehicle completeness is unnecessary for that commitment, but missing interface information can make the commitment unsound.

Release status identifies permission for a stated use. Applicability identifies the vehicles or configurations to which it applies. Maturity describes the confidence and completeness of the definition. These are distinct attributes. A mature design may be inapplicable to Vehicle 01; a locally released bracket may legitimately precede completion of the complete vehicle design.

A work package should resolve its baseline and applicability before issue. Referencing “latest released” without preserving the resolved selection makes later reproduction unreliable. Preserve the exact definition, instructions, interface constraints and acceptance basis issued for the task. Subsequent changes create a controlled decision about that package rather than silently refreshing its contents.

Supplier connector change

Vehicle 01 is building, Vehicle 02 has major equipment ordered and Vehicles 03–04 remain in planning. A supplier notification changes the cooling fan connector. The initial record describes a proposal, not permission to substitute. The responsible engineer identifies the fan endpoint, the supplier harness mating endpoint, associated electrical assumptions and any mechanical routing consequences.

The impact view includes stock, purchase commitments, released installation packages and support information. Procurement establishes whether the supplier owes the earlier configuration and what an amendment would require. Technical authorities establish compatibility and required verification. Manufacturing establishes whether the changed pair can be installed with the existing access and sequence. These decisions cannot be collapsed into a single design-release signature.

An assessed disposition might retain a compatible old pair on Vehicle 01, amend Vehicle 02 supply and introduce the new pair on Vehicles 03–04. The baseline records those choices individually. If incompatibility requires a new part identity, a convenient revision convention must not overrule that identification decision. Both mating sides and their applicability move together through the controlled change.

Closure requires evidence of each obligation: supplier acknowledgement, order disposition, manufacturing-plan update, installation or retained-configuration record and relevant verification. Approval alone does not establish implementation. Where Vehicle 01 already contains the old pair, its physical history remains true even after the new definition becomes the normal future selection.

Permissions and evidence

Permissions should follow delegated decisions and information sensitivity. A supplier may submit its definition without being allowed to approve vehicle applicability. A planner may revise an operation without changing the released product characteristic. An administrator can maintain software without acquiring engineering authority. Separate preparation, technical judgement, configuration control and contractual commitment in the recorded decision, even where a small organisation combines some roles.

Evidence records need their procedure version, assessed characteristic, actual configuration, result, disposition and reviewer. A successful test with an earlier fan and calibration does not automatically verify a later combination. Store software and calibration identity with the configuration where behaviour depends on them, including their compatible hardware and installation evidence. The architecture must preserve such relationships even if specialised software lifecycle and test tools hold the underlying artefacts.

SAP can hold commercial, material and execution information within its assigned scope. Its presence does not establish ownership of the complete as-built vehicle. Define where serialised installation events, inspection results, nonconformances and later maintenance changes are controlled, then provide a coherent physical-configuration view across those sources.

Implementing at scale

Millions of occurrences over years of manufacture make unrestricted tree traversal and manually checked spreadsheets inadequate as the sole control. Design bounded configuration queries, indexed identifiers, access scopes and retained baseline selections. Test representative impact searches with supplier restrictions and historical configurations included. A fast query that omits inaccessible affected data is a governance failure unless its incompleteness is explicit.

Thousands of users need understandable tasks and escalation routes. Avoid creating a separate workflow for every organisational preference. Configure a small set of decision patterns with explicit exceptions and risk-based routing. Validate upgrades against baseline reproduction, permissions, reconciliation and evidence retrieval. These are business acceptance tests; a successful software installation does not demonstrate them.

The reference architecture succeeds when it can explain a commitment, reconstruct its basis, find affected work and prove its disposition. Detailed vendor object mappings, licences, connectors and performance limits must be established against the selected versions before implementation. The logical model remains the acceptance criterion for that work.

A logical setup that can be inspected

The following setup is a conceptual implementation contract. Its class names are business meanings, not verified native Teamcenter types. Configure existing types and relationships where they preserve these meanings; introduce extensions only where the selected installation cannot represent them adequately.

A fan used twice needs two occurrence contexts even when both select the same part revision. Vehicle applicability belongs to the controlled selection and decision context; it cannot safely be inferred from the fan revision alone. Preserve the selected structure and relationship versions in the baseline. A later correction to an occurrence mapping must not change the historical answer to what Vehicle 01 was authorised to receive.

Follow one change through its lifecycle

For the supplier connector notification, use this logical lifecycle graph: received → bounded impact assessment → technical disposition → commitment authorisation → package release → recipient acceptance → scoped implementation → evidence reconciliation → closure. Rejection and further assessment are legitimate branches. A hold can interrupt release or implementation. These states describe the operating model; native workflow objects, status propagation and transaction hooks require installation-specific verification.

At assessment, the interface owner links both mating occurrences and checks whether bracket clearance, hose access or harness support changes. An unchanged radiator need not acquire a gratuitous revision, but the assessment must preserve why its mechanical and fluid interfaces remain adequate. NX mechanical definition and Capital electrical definition contribute separate controlled inputs. The customer payload and hot-climate changes retain their DOORS origins and independent dispositions even where they share this assessment.

At reconciliation, the EBOM fan use maps to the MBOM installation material, while its mating harness may arrive in another manufacturing assembly. The BOP assigns mounting, fluid connection and electrical mating to their actual operations. A separate inspection operation may verify the completed connection. Counting material consumption twice because two operations mention the fan is an error; referencing it for installation and subsequent inspection is legitimate. The correspondence therefore needs relationship meaning, not merely matching identifiers.

Technical disposition establishes acceptable combinations. Procurement then establishes the authorised order action for Vehicle 02. Release checks the executable package; recipient acceptance establishes that the manufacturing organisation can use it. None substitutes for the others. Vehicle 01 can continue unrelated chassis operations while its affected cooling operations remain held. Vehicles 03–04 receive the revised planning basis only within the authorised applicability.

A restart record must identify the vehicle and operations released from hold. It requires technical clearance, executable instructions, available compatible material and resources, acknowledgement by execution, and the delegated authority accepting any remaining exposure. Clearing a technical query alone cannot restart work with obsolete instructions. The permission model should prevent a workflow administrator or transport service from supplying these business decisions.

Closure distinguishes completed physical work from transferred obligations. If a later service action is legitimately deferred, record its accepting owner, affected units, acceptance criteria, due event and required return evidence. Administrative closure of a transfer does not establish physical completion. The physical configuration view continues to show the retained arrangement until actual modification evidence returns. Baseline and obligation queries must expose that residual work rather than presenting a single misleading green status.