4/20/2021 3 Master Model Concept Misconceptions – The PLM Dojo

≡ Menu

Resources…
Teamcenter Glossary
What’s a Business Object?
Revision Rules Illustrated
Popular Posts
Archives
About…
About Scott
About “PLM Dojo”
Disclaimers
Colophon
Contact…
Newsletter Signup

The PLM Dojo Get the Newsletter!

Be a Teamcenter PLM Samurai

3 Master Model Concept Misconceptions

by Scott
in Data Model
Share the knowledge
Like 4

236

If you’re around NX for very long you’ll hear someone talk about the Master Model concept. It is an
important concept. It comes up in the various forums from time to time. Usually when people as, “What is
the master model concept?” There are no shortage of answers offered. But I feel that most of the discussions
miss the mark. I think there are a lot of misconceptions about the Master Model Concept. I am going to try to
clear some of them up.

Master Model Definition

If I’m going to discuss what people get wrong about the Master Model Concept, I should at least try to
provide a definition of what it is. Here is how I define it

Master Model Concept:

A method of separating a CAD model definition from data which is dependent upon the CAD model but
does not define the CAD model itself. This separation is achieved by storing the CAD model definition,
called a Master Model, within one file and each piece of dependent data within separate files which refer to
the Master Model, typically by including it as a component within themselves. Typical examples of
dependent data types are drawings, machining tool path definitions, and FEA analyses.

Now, on to the misconceptions.

Master Model Misconceptions

plmdojo.com/datamodel/master-model-concept-misconceptions/#.YHwwjegzaUm 1/9
4/20/2021 3 Master Model Concept Misconceptions – The PLM Dojo

These are the misconceptions that I feel people have.

1. The Master Model Concept is Only for Drawings

Drawings are the first place most of us encounter the MMC. Unfortunatley many people think this is all the
MMC is about. In the early days of Unigraphics, there was but one file, and it contained your geometry and
your drawing. Then UG gave us the ability to create assemblies. Soon someone figured out that you could
the geometry in one file and the drawing in another. And then the word spread that drawings did not have to
be embedded into the same file as the model.

But that’s not the only thing you can do use MMC for. You can have a separate file for your manufacturing
tool path information too. And another file for your FEA analyses. Any type of work you need to do that is
driven by the model but does not influence the model can (and should!) be broken out into a separate file that
references the master model.

2. The Master Model Concept is about reducing file sizes

The second misconception I hear is that the main benefit of MMC is that it reduces your file sizes. Drawings
and tool paths and FEA meshes can be consume a lot disk space, so by separating them out from the model
file you make your models easier to work with.

That is a benefit. I agree with that.

I just don’t think it’s the primary benefit.

I think the primary benefit is that MMC decouples your model file from your drawings, machining files, and
analysis models. “Decoupling” is a word that is used in software engineering fairl regularly. However, if it’s
used in terms of CAD modeling, I’ve not heard it. Decoupling means to take a system and divide it into
logical self-contained units which share only what they need to share with each other through well defined
channels. For example, drawings do not need to know the model tree for the geometry. It makes no
difference if that hole was created with a feature or by extruding a sketch. All the drawing needs to see are
the faces and the edges. Likewise, the model does not need to know that the drawing even exists.

So here’s another point about MMC:

The flow of information in MMC is from the master model and to the dependent files.

So, why is this A Good Thing?

Protecting model integrity

No, I’m not talking about protecting the reputations of Victoria’s Secret models. I mean that there is nothing
you can do to the drawing, tool paths, or FEA analyses that will damage the master model.

If you had everything in one file, could you be sure that you wouldn’t inadvertently make an unintended
change to the model when you were only supposed to be updating the drawing?

Parallel work efforts

A second benefit of decoupling the model from the dependent files is that you can now divide the work effort
into parallel tracks. One person can be working the model while another starts on the drawing and a third
begins to prepare the tool paths.

Separate life cycles

plmdojo.com/datamodel/master-model-concept-misconceptions/#.YHwwjegzaUm 2/9
4/20/2021 3 Master Model Concept Misconceptions – The PLM Dojo

