How Fusion360 and Onshape are solving fundamental CAD collaboration problem

How Fusion360 and Onshape are solving fundamental CAD collaboration problem

3d-puzzle-design-collaboration

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.

fusion360-distributed-design

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”.

onshape-microversions

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

 

Share

Share This Post

  • Pingback: Beyond PLM Blog » Cloud CAD/PDM and mass customization future()

  • Pingback: Cloud CAD/PDM and mass customization future | Daily PLM Think Tank Blog()

  • Oleg,
    Some interesting concepts here long overdue for mainstream CAD collaboration, some drawn from capability long held in the most expensive platforms, others bringing us closer to a development environment more resembling software.

    Fusion’s reference geometry is a mirror of NX’s WAVE capability (the function which has been around believe it or not since the late 90’s). WAVE allowed associatively referencing external part geometry (either a specific face or feature or the whole part). It would maintain the geometry locally such that it could be used in construction of the work part. There is automatic update capability through Teamcenter integration as well as long as both parts eventually had a common parent. Or you could choose to keep the reference link frozen until you reopened the linked part in question to update.

    The WAVE feature is tremendously powerful in that you could link critical geometry across all interfacing parts (hundreds or thousands) and if those parts were properly parameterized from those references, you could update very complex assemblies by moving or modifying a couple pieces of geometry. This would let you build “controls” into a thousand part assembly that could very quickly respond to change.

    My guess on why it’s being implemented now in Autodesk’s product is perhaps the original patents are at or near expiration. That’s the elephant in the room when it comes to evolving CAD collaboration – many techniques are locked behind IP walls erected by the Big 3 (for understandable business reasons).

    Onshape’s implementation of microversions is very intriguing. Very Git-like. It’s essentially the merge feature that CAD badly needs. However, it’s a bit unclear what happens in the event of conflicts (i.e. same features changed in different ways by different users). That’s something I intend to experiment with in the Beta. Regardless how it works, you’re absolutely right about the double PDM tax – that will limit taking the most advantage of solutions like Onshape.

  • beyondplm

    Ed, thanks for you comment and thank you for reminding NX’s WAVE. It is indeed very similar stuff. Actually, I think there is similar capability of CATIA V5 bundled with VPM (old ENOVIA product). I’m not very familiar with Creo/Pro-E, but will not be surprised to see identical function. The difference of Fusion360 is to bundle it within mainstream $25/month/user package supported by A360 on a public cloud.

    WRT conflicts is Onshape – video explains how Onshape solves potential conflicts – last wins. It might be useful for simple scenarios, but I’d love to learn for more complex scenarios too with involvement of multiple parts.

    Note, both Fusion360 and Onshape are explicitly stating to support collaboration in a context of single project / document. This is something that requires more learning – look forward to check it using Fusion and Onshape (hopefully later this week).

    Best, Oleg

  • Peter Yodis

    Oleg and Ed. I think a different modeling paradigm (other than history feature based) coupled with the Onshape approach might have the ability to avoid the issues with merging of 2 or more incongruous branches due to the complexities of feature trees. Interesting topic.

  • beyondplm

    Peter, That is a very good point! Thanks for brining this up. I guess today Onshape can deal with the history of operations only. The ability to bring “any 3D models” into design workflow and the ability to merge it with Onshape geometry can be an interesting future opportunity.

  • Will be interesting what we learn – easiest way is just to try it and see what happens, that’s the beauty of the accessible free CAD model when is comes to discoverability.

  • beyondplm

    Ed, thanks- I was optimistic about a week, but this is “in process”. Look forward to blog more about that in the future.

  • Ryan

    I have to agree with Ed. What I have been reading about these systems has all been done in the integrated CAD platforms for some time. I help generate large complex assemblies using WAVE back in the late 90’s and 2000. Here we were driving close to 1,000 unique part numbers using WAVE to “configure” large weldments for the Gas Turbine inlet systems. Old news for some..but new bells and whistles for “mainstream” 20+ years later??
    I agree with Oleg, that Autodesk is bringing this to mainstream with an “inexpensive” option that is web-based. But then again, I look at these technologies and still shake my head. How many people truly work in these full collaborative environments where you have multiple users working on a single file?
    I can see this in the Auto/Aero where you can break models apart and assign users the ability to work on sections of a part file- (once again this is nothing new). But outside of that I don’t see this happening too often. If the Autodesk product is suppose to be for SMBs then why all this “high end” collaboration? The SMBs usually have design teams of 1-10 people. In these environments, from my experience, the last person I want making changes to an engineered part is the shop floor (last person to save) or heaven forbid the sales guy.
    With that in mind, you then need to look at rights and you are right back to a traditional PLM system with workflows and file access. Or am I missing this altogether?
    When I look at Onshape Microversions I cringe at the thought of things like…what version were we looking at and approved in the design review meeting? Did those changes that were suggestions really get approved and applied to the model? Those were just suggestions.
    When I look at the microversions I just see the complete design history that has always been hidden from the user. Having the ability to revert back to specific change sounds interesting but how is that different from an Undo list? To me, this is exposing way to much information and it will become very confusing to people and organizations.

  • beyondplm

    Ryan, thanks for sharing your insight! My immediate reaction – you are right! As an engineer, I think, why (god forbid) somebody else will touch my work? So, might be Autodesk and Onshape is doing that “just because they can”? On the other side, thinking about customers, work life is getting more collaborative. We are interacting more. Small companies might interact with design contractors and manufacturers. Maybe there are some other scenarios. On vendors’ side, I’m not excluding the possibility for Onshape and Autodesk to shot towards disrupting existing CAD/PLM vendors in their home turf – big auto/aero customers. What is your take on this?

  • Ryan

    Oleg,
    I think if the tools that are coming out can: 1) support the processes that are currently in place and continually being extended into the rest of the business processes; 2) if it makes business sense to change; 3) or if the new tools can replace the existing processes and make business sense, then yes, these tools have a possibility of disruption. But the smaller word in that statement are the ones with the biggest impact: “if”.
    Here’s a question I have. With Onshape being a limited “project/document” based system how does a discrete manufacture going to handle this? In my organization we have 10+ product lines. I have one product line that has over 10 billion possible configuration and others with more possible configurations. Will my organization be able to afford this..even though I don’t create all 10 billion configurations? Is each item master going to be its own project?

  • beyondplm

    Ryan, you are right about complexity of manufacturing organizations with product lines, configurations and organization. It was always a differentiation case between high end and mainstream systems. I guess Onshape is not trying to solve this problem for the moment. I think, Onshape might decide to focus on this later. But, there are so many “ifs” on that road. At the same time, high end systems need to develop better collaboration technologies. In fact all top PLM vendors focused on these problems already back in 2000s. It is all speculation, but if Onshape 3D collaboration can be a better technical solution that can scale and be more cost effective than 3DEXPERIENCE (or other high end alternatives), then we might have an event of disruption.

  • If you need another user to test some functionality with, just let me know – I also have an account.

  • Don’t disagree, but I imagine Onshape long’s view (if they’re being smart about it) is as projects get more complicated and you start getting into long histories of product lines, then just upsell more advanced management capability as companies grow out of the simpler project model.
    There’s room for Onshape to really drift away from the ownership model, just like Dassault might be able to do as they drift away from classical file structures in V6. The question will be, can this be done in a way that provides that added flexibility without out being too confusing for the average end user. Time will tell.

  • beyondplm

    Ed, thanks! Will do. My tests are mostly related to comparison of Onsahpe, F360 and few other software providers.

  • beyondplm

    I think, to have a look on what happened with SolidWorks can give you a good prediction of future strategy. But… we need to give a correction for networked world we live in. Things can get more complicated sooner. SolidWorks users lived long time in a world limited by single desktop and email account. eDrawing, Pack&Go and Workgroup PDM weren’t created early in the process. Now, it is different and Onshape basic tools are data management, share and collaboration. So, time will tell 🙂

  • Ryan

    On the DS comment, I think the real question of V6 and its new file structure is “How do I get existing data into this system?” and “How do I get my data out?” To me this appears to be a system that permanently captures the customers data. I am hoping this is not the case.

  • Ryan

    Oleg-

    I thought that collaboration was happening with the JT Open and the ASME Y14.41-2003 Digital Product Data Definition Practices and ISO 1101:2004 Geometrical Product Specifications (GPS) — Geometrical tolerancing—Tolerances of form, orientation, location and run-out.

  • beyondplm

    Ryan, I think DS is not different from other PLM platforms from the standpoint how to get data in/out. DS might impose more tough policies on API access, but I really don’t have last updates about that.

  • beyondplm

    I thought ASME Y14.41 was mostly about way to use CAD data for manufacturing and inspection. But I’m not very familiar with nuances of how it used. But going back to original comment, how is that related to a richness of project/document models and product configurations?

  • Ryan

    Yes, PMI is way to use data for communication. Which for me is what collaboration is all about. My comments were in response to your comment that “..high end systems need to develop better collaboration technologies.” JT provides an open and neutral format that could be used for this type of collaboration and PMI is the “universal” language- being primarily symbol-based.
    Yes, this is off topic and I apologize. I just felt that your comment needed some further discussion.

  • beyondplm

    Ryan, thanks for this clarification. Collaboration is a very confusing word after all. You are right- PMI is a way to communicate between engineers. But my point was about technologies for collaborative editing and change tracking.

  • Pingback: Beyond PLM (Product Lifecycle Management) Blog » Cloud CAD, real-time collaboration and data management overhead()