Revision management of sub-assemblies and multi-step parts

dustin_hecocks

So I've got some questions about revision management in OS. I am an industrial design engineer, using SolidWorks exclusively for work. I do not use any kind of PDM, so document and revision control has been a manual process. This is a feature that has me interested in OS, because any assistance in revision management is a big deal. Since I work in medical device design, revision management is paramount. 

So my question is two fold. First, what is the best way to manage revisions of sub-assemblies within a document? For example, one document will contain an entire device, and this device is composed of say 30 parts, and three sub-assemblies. The version management tab at the top seems to be a broad umbrella control. I am aware of assigning your revision of part and sub-assemblies via properties, but this seems to record and track very little, if at all. So I am guessing the document "manage versions" feature would be utilized every time you revise anything all the way down to the part level, which would in turn make that version management bar extremely messy for large assemblies, eventually to the point of being useless. Is this not available at the part level, or even the assembly level? Am I correct that the unique management control features are at the document level?

Second, is there a control mechanism for a multi step part? For example, we have a part that we order from a vendor. It has a drawing and a part number, it gets ordered, and it gets stocked. We then modify that part, with a new drawing, and it gets a new part number, and it gets stocked. We then do that process once more, giving it another part number and stocking it. That last piece is a component of a final assembly. My process in SolidWorks is as follows:
1. Create part, model three configurations of that part. First drawing is at the part level.
2. Create an assembly, bring in that part, use the second configuration. Drawing Bill of Materials generates correct information.
3. Create another assembly, bringing in assembly from step two, but changing the configuration to 3 on the part level. Drawing Bill of Material generates correct information.
So I am generating traceabiliy on my part and its multiple steps. But I am hoping with OS being focused on revision control, there may be a better way to streamline this process.

Interested to hear what you guys think, especially those of you working with large assemblies with the need for critical revision control. Thanks!

-D

philip_thomas

This is a great thread - just tagging so I can follow users contributions for now and possibly weigh-in later.

lougallo

@dustin_hecocks So a few things here to add as a primer:

1. Onshape version are currently immutable snapshots of the ENTIRE document.
2. Versions, although they do capture state of properties, is not Revision management (typically a per part number control based on state workflows (process)

With this being said, there will be much to come with respect to controlling revisions of parts as we evolve Onshape.  How our data management applies today:

• History - Auto captures of actions back to the origination of the document (removes the fear of trying new things since you can always go back to a previous action)
• Versions - Manual capture of the current state of the document.  (gives control to lock down an important step in the design and give an option to branch ideas from at a later date)
• Branching - Derive a new idea from a version without effecting the current branch's workspace (applies to the entire document, not just the tab you are in)
• Merging - Pull changes into your current branch's workspace (entire document), "merging" changes into once "synced" workspace.

I know many of these ideas can be hard to grock but focusing on the first two, those could have (either by Onshape or a 3rd part) the ability to lay a process workflow on top of the versioning/history to allow for revision control, access control, actions, notifications etc...  In the meantime, Onshape provides the framework to avoid the check in/out confusion and removes the worry of losing the ability to undo changes due to accidental loss or modifications.

dustin_hecocks

@lougallo Thank you for the reply. I am certainly a fan of those features, and they are great to utilize personally. However, though those features are very helpful to the designer, they don't do much to help some users meet the requirements of their job. My industry, medical device, and well as others, such as aerospace, federally mandate revision control. Now, to be clear, this really applies to engineering drawings. But many, myself included, apply that stringent revision control to the models linked to our drawings as well, simply to keep our own rear ends nice and covered. PDM (Product Data Management) solutions are meant for just that, revision control. But I remember seeing in some OS video that a goal of OS was to rid the need for a separate PDM solution. Which sounds amazing, because for most of us, PDM solutions are more trouble than they are worth. The implementation, the "vaults", the servers; it's a huge undertaking many companies skip. So here are some ways myself and others in this field are controlling revisions in SolidWorks without PDM:

1) At every finished revision, collect all and save as a copy. Can be very messy, and a massive space hog. Imagine separate folders for each revision of each sub-assembly and trying to keep everything current and linked. Nightmare.
2) My weapon of choice, configurations. Not a fool proof solution, because saving a configuration does not lock your model down or protect it from some future changes in future revisions. I don't often call up old revision configurations, but when I do, more often than not, something has been modified, whether by user error or a global feature change.
3) Drawings only. The above options are not very clean, so many opt to just manage ONLY PDFs of their drawings, leaving no trace of editable model or drawing history. 