Since the model and drawing and machining and analysis files are separate they can be submitted to different
workflows for review and release. The engineering group can review the model, the drafting group can
review the drawing, manufacturing, the tool paths, etc.

Independent changes
The different files can be revised independently. A change to a note on the drawing does not require the
model to be changed. Nor does a new analyses. And changes to the model that do not affect the other files do
not require them to be updated. For example, there’s no reason to update a tool path because someone added
a new reference set to the model.

3. In Teamcenter the Dependent Models Must be Manifestations

The “standard” implementation of Teamcenter puts the master model in a UGMASTER dataset that is
attached to a item revision with a Specification relationship. Then, additional datasets for the other models,
like the drawing, are put in UGPART datasets that are attached to the same item revision but with a
Manifestation relationship. Some people seem to think that this is what MMC has to look like in Teamcenter.
But there are other solutions. For example, the drawing could be in its own item revision under a different
item. For more on this topic, see this post on different ways of storing drawings in Teamcenter

Closing Thoughts
History?
If anyone knows the history of who first came up with the master model concept, please share. (Paging John
Baker…)

Be Consistent
I endorse using the MMC for all files. I know that some people feel that for really simple models that the
drawing should be embedded in the model file. Personally, I feel it’s better to just consistently use one
approach. If you’re going to use MMC in some cases (and you should), just use it in all cases.

Watch out for the WAVE

Interpart relationships, particularly WAVE relations, can turn the MMC upside down. Watch out for any
relationship that makes a master model dependent on something that happens in the derivative file(s).

More?
Have I missed any misconceptions? Do you disagree with my choices? Leave a comment, below.

Was this useful?

If so, please share, and endorse (+1, Like, etc.) on your social network of choice.
If you feel I’m mistaken about or missing something, pleas share your thoughts in the comments.
Thanks!

Like 4

236

plmdojo.com/datamodel/master-model-concept-misconceptions/#.YHwwjegzaUm 3/9
4/20/2021 3 Master Model Concept Misconceptions – The PLM Dojo
ALSO ON THE PLM DOJO

Killing Memory Errors A Sneak Peak at A Trick for U

with the STL – The … Multifield Keys in … Precise Asse
8 years ago • 15 comments 8 years ago • 10 comments 8 years ago • 24

Pull up a chair and let me As I’ve mentioned before, There are times
tell you a story from my Multi-key identifiers in precise assemb
early days as a … Teamcenter was a … is incorrect; the

15 Comments The PLM Dojo 🔒 Privacy Policy 

1 Login

 Recommend 2 t Tweet f Share Sort by Newest

Join the discussion…

LOG IN WITH
OR SIGN UP WITH DISQUS ?

Name

FSFarimani • 8 months ago

Thanks for the nice piece. I Twitted it here

t
. just two points:

- Instead of the term "decoupling" I would use the term

"modularization" or at least would add it.
- And in the "Parallel work efforts" section I would refer to the
"concurrent engineering" methodology.
△ ▽ • Reply • Share ›

Dustin Neifer • 8 years ago

I still find the default NX dataset type naming in TcUA to be
confusing:

UGMASTER = assembly model *or* part model

UGPART = drawing

A part is a drawing? OK ...

1△ ▽ • Reply • Share ›

Teamcenter Heretic > Dustin Neifer • 8 years ago

plmdojo.com/datamodel/master-model-concept-misconceptions/#.YHwwjegzaUm 4/9
4/20/2021 3 Master Model Concept Misconceptions – The PLM Dojo
y g
Uh, what is this thing called UG? Is it related to iMAN?
△ ▽ • Reply • Share ›

FSFarimani > Teamcenter Heretic

• 8 months ago • edited
I think the UG comes from the UNIGRAPHICS legacy
△ ▽ • Reply • Share ›

Scott Pigman Mod > Dustin Neifer • 8 years ago

It's the result of having a single .prt file type all types of files. I
haven't heard of any other CAD programs that that use a
single file extension.

UGPART could be something other than than a drawing too.

