Supporting MBD with the Right Technology

This blog post on MBD and MCAD design management has been posted by Industry Analyst Chad Jackson of Lifecycle Insights © LC Insights LLC. The concepts, ideas and positions of this post have been developed independently.

It seems with every passing day, there is more and more interest in Model Based Definition (MBD) initiatives. Some companies are looking at it to satisfy contractual requirements especially in aerospace and defense. Some are looking at it as a means to become more efficient in engineering and simplify design management. Yet others are looking at it as a way to cut down on scrap and incorrectly ordered parts in the supply chain.

Regardless of why a company is considering a change to MBD, there are a big misnomer that an organization must take into account. This issue isn’t obvious at first. However, it can become major issues if not addressed.

MBD is not just about using new functionality

If you look at most Computer Aided Design (CAD) applications today, the capabilities to annotate a 3D model exists. You can add notes, geometric dimensioning and tolerancing. You can define display states where those annotations can be shown or hidden as sets. You can create different views. All this can be managed with MCAD data management. With all this functionality, you can pretty much create what you need as engineering documentation.

While all this capability is becoming more broadly available, pursuing an MBD initiative is a lot more than just telling engineers to start using it.

Engineers can, of course, start annotating 3D models. But as an organization, you will want to follow certain standards. Just think about all of the policies and procedures surrounding the creation of an engineering drawing in your company. Certain notes must follow specific formats. Tolerances are displayed a certain way. Much more non-geometric information is included as well. So when a company pursues MBD, this has to be figured out.

It would be nice if that was all there was to it. But it’s not, because…

MBD requires process change

Why? Well, in my book, anytime you have multiple people working off a deliverable to perform an action or create other deliverables, you have a process. And with MBD, that is exactly what happens.

The annotated model, once released, is used in a myriad of ways. A procurement agent might include it in a data package as part of a request for proposal process. A manufacturing engineer might use it to create assembly instructions. A machinist might use it to generate NC toolpaths. A quality inspector might use it to check for non-conformances. A service planner might use it to build out service instructions. The list of ways to use an annotated model, or really any kind of engineering documentation, goes on and on and on.

But here’s where the big difference comes into play. Many people consider design release an event. But there is no doubt: an annotated model is used in many different processes. And because the unambiguous nature of it is so different, and in many ways better, it actually changes many of those processes. An annotated model can be directly interrogated without the need to interpret 2D entities. It can be used directly to create derived deliverables like CMM toolpaths, tooling for molds and other types of 3D-based instructions. It, of course, becomes the basis of other departments creating model-based deliverables, transforming the organization into a model-based enterprise.

And all of this leads to a critical point…

MBD demands data management

Well, more to the point, MBD initially needs configuration management. You need the ability to track every single iteration and change made in every version of the annotated model. You need the ability to control who can change it and even view it. You need the ability to have a historical record of traceability for who changed it and why.

Why is configuration management so critical for MBD initiatives?

I think the answer is the same reason that you need to manage any kind of deliverable: change. Throughout the work-in-process phase of the design cycle, that model will be changing very quickly, which is one reason why you limit visibility of it for other downstream participants. Sure, you have long lead time items where you need to get a jump start on procurement. But in general, downstream folks like those in manufacturing and quality really don’t get started until design release.

But post design release change is a completely different story. That’s because a version of those deliverables have been provided to a range of other participants. If a change occurs post design release, it needs to be documented carefully in terms of superseded and superseding items. Anyone who had received that earlier version needs to be notified of the change and offered access to the latest item.

MBD needs Product Data Management

Now, can you do that in a spreadsheet?

Technically, the answer is yes. But at what cost? To track all that configuration management work could consume a significant amount of time. Time that someone could be designing new products or performing another value-added task in product development.

Additionally, manually managing configurations introduces the risk of human error. It takes one mistake in that spreadsheet, and you suddenly might cause a significant delay or order a large volume of the wrong part.

Ultimately, the right technology to manage all of this complexity is a Product Data Management system. Quite literally, it was made to track and manage this exact kind of information automatically.

Recap

• Even though MBD functionality is becoming more prevalent in CAD applications, a lot more is needed to enable engineers to author such deliverables. Standards, policies and procedures are needed.
• A lot of different roles will end up using the MBD deliverable. That makes such an effort equates to a process change.
• Just like engineering documentation, configuration management is key for any MBD effort. Tracking and managing change to such deliverables is key.
• You can attempt to manually manage such a deliverable, but it will require a significant amount of effort and introduce the risk of human error. Product Data Management systems are the right fit for such initiatives.

This topic and many others must be carefully considered when pursuing a MBD initiative. For more, read Lifecycle Insights’ new eBook titled CAD and PLM Crucial to MBD Initiatives. Take care. Talk soon.

The eBook is licensed for hosting by Siemens PLM. The concepts, ideas and positions of the blog post and eBook have been developed independently by Industry Analyst Chad Jackson of Lifecycle Insights © LC Insights LLC