Why use a Skeleton?

Wow... I thought this would get some activity.

I found an image online showing a Skeleton Structure. It shows what I was asking about...

Does each part now have to be in its own asy with it's own skeleton that references back to the master skeleton (called Global Skeleton in the image)?

OR

Can the structure be flat, with all the parts using external copy geoms of the same Skeleton?

Skeleton and Inheritance master models are used to prevent circular references and failures in your assemblies. In these cases, references only exist in one place, not a bunch of different places from a bunch of different models.

I actually like to simply put th egeometry (curves and surfaces) in the top level assembly itself, essentiall, a skeleton model inside the assembly. Same cncept, it's just that I've noticed major layers issues with skeletons or inheritance models, whereas I've seen none with the geometry in the assembly itself.

A skeleton is a special kind of part file where the definition for your assembly lives. It allows you to lay out once the critical geometry that two or more parts share like outer surface contours, parting lines, hole locations, etc. It is typically only non-solid geometry - surfaces, planes, curves, axis, etc. - but there is no restriction on what kind of features you can put into a skeleton. Geometry is passed down through the use of publish geometry and copy geometry pairs.

A skeleton part behaves in some specific ways. It assembles in the default location ahead of the default datums. It is ignored by default for mass properties analyses, even if it has solid geometry. It can be filtered out of BOM tables and reports.

The use of a skeleton is one method, a powerful one, to implement top down design. There are many ways to do so. One is to have a single top level skeleton and pass the geometry down to all parts at any level in the assembly tree. The advantage is a simpler structure - you have a single skeleton with all shared geometry. The disadvantage is that every component is a direct child of the top level assy and requires it to be updated. A variation of this is to use the same skeleton at each level of the assy.

Another is to have a separate skeleton at each sub assy in the tree. You'd then pass the sub assembly's required geometry info form the top level skeleton to the subassy skeletons. You might then add geometry there that only is required at that level. Components then get their geometry from the skeleton in the assembly in which they reside, either the top level or a sub assy. The advantage is that each sub assy has the geometry it needs to regenerate. If a change is required at the sub assy level only, it can be made in that sub assy skeleton and that sub assy regenerated. Only true top level changes would require regeneration of the full assy. The disadvantage is a significantly more complicated assy.

The advantage of a skeleton over the master model technique (which I think is what you are referring to as 'reference part') is the ability to pass on only the geometry that the target component needs instead of the entire master model.

Some answers to your questions:

Is is bad for all parts in an assembly to reference the same skeleton?

No, it makes she assy structure simpler but the skeleton itself more complex. It also makes small changes a bit harder as the entire assy must be regenerated even if the change only affects a couple parts in a sub assy.

Would every part now have to have its own assy with a skeleton that copies from the higher skeleton?

No, there would be no advantage in doing that. There si some advantage, as stated above, for each sub assy having its own skeleton.

Does the Skeleton HAVE to be released with the parts?

I would say no, but that's going to be up to your company's process. In my mind the skeleton isn't a manufactured part, it therefore wouldn't be 'released' at all. There may be an advantage to giving it a release schedule, however, and certainly rev. tracking it.

I'm a huge fan of skeleton driven design, but it has its pitfalls. it adds complexity and adds part to part and part to assy dependencies. However, when done well, it can turn a late design change from a multi day proposition to a multi hour one.

Excellent thread, thank you to the contributors. Being new to ProE the skeleton has been one of the harder concepts to grasp. Part of that I beleive is in how the skeleton naming system was implemented on the project I started with.

So the only thing of value I can sort of add to the conversation is backing up what Doug mentioned about naming. I've see a mess of datums in the skeleton that were named something conveneint at the time to match their partner which was conveniently named, but as the development went on the partner's naming scheme became out of sync.

I too looked at the graphic Daniel posted a few weeks ago and was confused by not seeing a representation or chart of the other methods. Doug, your explanation clicked here, thank you.