How Fusion360 and Onshape are solving fundamental CAD collaboration problem

For many years, design collaboration and change management was an ultimate requirement for PDM tools. To manage revision history, share data in the team and apply changes made by different team members was a dream for many users. I’ve seen many attempts to solve this problem by PDM developers with questionable results. The challenge for PDM system was to connect two islands of data – CAD files and PDM database. More successful implementations in this space are belonging to CAD/PDM bundles provided by a single vendor in the situation when both CAD file structure and PDM data is controlled by a single tool.

Cloud CAD technologies are breaking the barrier of existing CAD/PDM bundles by introducing embedded PDM functionality as part of CAD tools. You probably remember my earlier post – Cloud CAD will have to solve PDM problem first. Autodesk Fusion360 and Onshape are two cloud CAD products today that are supposed to turn design collaboration dream into reality. Earlier in my blog I explained why I think Autodesk and Onshape disagree about cloud technology and focus. There are differences in data management approaches, offline mode support and application technologies used by both vendors. But, at the same time, it is very interesting to compare how both products are solving similar problems.

Autodesk Fusion360 blog – June product update review by keqingsong speaks about functionality added to Fusion360 to support distributed design and allows collaboration in distributed teams.

The following passage can give you a good description of what means distributed design for Fusion360 including usage of reference geometry and specific version inside of the project. What is interesting is how Fusion360 holds top down relationships between different elements of the project.

This release lays the foundation for distributed designs that will allow for future enhancements.  In this update, you will able to insert referenced geometry that is part of the same project.  Models outside of the project you are working must be moved or copied to your current project before they can be referenced.  When a referenced model is inserted into another model, a reference image appears before the name identifying which components are being referenced.

A “component is out-of-date” notification will appear when a referenced part is updated.  You will then have a choice to update and receive the change or keep the current version in your model. Simply right click on the referenced component and select “Get latest”. This intended workflow allows for designs that are in production to reference one version of a model while other versions are being created for a future design.  If a component is inside a model that is referenced by another model you must update the sub model first, save it, and then go to the top level and update.

At the same time, my attention was caught by Onshape blog – Under the Hood: How Collaboration Works in Onshape by Ilya Baran gives you a deep insight on how Onshape is managing changes by introducing a concept of “microrevisions”.

The following passage is explaining how microversions technique applies into distributed environment with multiple users.

For a given Part Studio, at each point in time, the definition is stored as an eternal, immutable object that we internally call a microversion. Whenever the user changes the Part Studio definition, (e.g., edits an extrude length, renames a part, or drags a sketch), we do not change an existing microversion, but create a new one to represent this new definition. The new microversion stores a reference to the previous (parent) microversion and the actual definition change. In this way, we store the entire evolution of the Document: this is accessible to the user as the Document history, allowing the user to reliably view and restore any prior state of an Onshape Document.

These definition changes are designed to be very robust: a change stored in a microversion is intended to apply to the parent microversion, but could be applied to a different one. For instance, if the change is “change the depth of Extrude 1 to 4 in,” as long as the original feature exists (identified using an internal id, so it can be renamed), this change can be applied. As a result, changes coming simultaneously from multiple collaborators can simply be applied to the latest microversion without interfering with each other. Traditional CAD systems based on saving an ever-changing memory state into files cannot do this, even if run on a remote server or with a PDM system attached: the data itself has to be collaborative.

What is my conclusion? Fusion360 and Onshape are trying to solve the problem of design collaboration. Both systems are leveraging cloud data management backend (Autodesk A360 and Onshape) to create robust mechanism to manage data, changes and relationships between design components and projects. The advantage of cloud architecture is that all “implementation mechanics” will be hidden from end users, which is absolutely great news. At the same time, it would be interesting to see how robust these approaches for use cases where  Fusion360 and Onshape will have to manage CAD data coming from other CAD systems. To avoid “double PDM tax” is a challenge both systems will have to deal with. Just my thoughts…

Best, Oleg

Image courtesy of Stuart Miles at FreeDigitalPhotos.net