Part Classification in PLM: Schemas, ECLASS, Shape Search and Duplicate Part Prevention

Every mature manufacturer owns the same embarrassing query result: search the part master for “bracket, steel, 3 mm” and get forty records that are, for practical purposes, the same bracket. Each one was created by a competent engineer who searched, found nothing usable in under two minutes, and drew a new one. Part classification PLM practice exists to make that two-minute search succeed, and to stop the forty-first bracket at the moment someone asks for a new part number.

It matters now because the economics have shifted. Learned geometry embeddings and vector indexes make shape search cheap to run on every request, and semantic dictionaries such as ECLASS and the IEC Common Data Dictionary are becoming the language of the Asset Administration Shell and digital product passports. A classification schema is no longer a filing cabinet; it is the key that joins engineering, procurement and compliance data.

You will leave with a schema design, a data model, a scoring pipeline that fuses attribute and shape similarity, and a governance gate with thresholds you can tune.

What this covers: classification hierarchies and attributes, ECLASS, IEC 61360 and UNSPSC, part numbering, the real cost of a new part, attribute and geometric duplicate detection, ML-assisted classification, a worked example and failure modes.

Context and Background

Part proliferation is a slow leak rather than a dramatic failure. No single duplicate breaks anything. The damage arrives as fragmented purchase volumes, extra inventory locations, more items to qualify, more drawings to revise when a material is banned, and more lines in every compliance roll-up. When a substance restriction lands, the team that must check forty brackets instead of one feels the cost directly; our post on RoHS, REACH and SCIP substance tracking through the BOM shows how that multiplication works.

How much is a new part worth preventing? The most cited public figure comes from the US Defense Standardization Program. Its parts-management business case estimates the average life-cycle cost of adding a new part at about $20,000, built up from engineering and design ($9,300), purchasing ($3,800), logistics support ($3,750), manufacturing storage ($1,750), inventory ($875) and testing ($700), and it explicitly excludes tooling and documentation sets. PTC’s reuse infographic uses a lower planning figure of roughly $5,000 per part per lifecycle phase. Treat both as orders of magnitude, not as your number. Your controller can rebuild the estimate from internal activity costs in an afternoon, and that internal number is what will fund the programme.

Incumbent tooling already covers much of the mechanics. Siemens Teamcenter has long shipped a classification module and the Geolus shape search engine, which Siemens positions as a way to find similar parts even when their names differ. PTC Windchill offers part classification with attribute-driven search, and Dassault Systemes sells 3DEXPERIENCE reuse and classification capabilities. Specialist vendors such as CADENAS focus on geometric search and supplier catalogue content. The PLM vendor landscape overview compares the suites more broadly.

The tools are rarely the bottleneck. Most failed reuse programmes have a reasonable classification module installed and a schema nobody trusts, attributes nobody fills in, and a creation workflow that lets engineers skip search entirely. This post therefore treats part classification as a data-product design problem: what the schema must contain, how matching should score candidates, and where the gate belongs in the part creation workflow. For the wider context of how classification feeds the rest of the lifecycle, start with the IoT, digital twin and PLM overview.

A Reference Architecture for Part Classification PLM and Design Reuse

Part classification in PLM assigns every part to a class in a controlled hierarchy, and each class defines the typed attributes that describe its members. Combined with geometric shape search and a gate at part creation, classification lets engineers find reusable parts and stops near-duplicates before they receive a part number.

Figure 1: Reference architecture for classification-driven design reuse at the point of part creation.

The flow starts when an engineer requests a part. The request form asks for a class first, then shows only that class’s attributes. A classification service proposes the class, an attribute normaliser converts units and value lists, and the reuse engine queries three independent signals: attribute match, shape similarity and text match. A fusion step scores candidates, and the decision either redirects the engineer to an existing part or releases a new number after librarian approval.

Classification is a schema problem before it is a search problem

A class hierarchy does two jobs that pull against each other. Navigation wants a shallow, intuitive tree that an engineer can browse in three clicks. Matching wants narrow leaf classes whose members share a precise attribute set, because comparison is only meaningful between parts described by the same properties. A “fastener” class with twenty optional attributes cannot detect duplicates; a “hex head cap screw, metric” class with thread size, length, property class, material and finish can.