So the thought, the version management system you have, being able to apply that to the part and assembly levels; my god, how great could that be! And drawings too?! Man, what an improvement that could be. To be able to lock down a revision of a part, sub-assembly, assembly, and drawings, all individually as they rev up; it's a game changer. So when the OS videos talk about OS removing the need for a separate PDM system, I am hoping this is what they are talking about. So I guess what I'm asking is whether or not this is part of the game plan, or the version control as it stands now is the plan, not necessarily revision control? 

pete_yodis

@dustin_hecocks ; I also come from a similar background as you.  I oversee our use of PDMWorks WorkGroup and have setup, migrated, troubleshot a move to EPDM with rollout coming soon.  Mostly SolidWorks stuff.  I think when Onshape allows the insertion of documents into other documents (document to document referencing..or whatever it gets labeled), you will then have a strategy to manage each piece of geometry in it's own document.  This would then demand a more bottom up approach to designing, but I think it would at least allow you to control things to a much more granular level that you are asking for.  Either that, or within a document Onshape may allow (I don't now how) versioning of bodies within the document.  That would also give a granular control.

dustin_hecocks

And just to add to my post above. To my second point in the first post, that is usually what I would consider as "versions". We stock three different versions of a part. They are all linked, as they a progressive versions of the same part, but they all have independent revisions. So all versions remain active parts, with their own independent revisions, but clearly a process flow from one to another. Does that make sense?

lougallo

@dustin_hecocks Totally makes sense.  @pete_yodis said it well, once we have inter-document referencing, versioning can make a good start to creating pseudo-revisions.  As we grow the platform, others might expand on the layer of revision management into the mix. 

_Ðave_

+++10 @dustin_hecocks for expressing my exact concerns so well. My first thoughts looking at the versions tree was how in the hell am I gonna incorporate all that @dustin_hecocks has so eloquently described. I have and require these exact needs and am looking forward to how OS will develop a solution which certainly will be no easy task.

 Thanks dustin for bringing this up and thanks Os for accepting the challenge.

_Ðave_

  @dustin_hecocks Your question as caused me to investigate into the version branching tree to try and find a solution for this type of workflow in which I also require.

 What I'm attempting and appears to be working, Is to branch from the start and create branches for sub assemblies and also branches for individual parts. From These branches I can create individual branches for parts within these sub assemblies. At any time I can save and revise (save version) any part, sub or whole of the assembly. When I'm satisfied with a revision I can then merge it into its sub or whole assembly.

 This is just a theoretical workflow and not fully developed but from initial testing appears that it may serve our objective.

 Looking forward to hear from others with these issues and how they are planning to resolve them.

Dave

dustin_hecocks

