Almost a decade-and-a-half after ANSI 14.41 first saw the light of day, many had predicted by now that the bulk of the engineering world would have adopted Model Based Definition (MBD) by now with open arms. And while there are isolated pockets of success, the overall engineering documentation landscape looks remarkably undisturbed from 2003. In fact, if you pick up your average engineering drawing, you might feel like you’re holding a time capsule, noting what little has practically changed since draftsmen laboriously hacked things out manually back in the mid twentieth century. The only true consolation is the non-associative drawing fakery that plagued early CAD drawings has been all but banished, the relationship between model and drawing has never been tighter. In case you’ve been hiding under an oordinate dimension, CAD is in a bit of a renaissance lately, with all the hoopla generated from the rise of new-fangled cloud-centric products like Fusion 360, Onshape and others. While these new platforms present a great opportunity to take a leap forward in MBD, it’s just not happening. Did MBD just miss a very important boat? Gilligan!
I have a bit of a confession to make if sometimes it sounds like I send mixed signals on this topic: I have a love-hate relationship with MBD. I love the promise of MBD, the potential to take dimensional associativity to the next level, to streamline the process of indicating design intent, to automate and/or eliminate error in so many activities otherwise left to the laborious process of squinting at hardcopies. I also hate the promise of MBD, in that it has been notoriously complicated, there’s a little too much hand-waving when talking about consumption over conventional drawings, and the outright arrogance among some of its largest proponents that the system, more or less as conceived in 2003, is necessarily perfect and therefore immune to influence or evolution. Ultimately it feels like a three-hour tour, sure it’s lots of fun making things out of coconuts, but we’re still stuck on some forsaken island (at least it’s free of polar bears).
To get some understanding on exactly how big the lost opportunity might be, let’s take a quick inventory of how cloud CAD platforms are upending long-held expectations in engineering. Cloud CAD is redefining:
- Access: Where previously sophisticated CAD was strictly the domain of engineering companies and educational institutions, but it’s now within reach of anyone willing to learn.
- Business Models: Where the maintenance of expensive perpetual licenses with annual maintenance limited small market adoption, now subscription and freemium models are in abundance.
- Collaboration: Where effective version control and were previously limited to complex integration with traditional PDM, it’s now intrinsic to the system itself or cloud storage.
- Software Delivery: Where the software was previously only available on a handful of very specific and closely controlled platforms, delivery through a browser makes CAD available on any device.
But when it comes to delivering engineering documentation, it’s a blast from the past. Both Onshape and Fusion 360 in all their forward thinking offer the same old thing we’ve known exactly forever: drawings. The kind you could plot out on a giant plotter and roll up and run around to get manually signed like it’s 1985 again. (I hope no one reading this is manually signing things, but I wouldn’t be surprised). While it’s still early in the lifecycle for both of these tools, it’s a little disheartening after so much innovation to see the documentation end of it be so unimaginative. Capitulation to the natives. Drawings come complete with a refresh button to update out-of-date drawing views. Yawn.
This is a lost opportunity for MBD, or PMI or whatever you want to call it. This is the first real opportunity to make the concept of MBD easily accessible, to evolve the paradigm. But it seems everyone has chosen to punt on the thought. In fact, neither tool supports even the basics of GD&T in its current state, drawing or not. We’re already keenly aware of an education/training problem that interferes with the utility of GD&T. Imagine if you could define GD&T graphically in such a way that would help overcome the common misunderstanding indicative of this complicated though very useful methodology? It’s certainly worth a try. Especially for new generations of engineers that don’t blink twice about sending a completely un-toleranced model over to some manufacturing destination with zero concept of producibility? And how about addressing engineering consumption down the line, for everyone reading drawings today? Providing a means to digest that content downstream without heavy reliance on proprietary formats and technology dependencies that escapes the common interpretation limitations of the common drawing? Maybe the professor can finally get us off this island, right little buddy?