Monday, December 17, 2012

Model-Based Engineering, Are We There Yet?

  Part I

As I‘ve mentioned before in several other posts, I’ve had the pleasure of visiting many design and manufacturing companies over the last 20 or so years, sometimes several per month. With some of these visits I even get the pleasure of conducting full product development process assessments. With these assessments I get a first-hand detailed view of how companies design products, from requirements to manufacturing. I also get a glimpse of what their vision might be for the future of their design processes and where they see high-value opportunities in process improvement.

In a previous blog post from 2009 titled “Model Based Definition(MBD) – What’s the Hold-Up?” I gave my early views on the topic and asked my readers a few questions. It is still the most read article on my blog. Interest in this topic remains very high.

There is one consistency I find with any discussion I have regarding “Model-Based” and that is that everyone seems to have a different idea of what it means.  Do we refer to it as Model-Based “Engineering” or “Design” or “Definition” or what? And what's the difference? And what does the term “Model” really refer to?  I have found, however, that if we translate all of this “Model-Based” discussion and debate down to the product development process, what most process experts/owners will agree to is that they need to somehow:

1.       Eliminate the disconnects
2.       Remove the redundancies
3.       And move to a single product definition master
If this Model-Based “whatever” can help them with those three “opportunities”, they want it.
And I think it can, but we have to be in sync on what the real goal is. If “Model-Based” somehow refers to one or more of the three opportunities listed above, we have to know where these conditions may exist, where the priorities are, and what the vision is.
It was over 30 years ago that the CAD industry presented a solution to disconnects and redundancies in the process. They called it “associativity” (which, by the way, is still not a word). Everything was supposed to be associative to the 3D model, i.e. the master model, (an old term). If the model changed, all downstream deliverables would update. Create data once and leverage it to the max. Was this not enough, or did it just not work? Based on my experiences, even the most sophisticated of companies still have many, and I mean many, disconnects, redundancies AND master documents in their processes. When I ask a company what they consider to be their “engineering” master, (and I’m not just referring to the detailed mechanical engineering master) they may have trouble answering that question. And of course, their “engineering” master and “manufacturing” master are at least two different things.
For many people “MBD” refers to the merger of key characteristics of the manufacturing drawing with a rich 3D model, thus eliminating or greatly reducing the need for the detailed manufacturing drawing. But, what’s the big deal with fully annotated and detailed 2D manufacturing drawings? What's the value of merging this data into the 3D model? Let’s see how this stacks up against the three opportunities.
Disconnects:
Most drawings today can be considered “Model-Based” in that they are extracted from a 3D model and are in most cases associated to the same. So in this case we should have no disconnect as the drawings are already "Model-Based".
Redundancies:
It is possible that some of the work done to fully annotate the drawing is redundant to the work that was done when creating the 3D model? But does PMI and 3D annotation eliminate this redundancy or just move the activity to a different "document"? It is possible that we may be able to eliminate some standard dimensions/tolerances by better leveraging the 3D model. So there will be some value here.
The Single Master Document
Perhaps the most significant value comes via the merger of one of the engineering masters (the 3D model) with one of the manufacturing masters (the 2D drawing). There is always high value in eliminating even one document in the process, and this is a big one. The big question with this is; how consumable is this rich document (the 3D model) to downstream functions. Functions such as; Tech Pubs, Mfg., CAM, Tooling, Process Sheets, and the tricky one – QA. We are getting better at this, but still much progress to be made.
Is that all there is to “Model-Based”? Merging the manufacturing drawing into the rich 3D model? On the contrary, in my humble opinion this particular merger is perhaps one of the higher cost, lower value fruits that can be realized through a “Model-Based” initiative. Perhaps it’s a reasonable, although complex, place to start, but don’t let it stop there. There is so many other high value opportunities with “Model-Based”.
In Part II of this post I want to share some other areas in the product development process where “Model-Based” can bring huge value, and in many cases at very low cost. If you have been able to eliminate or greatly reduce the number of 2D manufacturing documents being produced you have made great progress, no doubt. But I can almost guarantee you that even after all that work you most likely still:
1.       have not eliminated all the disconnects
2.       have not eliminated redundancies
3.       and do not have one single product definition master
Paul

2 comments:

Matthew Lorono said...

Have you looked into the solution being offered with the product MBEWorks?

Paul Hamilton said...

Matthew, I have no direct experience with MBEWorks, but I have read some about it and have seen a few demonstrations. It looks like a great tool for SolidWorks users to help them organize and leverage the intelligent 3D model for a variety of downstream deliverables. Grouping these deliverables, for example in the TDP, would be an example of the manufacturing master, in my opinion, as it is being derived from elements of the engineering master, in this case the SolidWorks 3D models.

When I see tools like this there are a few things I always want to know. How can the resulting documents be formally managed, secured and version controlled, in sync with the engineering master. I also like to know how an engineering change will impact the documents – from heavy manual interaction to fully automatic. And once the change is executed, I like to see how the change can be validated. These things I am unfamiliar with in regards to MBEWorks.

Have we simplified the process? Have we been able to remove some disconnects? Have we been able to reduce redundancies? Looks like there are some good possibilities with MBEWorks.