And if you store drawings under their own, separate, items
then they'll be UGMASTERs too.

Not differentiating between assemblies or parts is a good

thing, IMHO. Too frequently designs start as one and then
evolve to the other.
△ ▽ • Reply • Share ›

Don Knab • 8 years ago

I think the whole implementation for MM in NX and TC is a little
kludged.

In NX there’s sort of a child/parent assembly relationship thing going

between models and drawings.
In TC they’ve hidden the assembly relationship (where used), and
then implemented another relationship to suffice.

I can see the TC developers when they had to implement it:

Developer#1 – OK folks, this is what they’ve given us. We need to
find a way to make “this” fit into the whole which “that” fits in, using
only “these” (Apollo 13).
△ ▽ • Reply • Share ›

Teamcenter Heretic • 8 years ago • edited

Manifestations are a kludge at best IMHO.

The fact that a manifestation does not get locked down is both a
blessing and a curse.
Just go find one of those really important released CAD models and
cut/delete the manifestation with those many man weeks of NC
programming it in... Viola!!

Also, where used does not report manifestations that reference their
master so if the relation gets cut you are hosed.
△ ▽ • Reply • Share ›

Randy Ellsworth • 8 years ago

plmdojo.com/datamodel/master-model-concept-misconceptions/#.YHwwjegzaUm 5/9
4/20/2021 3 Master Model Concept Misconceptions – The PLM Dojo
a dy s ot 8 yea s ago

Excellent article as always Scott.

To add a little to the "benefits" section. By creating a separate Mfg
Part (Item and Revision) for tool paths and using a manifestation
relation allows a Mfg Engr to regenerate those paths without
"revising" the model. This is needed if a tool wears down or is
replaced with a new tool. Since the Mfg Part doesn't affect the
geometry of the model (doesn't describe it) then there is no reason to
revise the model. By default, a manifestation isn't released, allowing
the dataset to be modified without revising.
A mistake some companies make is to add manifestation to the
release workflow which locks it down and prevents modification
without revising it first. Basically turning a manifestation into a
specification.
Best,
/Randy
△ ▽ • Reply • Share ›

Scott Pigman Mod > Randy Ellsworth • 8 years ago

Thank you for the insight about manifestations (and for the
compliment :-)

In your view, is there not a need to lock down the tool paths at
some point and control when and how they are updated, even
if they are updated separately from the master model &
revision? I'm imagining possibly having a workflow that only
accepted and statused UGPART datasets -- but then i don't
know how you'd "revise" just the dataset.(unstatus it and
create a new version?)

"Manifestations -- what are they good for?" might be a good

topic for a discussion.
△ ▽ • Reply • Share ›

Teamcenter Heretic • 8 years ago

IMHO, the only downside to the method where the drawing is a
single part assy of the model is that you have to fabricate some
stupid convention like 12345_DWG.
with the V10 concept of compound id that disadvantage goes away
and I cannot imagine why anyone running Nx (is there really any
other CAD system?) would want to stick with the
UGMASTER/UGPART method.

Even the Part/Design/Drawing scenario makes great sense in V10!!

Cant wait to use my ITK skillz to begin re-identifying all those legacy
items when V10 gets here ;) I love POM calls!!!!!
△ ▽ • Reply • Share ›

srinivasan r • 8 years ago • edited

Insightful ! Is the MMC applicable for Pro E and Catia models (or any
plmdojo.com/datamodel/master-model-concept-misconceptions/#.YHwwjegzaUm 6/9
4/20/2021 3 Master Model Concept Misconceptions – The PLM Dojo

other for that matter) as well?And how about the dependencies in the
case of MMC? Say a TC part has a model as well as drawing
attached with it..in such a case how is it possible to have
independent lifecycles for model and drawing(when both have the
same TC part)? FYI, i work in TC Enterprise.
△ ▽ • Reply • Share ›

Dustin Neifer > srinivasan r • 8 years ago

