If you’re using Teamcenter to store your CAD models and drawings (and most Teamcenter customers are, I believe) then one of the first issues to tackle is, how do you store those drawings? There are a few different ways I’ve seen: embedded in the CAD model dataset itself, stored as an additional dataset under the same item revision as the CAD model, and stored as a separate item from the model item. Today I’ll run through some of the issues related to each of these approaches.

Things to Consider

This is surely not an exhaustive list, but here are some things to consider when deciding how to store your drawings in relation to your models.

1. Parallel work effortCan one person work on the model while another is working on the drawing, or can only one be worked on at a time? Being able to work on both concurrently is usually seen as a benefit.
2. Separate review processesDo you want to have one workflow for reviewing the drawing and another for reviewing the model, or will you always review both together?
3. Revision independenceDo you want to be able to revise the drawing and model independently, or will revisions always be synchronized? Some companies always revise the drawing if the part changes, and revise the part if the drawing changes. Others do not synchronize revisions. For example, changing a note on the drawing may not require an update to the part, while changes to the part that do not affect the drawing, such as changes to layer assignments or reference sets, do not require a drawing update.
4. Mono-detail or Multi-detail?Many companies only detail one part number per drawing. Others, particularly in the Aerospace industry, detail multiple part numbers per drawing. Typically the Drawing carries a core defining document number and each detail part defined by the drawing has a part number that contains the core document number and as suffix, such as -101, -102, etc. Which model applies for you?
5. Your CAD software and its integration to TeamcenterDifferent CAD packages and their Teamcenter integrations may force you into one model over another. My personal hands-on experience is almost entirely with NX. I believe that most everything I say here, except when noted otherwise, is applicable to other CAD systems but simply put, I do not know what I don’t know. If anyone knows of a case where a particular CAD integration requires one configuration over one of the others, I’d love to hear about it.

How to Store Drawings (Pick One)

Here are some of the ways I’ve seen for storing models and drawings in Teamcenter:

Drawing Embedded In the Model

Okay, I haven’t actually seen anyone do this in Teamcenter, but it used to be the standard way that drawings were stored in Unigraphics files.

For those of you who use other CAD systems and aren’t familiar with Unigraphics/NX, here’s a little background to put this in context — and for those of you who only know UG/NX, it’s helpful to understand where your non-NX colleagues are coming from so you may want to pay attention too. Unlike many (most? all?) other 3D Mechanical CAD applications NX only has one standard file type that it uses for piece parts, assemblies, drawings, library templates, and probably a couple other types of files I’m forgetting. All those file types are stored with the same .prt file extension. Autodesk Inventor, Solidworks, Pro-Engineer, etc. all have different file types (i.e., extensions) for these different types of files; they simply won’t let you put a drawing inside of a model file, or vice-versa. It’s just not how they work. However, for NX it used to be that the only way to store a drawing of a CAD model was inside the CAD model itself so that the model and drawing would be bundled together. Like I said, I haven’t personally seen this done in Teamcenter, but it’s possible, particularly when you’re working with old legacy data that’s been migrated into Teamcenter.

Pros

1. If you’re working with Legacy CAD data that was done this way, you may have to use this approach. I’d spend some time looking for tools to separate the data into two files though.
2. I’m thinking… Gimme a minute…

Cons

1. You cannot work on the model and drawing at the same time because they’re both in the same file.

 

1. You cannot review the model and drawing in different workflows because they’re both in the same file

 

1. You cannot have independent revisions of the model and drawing because… oh, heck. You get the picture by now.

 

1. You can’t have multi-detail drawings. I think you know why.

Introducing the Master Model Concept

Eventually Unigraphics began supporting assemblies and someone figured out the “Master-Model” concept for models and drawings. The concept is pretty simple: the model and drawing are two separate files and the drawing is an assembly which contains the model as its component.

Except for the fact that the drawing is also technically an assembly, this is pretty similar to how other CAD tools work that have separate extensions for models and drawings. the Master Model technique is pretty much the standard way or relating NX CAD drawings to NX CAD models. The question then is, how to store both the model and drawing files in Teamcenter?