The resolution is to separate the browse tree from the attribute-bearing leaf. Keep the visible hierarchy to four or five levels, and put the attribute definitions at the leaf, with inheritance for genuinely shared properties such as material or RoHS status. This mirrors how ECLASS works: its four levels are segment, main group, group and subgroup, and the property lists sit at the subgroup level.

Each leaf class needs a short list of mandatory, matching-relevant attributes. In practice five to twelve attributes carry the identity of a part; the rest are descriptive. Mark the identity attributes explicitly, because the duplicate detector will compare only those. A mandatory attribute that does not affect fit, form or function becomes friction that engineers fill with junk.

Standard dictionaries solve the hardest part of attribute design: unambiguous property definitions with data types and units. The ECLASS property model gives every property an IRDI (International Registration Data Identifier), a preferred name, a definition and a data type such as REAL_MEASURE, INTEGER_COUNT or STRING. Only the measure types carry a unit, and units that measure the same quantity are convertible. Value-list properties are strings whose allowed values each carry translations.

The IEC Common Data Dictionary (IEC CDD), the database published as IEC 61360-4, uses the same family of concepts. Its data model is defined in IEC 61360-2, aligned with ISO 13584-42, and maintained by IEC SC 3D with ISO TC 184/SC 4. It identifies classes, properties and units by IRDI following ISO/IEC 11179; a unit example is 0112/2///62720#UAA609. Domains include process automation equipment under IEC 61987 and low-voltage switchgear under IEC 62683.

The practical rule is to reference standard property IRDIs wherever a property already exists, and to keep your own class hierarchy. Your navigation tree reflects how your engineers think and what your products contain. A standard tree is designed for cross-industry trade and will feel foreign. Property-level alignment gives you interoperability at export time without forcing an alien taxonomy on daily users.

The reuse engine needs three signals, not one

Attribute matching, shape similarity and text matching fail in different ways, which is why combining them works. Attribute matching is precise but brittle: it misses duplicates whose attributes are missing or entered in the wrong unit. Shape similarity catches geometric twins with different names and incomplete metadata, but it cannot see material, finish or tolerances. Text matching across names, descriptions and specification references catches legacy parts that have no geometry.

Independent signals compound. Suppose, purely as an illustration, each signal alone catches 60 percent of true duplicates and their misses were independent. The chance all three miss a duplicate would be 0.4 cubed, about 6 percent, so recall would approach 94 percent. Real misses are correlated, since a badly described legacy part tends to fail several signals at once, so expect less. The direction still holds: fusion beats any single detector.

Classification Schemas Compared: In-house, ECLASS, IEC CDD and UNSPSC

The schema choice decides what matching is possible later, so it deserves a deliberate decision rather than whatever the PLM installer shipped. There are four realistic starting points, and most mature organisations end up with a hybrid.

ECLASS classification in practice

ECLASS is maintained by ECLASS e.V., an association founded in 2000 by German industrial companies. It describes itself as an ISO/IEC-compliant data standard for products and services and is developed in line with ISO 8000-110. According to the ECLASS release pages, Release 15.0 was published on 29 November 2024 and added about 490 classes and roughly 810 properties versus 14.0. Release 16.0 followed on 28 November 2025 with 995 new classes, 1,253 new properties and 126 new value lists, available in 31 languages. Public summaries put the overall size at around 50,000 classes and 23,000 properties.

Two features matter most for PLM. First, IRDIs make properties machine-referable across companies, so a supplier’s datasheet value and your internal attribute can be joined without string matching. ECLASS IRDIs follow the pattern supplier, type of structural element, identifier and version, where the type code distinguishes classes from properties. Second, ECLASS is a primary vocabulary for the Asset Administration Shell; the “Technical Data” submodel template can carry ECLASS Basic and ECLASS Advanced descriptions side by side. If your products ship with digital nameplates or product passports, ECLASS alignment pays twice.

The cost is licensing, release management and fit. ECLASS is distributed under licence, and a yearly major release means mappings must be versioned. Its classes reflect trade categories, so an engineered, make-to-print bracket often lands in a generic group with weak properties.

IEC CDD and UNSPSC

The IEC CDD is free to browse online and strongest for electrotechnical and process-automation domains. If you build instrumentation, switchgear or electronic assemblies, its property definitions are often more rigorous than any in-house equivalent. Content enters through change requests, which the CDD documentation says typically reach the database within about six months.