There is a "master model" concept for Pro/E (e.g. Creo)
however it’s not the same in nature as what is being
discussed here relative to NX. In Pro/E it is also described as
"top down design" and builds referential relationships between
separate files. Certain Pro/E functions are such as copy
geometry, envelopes, inheritance, publish geometry, etc. are
typically used in those cases.

Our practice is to keep MCAD drawings and the model they

depict in revision letter lockstep so the datasets are parked
under the same item revision. UGPART and UGMASTER,
ProDrw and ProAsm, ProDrw and ProPrt, etc.

I've never had the pleasure of having to deal with CATIA.

Sacré bleu!
△ ▽ • Reply • Share ›

Scott Pigman Mod > Dustin Neifer • 8 years ago

I think that the master model concept as NX uses it is
implicit in ProE's file types -- Your ProPrt or ProAsm
files would be the "master" file and then your ProDrw
would be the "manifestation" that refers back it.
△ ▽ • Reply • Share ›

Scott Pigman Mod > srinivasan r • 8 years ago • edited

Regarding Pro E and Catia, I have to qualify my reply since I

haven't worked with those systems, but from what I know or
think I know about them MMC is actually built into them
because they use different file types (extensions) for different
types of files, where as NX has only one, .prt.

As for the separate lifecycles question, I think you're

assuming a data model that looks like,

Item
- Item Revision
- Model Dataset
- Drawing Dataset

which would make it difficult to set up independent lifecycles

for the model and drawings. I would expect that instead you'd
have a data model that looks like this:

plmdojo.com/datamodel/master-model-concept-misconceptions/#.YHwwjegzaUm 7/9
4/20/2021 3 Master Model Concept Misconceptions – The PLM Dojo

Model Item
- Model Item Revision
- Model Dataset

Next post: Where Was The Dojo Last Week?

Previous post: 4 Steps to Follow When Updating Workflow Templates

Search the PLM web:

searches multiple PLM sites

Search

Recent Comments…

FSFarimani

3 Master Model Concept Misconceptions

Thanks for the nice piece. I Twitted it
August 12, 2020
FSFarimani

3 Master Model Concept Misconceptions

I think the UG comes from the UNIGRAPHICS...
August 12, 2020
Andre Röhr

Why You Should (or Shouldn’t) use Multiple BOMs

is it some person who knows to get the Part-structure information into NX-CAD. Workshop want to...
March 20, 2020
Mounika C

Critical Conditions
i want first revision to be created with "NR" and then 01 , 02..etc..can we define that using...
March 16, 2020
Karan Punjabi

Should You Use Master Forms or Properties for Metadata?

i recently noticed another objects getting created along with master and revision master forms when...
December 5, 2019
PLMLaundry

8 Questions to ask Before Starting a TC CAD Migration

You can also do this with migration utilities like tcxml import bulk load and IPS
May 3, 2019
PLMLaundry

How To Build a Compound Property to a Form Inside a Dataset

Thanks that was very informative (and fun!)
April 24, 2019
PLMLaundry

What Skills Does a Teamcenter administrator need?

The final advice is killer
April 23, 2019
shobana

plmdojo.com/datamodel/master-model-concept-misconceptions/#.YHwwjegzaUm 8/9
4/20/2021 3 Master Model Concept Misconceptions – The PLM Dojo

10 Teamcenter Preferences You Should Know

1) How to apply a column configuration for specific business object type? 2) How to apply column...
April 3, 2019
Hvv Lbz

How To Use Naming Rules

Hi I'm new to this site. I work in a big company. and I must use tc as configured in company. My...
January 9, 2019

Content and design © Scott Pigman 2014. Born of Insomnia. Built on Wordpress with the help of various
tools.

Optimization WordPress Plugins & Solutions by W3 EDGE

Recommended for you

Using Python to Unit Test 10 Teamcenter Preferences Displaying LOV

NX Open (or ITK) C Code - You Should Know | The Descriptions along with
The PLM Dojo PLM Dojo LOV Values - The PLM...
plmdojo.com plmdojo.com plmdojo.com

AddThis

plmdojo.com/datamodel/master-model-concept-misconceptions/#.YHwwjegzaUm 9/9