Master-Model using Manifestations

The default approach Teamcenter uses is to put both datasets under the same item revision. The model is stored in a UGMASTER dataset and associated with the revision with a Specification relationship and the drawing is stored in a UGPART dataset that’s related to the revision with a Manifestation relationship. Other CAD tools will use their own dataset types and possibly their own relationship types, but otherwise it should be the basically the same sort of setup.

Pros

1. Supports concurrent work on both the model and drawing.

 

1. It is possible to support separate workflows for the drawing and model (more on this in the under Cons)

 

1. The part and drawing are bundled together under a single item revision so it’s easy to find them.Oh wait, I guess that’s true of the previous all-in-one model solution too. I should go update section. Wait. No. No, on second thought I won’t do that. I don’t want to say anything else positive about that last setup.

 

Cons

1. It is harder to set up separate workflows for the drawing and model. Usually a workflow takes an Item Revision as a target and then processes a review process for relevant attached datasets. You’d either have to set up workflows that take one dataset or the other as a target, or that take an item rev and then pick up only the model or only the drawing dataset. Then you have to figure out how and when the revision itself is released. I’m not saying it can’t be done, but I think it’d be pretty convoluted.

 

1. You can’t have revision independence since both datasets are under the same revision.

 

1. Multi-detail drawings are probably possible to support, but it’d be an awkward setup. You’d have to figure out which model’s item revision contains the drawing, or have the same drawing dataset referenced by multiple item revisions, each one of which contains a different model dataset which is detailed by the drawing. Again, I’m not saying it can’t be done, but I suspect it wouldn’t be a very elegant solution. (Feel free to prove me wrong—I’d love to see a clean way of making it work this way).

 

Master-Model using separate Items

The last approach I’ve seen is to have one Item for the model and another Item, usually of a different “Item Type” (to use the old, but convenient, terminology) for the Drawing. As before, the Master-model concept is used.

Pros

Overall, this is the most flexible, although for some it may be too flexible.

1. The model and drawing can be worked on concurrently.

 

1. Setting up separate workflows for the model and drawing is very easy to do, and if you don’t care for that then it’s also pretty simple to set up a single workflow for reviewing both at the same time.

 

1. Revision Independence. Since the model and part are now under separate items, it’s trivial to revise them independently; just revise one, but not the other.

 

1. Multi-detail drawings are easy to support. Simply create separate items for each part model and then create a single drawing item that details all of them.

Cons

1. Un-synchronized revisions. If you don’t want revision independence you need to need to set up processes and safeguards to ensure that revisions are synchronized.

 

1. Globally unique Item ID restriction. Usually companies expect to store mono-detail drawings under the same drawing number as the part which they detail. Unfortunately, Teamcenter cannot currently support that. As of version 8, Teamcenter requires globally unique Item IDs regardless of item type. That means that you can’t create a Model item, 123455, and also create a Drawing item, 123456, to detail that part. Siemens claims that Teamcenter 9 will introduce multi-key item IDs, in other words in Teamcenter 9 you will be able to use the same Item ID for two different items, so long as they are actually different Item Types. At least, that’s what they’ve claimed. Until then the normal solution is to prefix or suffix the drawing with something to distinguish it from the model item. For example, the Model could be 123456 and the drawing of that model could be DRW-123456.

 

1. It’s harder to find everything. If a user does an Item query on “123456″, he’d only find the Part item, 123456. In order to get both the part and the drawing he would have to search for “*123456″. It might take awhile for users to get used to this.

 

One more wrinkle: Separate Drawings and Documents?

Finally, one last consideration. In a previous post I discussed how you might use separate Part and Design items to differentiate between your PDM and PLM requirements. Similarly, you might use separate Document and Drawing items as well. But that subject is probably best left for another day.

Conclusions and Questions

Hopefully I’ve given you some things to think about — or helped you to understand why things are done the way they’re done where you work (or how you might change things).

Are there any other ways to relate drawings and models which I have missed? What other issues are there to consider? Let me know, I still have a lot to learn myself.