UNSPSC, the United Nations Standard Products and Services Code, is a different animal. It is a spend classification with four levels of two digits each: segment, family, class and commodity. Version 26.0801, released in August 2023, contains about 158,000 items, and the United Nations Development Programme has managed it since 1 January 2025. UNSPSC has no attribute model, so it cannot drive duplicate detection. It belongs on the part master as a procurement mapping for spend analytics, not as the engineering schema.

Decision matrix

Criterion	In-house schema	ECLASS	IEC CDD	UNSPSC
Typed attributes with units	Whatever you design	Yes, IRDI properties	Yes, IRDI properties	No
Fit for engineered make-to-print parts	Best	Moderate	Moderate in its domains	Poor
Fit for purchased catalogue parts	Weak	Strong	Strong for electrotechnical	Spend level only
AAS and digital passport interoperability	Needs mapping	Native	Native	None
Cost	Internal effort	Licence plus release work	Free to use online	Free code set
Change control	You decide	Annual major release	Change requests	Periodic versions

The pattern that survives contact with reality is a hybrid. Own the browse hierarchy and leaf classes. Bind each identity attribute to an ECLASS or CDD property IRDI when one fits. Store a UNSPSC commodity mapping per class for procurement. Version every external mapping against the release it came from.

Part numbering: intelligent versus non-intelligent

Classification is often confused with part numbering, and the confusion causes real harm. An intelligent part number encodes meaning, for example a prefix for the commodity, digits for size and a suffix for finish. It feels efficient because a machinist can read it. It fails because the encoded facts change, the code space for a segment runs out, and engineers start choosing numbers that “look right” rather than searching.

A non-intelligent number is a sequential or random identifier with no meaning. All descriptive information lives in classification attributes, where it can be typed, searched and changed without renumbering. Arena’s white paper on part numbering lays out both schemes and concludes that each has advantages and disadvantages; for organisations that want reuse, the balance tips toward non-intelligent numbers. The pragmatic exception is a short, stable prefix that marks broad type, such as purchased versus manufactured, because that rarely changes.

The rule for reuse is simple. The part number identifies; the classification describes. If your part number is doing the classification’s job, duplicates hide behind number formats instead of being caught by attribute comparison.

Walk-through: Data Model, Matching Pipeline and a Worked Example

The data model

Figure 2: Minimal data model for classification, normalised attributes, shape signatures and external dictionary mappings.

The model separates three concerns. The dictionary side holds classes, a self-referencing parent link, class-property bindings with a mandatory flag, and properties carrying an IRDI, data type and unit, plus value lists. The instance side holds the part master with a non-intelligent part number and a classification record that names the class and the dictionary version. Attribute values point at properties and are stored normalised to SI alongside the original entry.

Two details prevent pain later. First, version the classification record, not just the part. When a class is split, you need to know which version of the schema classified each part, so reclassification can be audited. Second, keep the shape signature as its own entity keyed by the CAD revision. Geometry changes on revision, and stale signatures are a silent source of false matches. Our post on migrating legacy PLM data to cloud PLM covers how to carry classification data and its history through a cutover.

The matching pipeline

Figure 3: Duplicate detection pipeline with blocking, attribute similarity, geometric filtering, embedding search and weighted fusion.

Blocking comes first. Comparing a candidate against every part in a 400,000-item master is wasteful and noisy, so restrict comparison to the candidate’s class and its siblings. Sibling inclusion matters because misclassification is common, and a duplicate filed one class over is still a duplicate.

Attribute similarity compares identity attributes only. Numeric attributes use tolerance bands rather than equality: a 3.0 mm thickness and a 3.05 mm thickness are the same sheet gauge for most purposes. Value-list attributes compare exactly, with a synonym table for legacy values. Missing attributes count as unknown, not as mismatches, and the score is computed over attributes present on both parts, with a penalty when coverage is low.

The geometry pipeline runs in two stages. Cheap invariants such as volume, surface area, sorted bounding-box dimensions and hole count filter out obvious non-matches. A learned embedding then ranks what remains. Classical descriptors such as the D2 shape distribution of Osada and colleagues, which histograms distances between random surface points, still work as a robust baseline. Newer encoders operate on the boundary representation directly. UV-Net, presented at CVPR 2021 by Autodesk Research, samples U and V parameter grids on faces and edges and combines image-style convolutions with graph convolutions over face adjacency. B-rep encoders see holes, fillets and planar faces as engineers do, which point-cloud models only approximate.

