Why the Digital Product Passport Is a PLM Architecture Problem
The Digital Product Passport has moved from policy debate onto the compliance calendar. Under the EU Battery Regulation, a battery passport becomes mandatory on 18 February 2027 for EV, industrial (over 2 kWh), and light-means-of-transport batteries. The Ecodesign for Sustainable Products Regulation (ESPR), in force since July 2024, extends the passport across product groups — steel, textiles, aluminium, furniture, electronics — through a rolling series of delegated acts into the 2030s.
For organizations running Siemens Teamcenter, the instinct to procure a “DPP system” gets the problem backwards. Most of what a passport demands — identity, composition, substances, provenance, compliance evidence, repair and end-of-life data — is already modeled inside the PLM backbone. The passport is an aggregation-and-exposure problem sitting on top of data you already own.
That makes Digital Product Passport PLM readiness a data-model problem before it is a compliance-software purchase. The question is not “which vendor?” but which Teamcenter objects hold the DPP-relevant data, and whether they are structured, populated, and exposable enough to serve it. Get the Digital Product Passport data model right and any passport platform works; get it wrong and none will. Seven objects carry most of the weight.
What the Digital Product Passport Demands
The Digital Product Passport data requirements are consistent across the ESPR categories and the battery-passport template. A passport has to carry:
- A unique product identifier (model, batch, or serial number) bound to a data carrier — QR code, GS1 Digital Link, or RFID
- Material and substance composition, including substances of concern and, for batteries, critical raw materials such as cobalt and lithium
- Origin and supply-chain traceability
- Environmental metrics, such as carbon footprint
- Repairability, spare-parts, and disassembly information
- End-of-life and recycling data
- Compliance evidence — the EU Declaration of Conformity, certificates, test data, and a summary of risk assessments
Two properties drive the architecture. The data spans the full lifecycle — as-designed, as-built, and as-maintained — so no single system owns all of it. And the regulation implies product- and often item-level granularity with an auditable history, not a static datasheet.
Why Teamcenter Is the Natural Backbone
Teamcenter is the system of record for as-designed truth: product structure, the engineering BOM, material specifications, change history, and design documentation. A passport consolidates and exposes that record rather than replacing it.
Across DPP readiness assessments, CloudZen consistently finds teams overestimating the difficulty of selecting a passport platform and underestimating the effort to normalize engineering data across Teamcenter objects. The platform decision is weeks of evaluation. The data-model work below is quarters, and it is where compliance is won or lost.
The Seven Critical Teamcenter Objects
1. Item and Item Revision — Product Identity
The Item (a WorkspaceObject) and its Item Revisions carry product identity, and the passport’s unique identifier must resolve deterministically to a specific Item Revision.
- Maps the passport identifier to a model, batch, or serial number
- Reconciles internal Item IDs with external keys — manufacturer part number, GTIN, GS1 Digital Link
- Revision rules and Effectivity decide which revision the passport describes
- Model-level versus unit-level identity (serialization — object 7)
Where it breaks: intelligent part numbers that were never designed as external keys, and identifier governance that was inherited rather than defined.
2. BOM View Revision and Product Structure — Composition
Composition lives in the structure. The BOMViewRevision exposes the assembly breakdown; Occurrences carry quantity and configuration; substance, recycled-content, and carbon roll-ups traverse it.
- Feeds composition and all roll-up calculations
- Variant Management and Effectivity require resolving a specific effective structure, not a generic BOM
- EBOM, MBOM, and as-built alignment through Manufacturing Process Planner
Where it breaks: an unresolved occurrence or EBOM–MBOM drift silently corrupts a roll-up, usually unnoticed until the number is wrong on a published passport.
3. Classification (CLS) — Machine-Readable Attributes
A passport is machine-readable, which makes free-text worthless to it. Classification — the CLS class hierarchies defined in BMIDE — holds structured attributes that extract consistently across tens of thousands of parts.
- Standardized material and part attributes for automated extraction
- Mapping to external taxonomies (ECLASS and category-specific schemas)
- Requires a data-dictionary owner and active governance
Where it breaks: unclassified or free-text parts — the single most common reason DPP extraction stalls.
4. Material and Substance Compliance — Substances and Critical Raw Materials
Teamcenter’s Material and Substance Compliance model manages materials and declared substances, computes roll-ups against RoHS and REACH/SVHC, and ingests supplier declarations from IMDS (automotive) and BOMcheck (electronics).
- Declared substances, substances of concern, and critical raw materials (cobalt, lithium, nickel)
- SCIP reporting for SVHC above 0.1% by mass — a live preview of DPP substance transparency
- Supplier-declaration coverage and split ownership between engineering and compliance
Where it breaks: substance data stranded in supplier PDFs and spreadsheets instead of modeled against the BOM. This is where most programs stall.
5. Document Revision and Dataset — Compliance Evidence
Evidence lives as Datasets and managed Document Revisions, related to the exact Item Revision they support.
- EU Declaration of Conformity, test certificates, safety data, and repair/disassembly/recycling instructions
- Versioned and bound to the revision they certify
Where it breaks: loose PDFs on network shares, or a certificate related to the wrong revision — worse than no certificate.
6. Change Management — Provenance and Audit Trail
Change objects (ECR/ECN) driven through EPM Workflow, with native revisioning, supply the provenance behind every passport field.
- Captures what changed, when, and by whom
- Passport-controlled attributes must change through controlled change, not in-place edits
Where it breaks: attributes edited in place in Active Workspace, destroying the auditability the regulation implies.
7. Serialized and As-Built Physical Part — Item-Level Passport
Battery passports are issued per unit. The Physical Part and As-Built structure tie a manufactured unit to its configuration and, through the digital thread, to operational and end-of-life data.
- Per-serial composition and compliance, not just per-model
- Join to MES and ERP for as-built capture, and to the physical data carrier in the field
Where it breaks: serialization is expensive to retrofit under a deadline, and model-level data is not enough for item-level categories.
The Governance and Exposure Layer
Two capabilities cut across all seven objects. Release Status, governed through EPM Workflow, decides which data is authoritative — a passport publishes released data, never work-in-progress. Forms and extended attributes modeled in BMIDE hold passport-specific fields without corrupting the standard data model.
Exposure is a separate discipline. A standard is emerging for the supplier–OEM side: the Asset Administration Shell (AAS), the digital-twin envelope Siemens is building into Teamcenter. Whether the transport is AAS, a passport registry, or your own SOA/REST services, direct-database reads and ITK point-to-point interfaces will not serve a per-unit, always-current passport. This is where an API-First integration strategy and disciplined ERP integration become the mechanism that makes the passport work.
Best Practices
- Model DPP attributes on standard objects using Forms and BMIDE — never a parallel passport database
- Populate and govern Classification before attempting extraction
- Bring substance data into Substance Compliance against the BOM, via IMDS, BOMcheck, and SCIP
- Bind every Document Revision to the exact Item Revision it certifies
- Force passport-controlled attribute changes through Change Management (EPM Workflow)
- Define the Release Status that authorizes passport publication
- Resolve EBOM/MBOM alignment and serialization for item-level categories early
- Expose through governed APIs and AAS, not direct database reads or ITK point-to-point
- Map internal identifiers to GTIN and the GS1 Digital Link
- Assign data ownership across engineering, product compliance, and supply chain
Common Anti-Patterns
- Standing up the DPP as a new database that duplicates PLM data, creating a second source of truth
- Substance and compliance data managed in spreadsheets instead of against the BOM
- Unclassified or free-text parts that force manual extraction
- Evidence on network shares, unlinked to the Item Revisions it certifies
- Model-level thinking applied to item-level battery passports
- Snapshot extraction with no provenance, unmaintainable the moment data changes
Business Benefits
- Faster compliance as each product category’s delegated act lands
- A single source of truth, with no parallel passport database to reconcile
- Reuse of existing Teamcenter data, governance, and the digital thread
- Audit-ready provenance through native change and revision control
- Less manual extraction and supplier chasing
- A foundation ready for item-level battery passports and future categories
- Interoperability through AAS and an API-First exposure layer
- Lower long-term cost of compliance across the product portfolio
Conclusion
The manufacturers who comply fastest, and most cheaply, will treat the Digital Product Passport as a data-architecture problem rather than a procurement exercise. For Teamcenter organizations the passport is already inside the platform, distributed across seven objects: Item and Item Revision, the BOMViewRevision, Classification, Material and Substance Compliance, Document Revision, Change, and the serialized Physical Part. The work is to make that data structured, governed, and exposable before the delegated act that names your product category arrives. A structured Teamcenter Health Check focused on Digital Product Passport data readiness is the fastest way to see where you stand. Batteries, in February 2027, are only the first forcing function.
Frequently Asked Questions
What is a Teamcenter Digital Product Passport?
It is not a module you buy. A Teamcenter Digital Product Passport is the aggregation and exposure of passport-required data — identity, composition, substances, compliance evidence, and lifecycle information — that already lives across Teamcenter objects, published to a registry and a data carrier.
Which Teamcenter objects hold Digital Product Passport data?
Primarily seven: Item and Item Revision, the BOMViewRevision and product structure, Classification, Material and Substance Compliance, Document Revision and Dataset, Change objects, and the serialized As-Built Physical Part.
Do we need to replace Teamcenter to comply with the DPP?
No. Teamcenter already models most passport data. The work is data quality (Classification, substance data), change and release governance, serialization for item-level categories, and an API-based exposure layer — not the platform itself.
When does the Digital Product Passport become mandatory?
The first fixed deadline is the battery passport, mandatory from 18 February 2027. ESPR then phases in other categories through delegated acts across the later 2020s. Confirm the timeline for your specific product category.
Where do most Teamcenter DPP programs fail?
On composition and substance data — material information sits with suppliers as declarations and spreadsheets rather than modeled against the BOM. Classification gaps and missing serialization are close behind.
