Automatically release parent assemblies when releasing a part

romeograham

When we have an assembly that includes sub assemblies, and all parts and sub assemblies are Revisions, it is a huge amount of work to edit and re-release a part at the bottom level.

Consider this example arrangement (all parts and assemblies are Revisions):
Top Assembly-A
>sub assembly-A
>>sub assembly-A
>>>part-A

When the Part-A is edited and released to Rev B- it takes 4 releases (if I don't make any mistakes!) to end up with this:
Top Assembly-B
>sub assembly-B
>>sub assembly-B
>>>part-B

Please make it automatic!

The new workflow could be: edit the Workspace for the part and release Rev B - then Onshape will cascade the release up the chain, to give me Rev B throughout. Onshape knows what has changed, and which sub assemblies will need to be up-revved. Maybe there will be a checkbox that I can select or something, but really - in what scenario does anyone NOT need to Revise all the parents of a changed child?

See here for one of the recent excellent discussions on this topic.

Thanks!

lougallo

@romeograham I think this would be more along the lines of having a way to pull changes up the tree.  When we finally re-release the recursive assembly update, you could make these changes of the part, version it and then pull this up to the top and re-release.  Once we get that feature out, I would like to revisit this workflow.  I am going to move this over to product feedback for the time being.

romeograham

@lougallo that sounds reasonable. I like the idea of pulling it up rather than pushing it up.

aeromorrison

I agree this is a challenging issue in Onshape that leads to many, many 'no value' revisions to assemblies that then have to be cascaded to downstream systems such as MRP/ERP. This creates a lot of needless churn. Best practice in product configuration management would say that "parts do not have revisions" from the standpoint that revisions cannot impact form/fit/function or interchangeability. A revision to a part should not impact any assembly where it is used and parts of a single part number and any revision status should be stored in inventory in the same bin. If something is going to impact a higher level assembly, then it should be assigned a new part number. A part number change then only cascades as many levels up the assembly tree as required before no longer affecting form/fit/function or interchangeability.

I'd like to see Onshape add a Company setting that allows for uniqueness in parts to be determined by P/N and not revision. In other words, the Product Structure should only include the P/N of item and not the revisions. This change would solve my company's biggest challenge with Onshape and make both engineering and production personnel very happy.

tim_hess

@aeromorrison: Just for clarity - In your best practice system, can assemblies be revised, or are they given new part numbers when they aren't interchangeable after a modification?

aeromorrison

@tim_hess Part and assemblies can be revised just the same. It's just that revisions are not the 'anchor' for configuration control. Part Numbers are the 'anchor' for configuration control. So, you should be able to mix/match revisions of parts or assemblies into higher-level assemblies with no concerns. A part number change would be used any time a proposed revision affects form/fit/function/interchangeability. In other words, the Bill of Materials (or Product Structure) should not need to list revision status to fully control the product configuration.

This concept is reflected in industry standards related to product configuration control and change management. For example, the military standard DOD-STD-100 indicates that "Part numbers shall not include the part revision" and the Configuration Management Deskbook says, "Part number, a number used to uniquely identify a part or item. ...The revision letter is not included with the part number."

tim_hess

@aeromorrison - Thanks for the clarification. I've seen some of those standards/recommendations as well and just wanted to clarify your usage. If you follow form/fit/function rules, anything with the same part number should be interchangeable regardless of revision. 

When you say "The Product Structure should only include the P/N", what exactly are you referring to? It seems totally valid to have a revision level associated with a document in the product data management tool (Onshape). If the revisions exist, the tool has to have some rule about what is actually displayed to the user, right? If you're just talking about BOM tables, the Revision level can be removed from those easily. 

If I re-phrase what you're asking for out of onshape- is it that you want higher level assemblies to not be "out of date" if something below it is revised and still interchangeable (ie. no part numbers have changed, following your rules) because the "Product Structure" is still technically the same? 

I think I understand what you're getting at (and find the discussion interesting). My feeling is that Onshape is still not designed to capture the "product structure" that should be ideally captured in and ERP or PLM system. In contrast to those systems, onshape is built for managing the "product data"  consisting of 2D and 3D representations. In onshape we revise these representations, so the revision level IS an important part of product data and defines the "uniquess" of the REPRESENTATION. Then, trouble comes in when part numbers the identify "items" get confused with part numbers that identify 3D models or 2D drawings, which are representations of items.  So, to me, I think that the way onshape deals with P/Ns and revisions is OK, because its really only managing representations of these items. The improvements need to come from integrations with the other systems that do manage the relationships of the items themselves (like the ERP systems). 

Just my $0.02. Thanks for the discussion

aeromorrison

When you say "The Product Structure should only include the P/N", what exactly are you referring to?

When I mention Product Structure, I'm generically referring to the hierarchical BOM for a product, subsystem, etc. In my comment I was attempting to reinforce that the configuration of a product can be controlled without the need to include revisions of parts in the Product Structure. Any revision of a part should be interchangeable with any other revision of a part. So when I say "parts don't have revisions" I'm really referring to that idea. Parts certainly have revisions from the standpoint of individual item control. For example, I might add a hole to a part to make it lighter weight. This would definitely be a revision. If adding the hole does not affect its usage then it doesn't need a new part number and higher level assemblies should use it automatically (without the need to do release revisions up the chain) since the product structure doesn't care about part revisions.

If I re-phrase what you're asking for out of onshape- is it that you want higher level assemblies to not be "out of date" if something below it is revised and still interchangeable (ie. no part numbers have changed, following your rules) because the "Product Structure" is still technically the same?

Yes. That's generally what I'm saying. The determination of interchangeability or form/fit/function is not something that Onshape can do. It's a company change management process because all product have unique requirements. The decision of the change management process is reflected by whether a revision is released (in which case the higher level assemblies should just show the latest revision of the unchanged part number) or a new part number is created (in which case at least one level of higher-level assembly is affected).

Onshape is extremely powerful as it relates to tracking of geometric and metadata representations, as you say. This is a huge asset and should be leveraged as much as possible. Similar to your statements I believe it needs to have a deeper sense of best practices for configuration control and change management because many changes that are important to track from a geometry management standpoint may not be important from a configuration control and change management perspective.

Onshape is selling an integrated PLM system as part of the subscription including BOM management, formal release management, etc. PLM systems are the place where product configuration and design history and product data management is captured. All of the aspects we're discussing related to product structure should happen in Onshape. ERP/MRP systems are where the current product configuration is manufactured/produced and any as-built differences and build records captured.

Great discussion! By the way, I started a fresh thread on a similar topic to hopefully draw in some other forum participants. See https://forum.onshape.com/discussion/comment/81995#Comment_81995.

adrian_vlzkz

aeromorrison said:

I agree this is a challenging issue in Onshape that leads to many, many 'no value' revisions to assemblies that then have to be cascaded to downstream systems such as MRP/ERP. This creates a lot of needless churn. Best practice in product configuration management would say that "parts do not have revisions" from the standpoint that revisions cannot impact form/fit/function or interchangeability. A revision to a part should not impact any assembly where it is used and parts of a single part number and any revision status should be stored in inventory in the same bin. If something is going to impact a higher level assembly, then it should be assigned a new part number. A part number change then only cascades as many levels up the assembly tree as required before no longer affecting form/fit/function or interchangeability.

This is a touch topic, in the real-world is not very realistic since, for highly regulated environment a replacing a part number in a commercially released product would take months of work from many teams, the policy typically is that any new Revision to a PN automatically obsoletes older revisions, and a material disposition indication is released for any existing inventory. Also, contract manufacturers need clear identification of what revision of a part they have to produce and/or assembly.