Embeddings go into an approximate nearest neighbour (ANN) index. The arithmetic is modest: a 256-dimension float32 vector is 1 KB, so 400,000 parts need about 400 MB of raw vectors. An HNSW index fits on one ordinary server. If you already run vector search, the guidance in our post on filtered vector search with metadata pre-filtering applies directly, because class blocking is a metadata filter.

Fusing the scores

The fusion step turns three scores into one ranked list with evidence. A weighted average is the right starting point because it is explainable to a librarian. The sketch below is illustrative; the weights and tolerances must be calibrated on your own labelled pairs.

from dataclasses import dataclass

@dataclass
class Prop:
    irdi: str          # e.g. an ECLASS or IEC CDD property IRDI
    kind: str          # "measure" or "enum"
    tol_rel: float = 0.0
    weight: float = 1.0

def attr_similarity(cand: dict, other: dict, props: list[Prop]) -> tuple[float, float]:
    """Return (similarity, coverage) over identity attributes present on both parts."""
    num = den = 0.0
    present = 0
    for p in props:
        a, b = cand.get(p.irdi), other.get(p.irdi)
        if a is None or b is None:
            continue                      # unknown, not a mismatch
        present += 1
        if p.kind == "measure":           # values already normalised to SI
            ref = max(abs(a), abs(b), 1e-9)
            ok = abs(a - b) / ref <= p.tol_rel
        else:
            ok = a == b
        num += p.weight * (1.0 if ok else 0.0)
        den += p.weight
    coverage = present / len(props) if props else 0.0
    return (num / den if den else 0.0), coverage

def fused_score(attr: float, coverage: float, geom: float, text: float,
                w=(0.5, 0.35, 0.15), min_cov=0.5) -> float:
    w_a, w_g, w_t = w
    if coverage < min_cov:                # weak metadata: lean on geometry
        w_a, w_g = w_a * coverage, w_g + w_a * (1 - coverage)
    return (w_a * attr + w_g * geom + w_t * text) / (w_a + w_g + w_t)

Three choices in that sketch are deliberate. Missing values are skipped rather than scored as mismatches, so sparse legacy records are not unfairly excluded. Low attribute coverage shifts weight to geometry, because a part without metadata can still be a geometric twin. And the score stays in the 0 to 1 range, which makes thresholds legible to the people who own the gate.

Worked example: one bracket request

Consider an illustrative mid-size equipment maker. The part master holds 400,000 items, and engineering requests about 600 new part numbers a week. An engineer requests a formed steel bracket: class “sheet metal bracket, formed”, material S235, thickness 3.0 mm, flat pattern 120 by 80 mm, four holes of 6.6 mm, zinc plated.

Blocking narrows the field to the bracket class and two siblings, about 2,300 parts. Geometric invariants drop that to 140 parts whose sorted bounding boxes are within 10 percent and whose hole counts match. The B-rep embedding search returns the top 50 by cosine similarity. Fusion produces three candidates above 0.75. The best scores 0.91: identical material and finish, thickness 3.0 mm, flat pattern 120 by 82 mm, holes 6.6 mm, geometry similarity 0.95. The engineer checks the mating interface, accepts it, and the PLM records a new where-used link instead of a new part.

Now scale it. Suppose, as an illustration, 8 percent of requests turn out to have a usable existing match and half of those engineers accept. That is 24 avoided parts a week, roughly 1,200 a year. At the Defense Standardization Program’s $20,000 life-cycle estimate this is $24 million of cost avoidance; at a deliberately conservative $2,000 internal figure it is still $2.4 million. These numbers are illustrative and the inputs are assumptions. The point is that even pessimistic inputs dwarf the cost of a vector index and a part librarian.

Reviewer load is the binding constraint. If 15 percent of requests trip a match above 0.75, the librarian queue receives about 90 items a week, or 18 per working day. At five minutes each that is 1.5 hours daily, which one person can absorb. If the threshold drops to 0.6 and the flag rate climbs to 40 percent, the queue becomes 240 items a week and the gate turns into a bottleneck. Threshold tuning is therefore a capacity decision as much as a precision decision.

Calibrating thresholds