@dave_petit Thanks for the suggestion. Gave it a try today for a little bit, tried to see how I could get it to work. It certainly felt like a workaround, and quickly got a little complicated. It would take some time to wrap my mind around getting that to serve for revision management. It feels like OS is primed and ready to have great revision management capabilities. What with the constant tracking and infinite undo of every little change, it seems like (and I'm no programmer) that the switch to taking the version control down to the part level would not be a HUGE leap. Like with SolidWorks, implementing revision management becomes such a bear because tracking your history and movements is just not a part of the SW framework, so trying to implement something to control revisions becomes a significant effort. The capabilities are already here is OS. It's so close you can taste it! But it's just not implemented in a way that makes it very useful, at least to myself. I'm sure if the needs of the general user population are similar to mine, it'll get there. I sure hope it does.

_Ðave_

 @dustin_hecocks thanks for replying.

 Yes, It is a bit of a workaround. My intent was not to claim a working solution so much but as a starting point to progress from.

  I like the concept of keeping all of the parts within a single document, which this process will provide without external links which could be an issue keeping organized and linked. But unfortunately when creating parts in the main part studio (which is quite convenient) there is no convenient way to get a single part into another branch of the version tree with it's specific feature tree. I understand that OS may be working on a way to do this. Also It appears that the Versions branch tree would soon get quite difficult to navigate on large assemblies. Hopefully if OS considers this a viable workflow they may incorporate some functionality to assist and make this flow a bit smoother. Or possibly a much better process but this is certainly an area of concern.

Thanks
Dave
  

brucebartlett

This is great stuff. Revision's built into 3d models not just the blocks on the drawing (although this will be important too) and reduce the need for countless ECN doc's. Hope this discussion keeps on going with some quality outcomes implemented, Will need some hardcore UX testing across industries and maybe even partners for specific requirement's. Great thing is the structure is in place to build on. 

stevehess

Definitely great stuff here.  tagging on as well.  

3dcad

For us who are not required for 'official revisions' but who should have version control for keeping track of changes and possible cost changes in production; revision control should be a one button thing. I mean, that if it has a learning curve with workarounds we will probably just make copies or just modify original or at worse case just make changes without updating cad data and not use such a great feature.

In my game with furniture the need for new revisions could be:
1. proto model, only for the looks - modeled just as much as we need to have a nice rendered image of final product look
2. updated protos according to customer needs (currently just modify the original to find the final shape)
3. production model, at this point we bring in the inner mechanisms (standard parts) and add drillings and connection accessories. Finalize dimension.
At this point we should compare to all existing parts to take benefit of those and not to create almost similar parts with only 1mm difference or so (this is not that easy when having thousand of parts). This would be the first production version.
4. Possible revision if some standard part changes (new supplier or so..)
5. Another possible revision if we expand the collection with new product that can use the same parts but needs some more drilling or other minor change which doesn't harm original product etc..
6. Special revisions for limited time sale or similar marketing versions.
7. End of product lifetime revision, usually we need to make some slight changes to efficiently end a product (or more like a collection) lifetime.

Sadly, our cad data usually only follows up to point #3 and revisions are made just to production (cnc programs). This is because of the lack of easy revision control in cad and the need to update all static files like assembly instructions.

Using configurations for revisions is too messy, since we usually already have 5-10 configurations in most of files and new revision would always multiply the amount (I'm great fan of using configurations to lower the amount of files and speed up assembly work within similar parts).
This makes the cad data useless in later revisions and this is something I would like to change.

That said, +1 for one button revision control. Just click to begin new revision and Onshape takes care that you have always access and compare possibilities to old revisions.

brucebartlett

That said, +1 for one button revision control. Just click to begin new revision and Onshape takes care that you have always access and compare possibilities to old revisions.

Isn't this basically what shift+s does. 

3dcad

@brucebartlett To be honest, I haven't dig into version/branch features deep enough yet. Point of my post was: What ever features Onshape gets, keep them simple enough fo everyone to use.

dustin_hecocks

@brucebartlett Thanks for chiming in here. I can see for your screenshot that you are making good use of the branching in version control. Admittedly, I have to dig in a lot more to the branching in the version control. Coming from SW, its a different approach, so I kind of need to get my mind fully wrapped around how to utilize the workflow of branches.

But the version control and history is powerful. Technically, it is already tracking every revision you make all the way down to the part level. The unfortunately part is that (in my opinion) it is not efficiently organizing this information. In theory, you could go call back any revision you made. But in practice, if you have many parts and assemblies, good luck trying to find a part revision made three weeks ago. I have zero experience with SolidWorks PDM, but as far as the standalone application, OS already has a major leg up on SW in history tracking. And I think that is a pretty big deal, to have a leg up in anything on such a polished and established product. I am hoping the existing technology is further refined and utilized for effective revision control and management. 

And to @3dcad point, maybe it could possibly be a configurable option. When you open a new document, maybe you have the option for simplified overall version control, or part level revision control. Because certainly not everyone needs the stringent revision management that I do, and maybe those features to some would be more cumbersome than helpful. I would guess given the option, you would see pretty sizable use of both configurations. 

_Ðave_

@pete_yodis I've done a bit more experimenting with the version branches and have concluded that I agree there's yet much more functionality needed to make it work smoothly. Until then it appears the best solution is that when I update a model just export as a dumb solid and create a drawing with the rev change.

Dave

pete_yodis

dave_petit said:

@pete_yodis I've done a bit more experimenting with the version branches and have concluded that I agree there's yet much more functionality needed to make it work smoothly. Until then it appears the best solution is that when I update a model just export as a dumb solid and create a drawing with the rev change.

Dave

@dave_petit I agree there is more functionality needed.  I think Onshape is really doing a good job of laying the foundation of their product and then allowing us hacks to beat on it a bit and work out all the kinks to the foundation before they begin to add more on top.  If that foundation isn't correct from the get go, then things on top will be awfully difficult to fix later after a lot of user data has been created and in the Onshape system.  There is a long term benefit to proceeding a little more slowly here.  For now, you can only version the whole document.  The top down approach with being able to define geometry of all the bodies in one part studio is efficient from an initial layout of a product is concerned, but brings some caveats when you then need to lock a design down and manage revisions of each change to a body/part.  For product design I like the idea of a single part studio to work in, but I would like the idea of being able to break that at a later date when a design moves to the lock down phase.  In SolidWorks, in each part file I would kill all the in context relationships back to an assembly layout once that design was finalized and moving into being formally revision managed.  I wonder how that is going to work in Onshape with features spanning multiple parts/bodies?  I think it may cause a change in how people will want to work if part studios are not flexible enough to adapt to how people will want to manage their data after the fact.  Folks may opt to not do top down design in Onshape and will do the bottom up approach if that is the case.  For now, the bottom up approach is hampered by not being able to insert bodies located in another document.  I think we lab rats are being watched to see what we think and what we ask for of the tools.  As it stands right now... I would like the ability to change methods during the design and for the revision management and layout tools to be able to shift with me.  Is that fair?

dennis_20

@dustin_hecocks, I appreciate your bringing this up with such a good example.  I think many of us are watching for this PDM capability.

The process you describe below brings up a couple of things.

dustin_hecocks said:

My process in SolidWorks is as follows:
1. Create part, model three configurations of that part. First drawing is at the part level.
2. Create an assembly, bring in that part, use the second configuration. Drawing Bill of Materials generates correct information.
3. Create another assembly, bringing in assembly from step two, but changing the configuration to 3 on the part level. Drawing Bill of Material generates correct information.
So I am generating traceabiliy on my part and its multiple steps. But I am hoping with OS being focused on revision control, there may be a better way to streamline this process.

Interested to hear what you guys think, especially those of you working with large assemblies with the need for critical revision control. Thanks!

-D

We sometimes do a similar thing in that we purchase a vendor part, assigning a part number to it and stocking it and documenting it with a part and drawing file and then making a new part from it by modification.  However, our part file and drawings are more separated than your process and I think are more secure.  With your process of having the raw and modified parts as different configurations within a single file it is very easy to change something that shouldn't, i.e., making a change to one of the modified configurations and that change inadvertently affecting the raw part.

Instead we keep the raw part in its own part file.  Customized parts made from this are themselves separate part files.  We use SolidWorks' Insert -> Part in this new file to insert the raw part.  It looks and is treated much like a dumb solid in that you cannot modify the base part itself and this new file contains just the modifications to the raw part.  We use the same technique to control separate files between a raw casting and the various machined parts that can be made from it.  We also use this same technique with our library of raw materials, which has completely eliminated those pesky issues of different engineers using a slightly different detail for the raw material.

I have not used OnShape enough to know if it has this equivalent capability (Insert -> Part), but consider it an invaluable capability.  If this does not exist then I am sure there is already a ticket on it and I'd like to add my support for it.

brucebartlett

dennis_20 said:

Instead we keep the raw part in its own part file.  Customized parts made from this are themselves separate part files.  We use SolidWorks' Insert -> Part in this new file to insert the raw part.  It looks and is treated much like a dumb solid in that you cannot modify the base part itself and this new file contains just the modifications to the raw part.  We use the same technique to control separate files between a raw casting and the various machined parts that can be made from it.  We also use this same technique with our library of raw materials, which has completely eliminated those pesky issues of different engineers using a slightly different detail for the raw material.

I have not used OnShape enough to know if it has this equivalent capability (Insert -> Part), but consider it an invaluable capability.  If this does not exist then I am sure there is already a ticket on it and I'd like to add my support for it.

Yes in SW I tend to avoid having configurations for different versions of a purchased part which are modified in house and need drawings or instructions, currently I'd download/draw it preferably as a part or multi-body part(not an assy) and then insert it into another part and make mods here. Sometimes the only mods maybe properties for paint detail and a drawing with specific instructions.  In Onshape at the moment I'm a bit limited but I'd do this in the part studio with the copy body then add changes and new properties on the copied part (nice workflow) however would not work with a multi-body part though unless you could group parts in the part studio and add properties to the group and this could also be drop into the assy as a locked up group, there's an idea.  I am waiting for Onshape inter doc/inter part studio relation get my head around future work flow's to solve these issues.

Not sure how the version tool will work with inter doc and inter part studio relation could be messy but sure there is a way to do it cleanly and efficiently. I think the immutable version tool may help to stop things falling apart from peoples down stream changes, will be interesting to see.