I’ve been reading up lately on the differences between Product Data Management (PDM) of CAD data and Product Lifecycle Management (PLM) of part data. I must confess that I used to think of the difference between them as one of degree and not of kind — that PLM was basically PDM on steroids. But more and more I’m coming to the conclusion that I was simplistic in my understanding. The truth is that they are different tasks altogether. Because of this misunderstanding I came up with some very inelegant solutions to some of the data management issues I encountered. I have been looking for better solutions. As it happens, it seems that Teamcenter now provides us with a means for making this distinction between PDM and PLM by maintaining two independent structures, a CAD BOM of Design items and a Part BOM of Part items, and then aligning the two. Although I have some concerns with the process, I think it has potential and should be explored.
When CAD models don’t equal Parts
I think that a lot of us who come from a Mechanical CAD background tend to think of the CAD model as being the part. Naturally, if there’s a part 1001 we think that the thing to do is to create an item in TC numbered 1001 and place the CAD dataset for it underneath. And lo and behold, that’s just what my NX Manager integration will do for me automatically when I create a CAD model called 1001; the item is created in the database and the dataset is placed underneath. It all works beautifully.
Except for when it doesn’t work.
Sometimes an entire assembly of MCAD models will represent a single part. For example, a part purchased from a vendor is typically listed as a single part on the BOM, but may be modeled as an assembly of CAD models. The models of the components don’t correspond to any Part number in the system.
Sometimes It may be desirable to use a single CAD model to represent many different parts. For instance standard parts that are geometrically identical but which have different finish codes. Parts defined by a Selected Item Drawing would be another example.
Other times you may want to represent a part with many different CAD models, for example if the model is of flexible wiring which may be routed in one path in one assembly and another in another assembly (or even in multiple different ways within the same assembly).
And then there’s Electrical CAD, ECAD. Frankly, I had to have it explained to me a couple of times that a single ECAD model actually defines many parts and that there is no CAD model of them individually. Not that it’s really a hard concept to grasp, it’s just that it’s a much different reality from the preconceived notions I had. Sometimes you need to walk right into your own blind spot to know it’s there.
So clearly the idea that you can simply create items for your parts and put their CAD dataset underneath them is at times too simplistic.
Parts, Designs, and CAD-BOM Alignment
Teamcenter now provides a pair of Business Objects that address this dichotomy between managing CAD and managing Parts: the Design and Part Item Types(*). The intention is that Design items will store your CAD data and that Part items will contain such things as requirements documents and analysis data. Designers will create design items which have product structures that represent how the CAD data is assembled, while Part Planners will create Part structures that represent how the parts are maintained by the business systems, e.g. ERP. These two structures are then aligned so that the CAD Design data is associated with the Parts which it represents.
(*)I guess that “Item Type” isn’t really proper terminology any more but I use it for Business Objects which are subclasses of Item.
One thing you’ll notice right away about Part and Design items that differentiates them from other types is that Parts contain a Represented By pseudo-folder and Designs contain a Representation For pseudo-folder. A Part’s Represented By folder contains all of the designs which represent it while a Design’s Representation For folder contains the parts for which it is a representation.
A design can be associated with a part by copying the Design revision and pasting it into the Represented By folder of the corresponding Part. The Design’s Representation For folder will then automatically be populated by the Part revision. The default cardinality of the Represented By/Representation For relationship is many-to-many, so one Design may be a Representation For many Parts and one Part can be Represented By many Designs. This addresses the various problem scenarios discussed above, if you want to have one Design represent many geometrically identical Parts, paste it into the Represented By folder of all of the Parts. If you have one Part which has several different configurations you can paste multiple Designs into its Represented By folder.
Finally, there is a process for aligning a CAD structure to a Part BOM. I’ve only just started working with this myself so I haven’t finalized my opinions yet, but I’ll share what I know so far. The process is to send both structures, CAD and Part, to Collaboration Context which will lay out the two structures side by side. You then select the Design and Part you want to associate and select Tools→Structure Alignment→Publish Data. When you do this you’re given the choice to Globally Associate the Part and Design, which has the effect of creating the associations in the Represented By & Representation For folders. Once the structures are aligned you can send the Part structure to the viewer and visualize the structure the same as if you were looking at the design structure.
Some final thoughts:
A Design for Every CAD model?
If a CAD design and a Part truly do have a one-to-one relationship, as will usually be the case for MCAD parts and designs, do we really need two separate items which then need to be aligned? On one hand it seems to be adding clutter to the database to create both a Part item and a Design item when only one is really needed. On the other hand, if all CAD models are stored as a single Design type then it makes the users’ lives much less complicated since they don’t have to make the decision of which Item type to use. If there is a choice to be made between picking a Design item type and a Part item type you know that sooner or later someone will make the wrong choice.
I admit that I need to play with the alignment process more before I make a final judgement, but the process of aligning the two BOMs appears tedious and prone to error. I’m not sure how willing users will be to take it on. Finding the right pair of Design and Part items to associate looks like something that won’t be much fun if the structures are large or not laid out with similar structures. It doesn’t seem like Collaboration Context takes advantage of any preexisting Represented By/Representation For relationship between the Parts and Designs, but perhaps I’m wrong about that.
Opportunities for automation
It seems to me that there’s a lot of opportunity for automation. For example, by defining naming conventions for Parts and Designs one could implement some custom post-actions on Part and Design creation that would automatically associate the two. If you said that the naming convention for Designs was
partnumber-DESn, then a post-action on Design create could search the database for a Part identified by that part number and automatically associate the two. Likewise, a post action on Part creation could search the database for all designs using that core part number and associate those to the part. That wouldn’t automate the case of one design representing many Parts, but it would simplify lots of the use cases.