Calibrate on labelled pairs, not intuition. Sample a few hundred candidate pairs across score bands, have two experienced engineers label each as “interchangeable”, “similar but not interchangeable” or “different”, and plot precision against the fused score. Agreement between the two labellers is itself informative: if they disagree on 20 percent of pairs, no algorithm will exceed that ceiling, and your class definitions are probably ambiguous.

A three-band policy works in most organisations. Above an upper threshold, show the match prominently and require a reason code to proceed. Between the lower and upper thresholds, show matches as suggestions. Below the lower threshold, stay silent. Silence matters, because a gate that always shows low-quality matches trains engineers to click past it.

ML-Assisted Classification and Legacy Clean-up

Classification fails at the start of the workflow when engineers pick the wrong class or a vague parent. Machine learning helps in two places: suggesting a class for new parts and reclassifying the legacy backlog.

Class suggestion at creation

A class suggester takes whatever the engineer has provided, typically a draft name, a CAD model and sometimes a material, and returns the top three classes with confidence. Text classifiers work well on names and descriptions; geometry encoders work well when the model exists. A late-fusion approach, averaging calibrated probabilities from both, is simple and robust. Showing three options instead of one keeps the engineer in control and produces a useful training signal: which suggestion they picked.

The target is not full automation. A suggester that is right in the top three most of the time cuts the cognitive cost of a deep hierarchy without hiding it. Measure top-1 and top-3 accuracy on a held-out set before launch, and track the rate at which engineers override suggestions in production, segmented by class.

Reclassifying the legacy backlog

The larger prize is usually the legacy master. Many companies have hundreds of thousands of parts filed under “miscellaneous” or a generic parent, with attributes trapped in free-text descriptions such as “BRKT STL 3MM ZN 4X6.6”. Extracting structured attributes from those strings is a sequence-labelling problem that large language models now handle well with a constrained output schema, provided every extracted value is validated against the class’s data types and value lists.

Run the clean-up as a batch pipeline with human review sampling. Our post on RAG over CAD and BOM data for PLM knowledge retrieval covers the retrieval side of that work. Prioritise by business value: high-spend purchased parts, parts with active compliance exposure, and parts on live BOMs first. A part that has not been used in ten years can wait, and may be a candidate for obsolescence instead.

Clustering the legacy master is the fastest way to size the duplicate problem. Run the same matching pipeline in all-pairs mode within each class, cluster pairs above the upper threshold, and count clusters with more than one member. That count, multiplied by your internal cost figure for maintaining an active part, is the business case.

Governance: Putting the Gate at Part Creation

Search tools that engineers must remember to use deliver little. The control point that works is the part number request itself, because every new part passes through it exactly once. Moving duplicate prevention into that workflow converts reuse from a good intention into a default.

Figure 4: Governance workflow at part creation, with scored matches, reason codes and librarian review.

The sequence is short by design. The engineer requests a part with a class and attributes. The PLM part service calls the reuse engine, which returns a shortlist with scores and evidence. Matches above the lower threshold are shown to the engineer. If the engineer rejects them, they choose a reason code, and the request routes to a part librarian, who either approves the new number or redirects to reuse.

Reason codes are the feedback loop

Reason codes turn rejections into data. A useful starter set is: different material or finish, different tolerance or critical dimension, different supplier qualification, customer-specified part, and “match was not actually similar”. The last code is a direct false-positive signal for tuning weights. The others reveal attributes that should be identity attributes but are not yet in the schema.

Review reason codes monthly by class. If “different tolerance” dominates a class, add the governing tolerance as an identity attribute. If “not actually similar” dominates, the geometry weight for that class is too high or its embedding is poorly trained on that shape family.

Where the librarian fits

A part librarian, sometimes called a component engineer or data steward, owns the schema and the queue. The role is not a rubber stamp. Librarians approve new classes, maintain value lists, merge duplicates found in the backlog and decide when a near-match should become a preferred part. In smaller organisations it is a part-time role per commodity; in larger ones it is a small team.

Duplicate merging deserves care because it is an engineering change. Retiring a duplicate means updating every BOM where it is used, which runs through the formal change process; see our guide to engineering change management with ECR, ECO and effectivity. Mark the retired part “do not use for new design” immediately, and let existing BOMs migrate on their natural change cadence unless there is a supply or compliance reason to force it.

Preferred parts and the reuse ranking

Not every existing part is equally good to reuse. A preferred-part flag, maintained by the librarian, marks parts with healthy supply, active qualification and good cost. The reuse engine should boost preferred parts in ranking and demote parts flagged obsolete or at end of life. Our post on component obsolescence management and BOM health covers how those lifecycle signals are computed.

Classification attributes also feed sustainability reporting. Material, mass and process attributes on a well-classified part are the inputs that a footprint roll-up needs, which is why consistent classification shortens the work described in our post on product carbon footprint exchange and PCF roll-ups through the BOM. Reuse reduces the number of distinct parts whose footprint must be sourced from suppliers.

Trade-offs, Gotchas, and What Goes Wrong

Schema bloat. Teams add mandatory attributes until creating a part takes twenty minutes. Engineers respond with placeholder values such as zero or “TBD”, which poison attribute matching. Keep mandatory attributes to identity attributes and enforce value ranges, so a 0 mm thickness is rejected rather than stored.

Geometric twins that are not interchangeable. Two brackets can be identical in shape and differ in material, heat treatment or a critical tolerance shown only on the drawing. Shape similarity alone will rate them as duplicates. This is why geometry must never auto-merge and why material and finish belong in the identity attribute set. Product and manufacturing information (PMI) on the model can close part of the gap if your CAD practice captures it.

Mirror and scale ambiguity. Many shape descriptors are invariant to reflection and some to scale. Left-hand and right-hand parts then look identical, and a 10 mm and 12 mm version of the same spacer may match. Add explicit handedness and characteristic-dimension checks after the embedding stage.

Stale signatures. If shape signatures are not recomputed on CAD revision, the index compares against old geometry. Tie signature generation to the release event and store the CAD revision with the vector.

Class drift across schema versions. Splitting a class without migrating its members leaves parts in a parent class with no identity attributes, invisible to matching. Treat class changes as schema migrations with a reclassification job and an audit trail.

External release churn. ECLASS publishes a major release yearly, and property definitions can be deprecated. Store the dictionary release with every mapping and plan a yearly mapping review rather than silent upgrades.

Gate fatigue. A gate that flags half of all requests will be bypassed by escalation or by creating parts under a different class. Track the flag rate and the acceptance rate together. A falling acceptance rate with a stable flag rate means the matches are getting worse.

Metrics that reward the wrong thing. Counting “duplicates prevented” invites gaming, since any rejected suggestion can be recounted as prevention. Measure new part creation rate per project and reuse ratio on new BOMs instead.

Practical Recommendations

Start with measurement, not software. Run the matching pipeline in batch mode on your existing master, cluster likely duplicates, and price the result with an internal cost-per-part figure your finance team agrees with. That single number decides whether the programme gets a librarian and a gate, and it gives you labelled examples for calibration.

Then fix the schema for the classes that matter. Pick the ten classes with the most parts or the most spend, define five to twelve identity attributes each, and bind those attributes to ECLASS or IEC CDD property IRDIs where they exist. Leave the long tail of classes for later. Adopt non-intelligent part numbers for new parts if you have not already.

Only then build the gate. Put the reuse engine inside the part request workflow, start with conservative thresholds, require reason codes and staff the queue. Revisit weights and thresholds every quarter using reason-code data, and expand class coverage as each class proves itself.

Price a new part with an internal, finance-approved figure; cite public estimates only as context.
Separate the browse hierarchy from attribute-bearing leaf classes.
Mark identity attributes explicitly and keep them to five to twelve per class.
Bind attributes to ECLASS or IEC CDD IRDIs and version every external mapping.
Store attributes normalised to SI alongside the original entry.
Combine attribute, shape and text signals; never auto-merge on geometry alone.
Recompute shape signatures on every CAD release.
Calibrate thresholds on labelled pairs and size them to reviewer capacity.
Require reason codes for rejected matches and review them monthly.
Track new part creation rate and reuse ratio, not “duplicates prevented”.

Frequently Asked Questions

What is part classification in PLM?

Part classification in PLM is the practice of assigning every part to a class in a controlled hierarchy, where each class defines typed attributes such as dimensions, material and finish. The classification lets engineers search by meaning rather than by part number or free text, enables comparison between parts described by the same properties, and supplies structured data to procurement, compliance and sustainability processes. Modern implementations bind class attributes to standard dictionaries such as ECLASS or the IEC Common Data Dictionary so that values can be exchanged with suppliers and customers.

What is the difference between ECLASS and UNSPSC?

ECLASS is a product description standard with classes and typed properties identified by IRDIs, which makes it suitable for describing parts and exchanging technical data, including within the Asset Administration Shell. UNSPSC is a spend classification with four levels of two-digit codes and no attribute model, used mainly for procurement analytics. A PLM system can use both: ECLASS or IEC CDD properties for engineering attributes, and a UNSPSC commodity code mapped per class so purchasing can analyse spend across categories without changing the engineering schema.

How do you prevent duplicate parts in PLM?

Put a reuse check inside the part number request so every new part is compared with existing parts before it gets a number. Restrict the comparison to the requested class and its siblings, score attribute similarity with tolerance bands, add geometric shape similarity and text matching, and fuse the scores. Show strong matches to the engineer, require a reason code to proceed, and route those requests to a part librarian. Calibrate thresholds on labelled pairs and size them to the reviewers’ capacity so the gate is not bypassed.

How does geometric shape search work for CAD parts?

Geometric shape search converts each CAD model into a compact signature and finds parts with similar signatures. Older approaches use descriptors such as shape distributions, which histogram distances between random surface points. Newer approaches train neural encoders on the boundary representation, so faces, edges and holes shape the embedding. The embeddings are stored in an approximate nearest neighbour index. A search usually filters first by class and simple invariants like bounding box and volume, then ranks the remaining candidates by embedding similarity.

Should part numbers be intelligent or non-intelligent?

For organisations that want reuse and scale, non-intelligent part numbers are usually the better choice. A sequential identifier never needs to change when part properties change, and it never runs out of code space within a category. Descriptive information belongs in classification attributes, where it can be typed, validated and searched. Intelligent numbers remain popular because they are readable on the shop floor, but they encourage engineers to pick numbers that look right rather than searching. A short stable prefix for broad type is a reasonable compromise.

How much does it cost to create a new part number?

Public estimates vary widely. A US Defense Standardization Program business case estimates about $20,000 in life-cycle cost to add a new part, covering engineering, testing, purchasing, storage, inventory and logistics support, while PTC’s reuse material uses about $5,000 per part per lifecycle phase. Your own figure depends on industry, regulation and how many systems a part touches. Build an internal estimate from activity costs with your finance team, because an agreed internal number is far more persuasive than an industry average.

References

ECLASS e.V., “ECLASS Releases” and “Release 15.0” information pages: https://eclass.eu/en/eclass-standard/releases and https://eclass.eu/support/content-creation/release-process/information-on-releases/release-150
ECLASS e.V., technical specification, “Property” structure and data types: https://eclass.eu/support/technical-specification/structure-and-elements/property
IEC Common Data Dictionary (IEC 61360-4 DB): https://cdd.iec.ch/ and overview at https://en.wikipedia.org/wiki/IEC_Common_Data_Dictionary
UNSPSC overview, versions and governance: https://en.wikipedia.org/wiki/UNSPSC
Defense Standardization Program, Parts Standardization and Management Committee, “Reduce Cost Through Parts Standardization and Management” business case: https://www.dsp.dla.mil/Portals/26/Documents/Programs/PartsManagement/070524-Report-ReduceCostThroughPSCMBusinessCasePartsManagement.pdf
PTC, “Saving Millions on Reuse” infographic: https://ptc.com/en/resources/plm/infographic/save-millions-on-reuse-quantify-lifetime-of-a-part
Siemens, “How Geolus 3D shape search drives part re-use”: https://blogs.sw.siemens.com/teamcenter/how-geolus-3d-shape-search-drives-part-re-use/
Jayaraman et al., “UV-Net: Learning From Boundary Representations”, CVPR 2021: https://openaccess.thecvf.com/content/CVPR2021/html/Jayaraman_UV-Net_Learning_From_Boundary_Representations_CVPR_2021_paper.html
Osada, Funkhouser, Chazelle and Dobkin, “Shape Distributions”, ACM Transactions on Graphics, 2002.
Arena Solutions, “Is Your Part Numbering Scheme Costing You Millions?”: https://www.arenasolutions.com/white-papers/part-numbering-scheme/

By Riju — about